C++ Opengl Game Engine

[Saustin Grody]

Tohave one shader program with a lot of uniforms specifying lights to use, or mappings to do (e.g. I need one mesh to be parallax mapped, and another one parallax/specular mapped). I'd make a cached list of uniforms for lazy transfers, and just change a couple of uniforms for every next mesh if it needs to do so.

To have a lot of shader programs for every needed case, each one with small amount of uniforms, and do the lazy bind with glUseProgram for every mesh if it needs to do so. Here I assume that meshes are properly batched, to avoid redundant switches.

Generally, option 2 will be faster/better unless you have a truly huge number of programs. You can also use buffer objects shared across programs so that you need not reset any values when you change programs.

In addition, once you link a program, you can free all of the shaders that you linked into the program. This will free up all the source code and any pre-link info the driver is keeping around, leaving just the fully-linked program in memory.

I would tend to believe that it depends on the specific application. And yes since it would be more efficient to say run 100 programs where they each may have about 2-16 uniforms each; it may be better to have a trade off of the two. I would tend to think that having say maybe 10 - 20 programs for your most common shading techniques would be sufficient or a few more. For example you might want to have one program / shader to do all your bump mapping, one to do all of your fog effects, one to do reflections, one to do refractions.

Now outside the scope of your question I think it would pertain here as well, one thing to incorporate into your engine would be a BatchProcess & BatchManager class setup to reduce the amount of CPU - GPU calls over the bus as this would prove efficient as well. I don't think there is a 1 fits all solution to your question as I would believe that it would be application specific just as setting up the relationship between how many batches (buckets) of vertices (primitives) your engine would have and how many vertices each of those batches would contain.

To try to make this a bit more clear: one game might have 4 containers or batches where each batch can hold up to 10,000 vertices to be considered to be full before the BatchManager decides to empty that bucket sending all of those vertices to the Graphics Card for the Rendering pipeline to be processed and drawn where a different game may have 10 buckets with 5,000 vertices, or another game might have 8 buckets with 12,0000 vertices.

So there could be a trade off of trying to combine the two according to your needs. If you have 1 single program with 100s of uniforms; the single program is easier to manage within the pipeline, but the shaders would be over cumbersome to read and manage. Then again have shaders with very few uniforms is quite easy to read and manage but having 100s of programs is a little harder to manage on the CPU before linking and sending them to be rendered properly. I would personally try to find a middle ground to where I have enough programs to do each specific task that is completely unique from each other such as doing fog density on one and a volumetric shadow mapping on another where each program has just enough uniforms to do the calculations required.

I am new to OpenGL ES, and I'm about to begin a 3D game for the iphone in which we are showing some car pursuit or racing. Is it possible just with the OpenGL ES or UIKit only, or do I have to use other tools for it? I am comfortable with UIKit but newer to OpenGL/OpenGL ES; which would be better to start this game?

OpenGL is a 3D graphics API. If you go with this, you'll have to write quite a bit of extra code, maybe some tools and a pipeline, to get a fully-featured game going. For example, collision systems and AI will be on you to develop.

For your application, it sounds like you might be better off going with a game engine as it will get you up and running much sooner than if you try to develop those systems yourself. One popular engine is the Unity engine.

Actually you cannot compare OpenGL and game engines. OpenGL is just a graphics programming API, the very basic rendering stuff so to speak. If you are going for OpenGL you will have to code everything yourself, find out how to render complex effects like shadows, lights, as well as all game objects.

While a game engine is not a rendering engine either, a decent game engine already has all the rendering stuff covered and will manage your game objects (cars, houses, trees, etc.) for you. Depending on how good it is it may impose certain restrictions on what you can do with, but for a beginner using a game engine would certainly be the right start off. With a game engine you can just specify your game's behaviour on a pretty high abstraction level and won't have to bother about all the basics anymore.

Think of the difference between OpenGL and a game engine like the difference between getting a car building factory where you have to program all the machines yourself to get the desired car's part (OpenGL) and having all parts of the car ready for assembly already (game engine) and only having to put them together, maybe change the color here and add a gear there.

This really depends on how comfortable you are programming graphics code. OpenGL is easy to get used to if you have a strong C background, but if you're used to an object-oriented language like Java it can be difficult. As Dominic mentioned, you also have to write a substantial amount of code to get a good game off the ground. 3D adds a substantial amount of complexity over 2D.

I would suggest using a game engine such as Unity. I have a friend that writes iPhone games using it, and I've been very impressed with the results. It will import 3D models from Maya or 3D Studio Max directly and worry about texturing, materials, etc...

The only downside to this approach is that the game engine cannot be optimized to your specific needs. If there's a special OpenGL technique you want to use, or a very graphics-intensive scene you need to render, writing everything directly in OpenGL will give you more control and better results.

I think it is better when you just do it like you want. First of all I thought about using an Engine just like you but ist is better when you start from scratch because you will understand more and maybe you will be able to programm anything you want.

I am an undergraduate computer science student. I want to be a game designer and my institute does not offer courses in game design field. That is why I started learning OpenGL. So the final aim is to get in game designing industry. And as I am good at programming, I guess I will end up being a programmer. In this case what should I do??

Again, the question is this: do you want to be a game designer or a game programmer? If you want to design games, then you should use whatever tools you have available to make designing the actual game part of your game easier. If you want to program games, then you should practice that.

I recommend you try making your own game engine from scratch, and design a game for that engine. See what you like and dislike about doing both and come to a decision about what you like more. All-in-all I think it would be beneficial to do both regardless of what you want to do in the long run for the sake of understanding how everything works together.

If you know how to write a game engine, then you should rather easily be able to learn to use any game engine, because general concepts are the same. But if you only study how to use one particular game engine, then you may have a harder time learning how to use another game engine, because all you really know are how-to details and not why anything is as it is. What if you choose to only learn XYZ game engine now, but then when you graduate you find a company you want to work for that uses ABC game engine? Will they hire you?

To find out how engines work, download some open-source engines, analyze them with Understand C++, split them up into toolkits (this can be a bit involved) and voila you have some toolkits you can use in your game and you even lose the (L)GPL.

When Metal came out, I had barely finished the first stage of my game engine. Back then, I thought that it would be a good idea to port the engine to Metal. However, I resisted in doing so, until Metal became stable.

Well, on the weekend of July 4th, 2017, I happened to play around with some Metal demo apps, and I was impressed at Metal's power. It was then that I decided to use my four-day weekend learning and porting the engine from OpenGL to Metal.

On Tuesday night, I laid out a plan on how to port the engine from OpenGL to Metal. All in all, the porting took about two weeks. There are some minor bugs to fix, but all in all, I'm pleased with the results. Here is a screenshot of the engine using Metal.

Most of what I know about Metal, you can find it here. I wrote these articles a while ago,; I used them as a reference during my review and the porting. But here are the main things that you should know about Metal:

If you have experience working with OpenGL and have a good grasp of computer graphics, Metal will be a piece of cake to learn. I can guarantee that you will love it. However, if you are a newbie, keep in mind, that it may take a while for you to grasp Computer Graphics concepts and Metal at the same time. Hopefully, these articles can help you out.

I make a voxel engine on LWJGL 3 (OpenGL binding for JVM).I store all object data in world class.World is subdivided into 32*32*32 chunks.Chunks use octree storage.The main part of all my rendering is cubes that share one mesh but have different transformation matrices and some other data. To render those i use one VAO per chunk, it contains only one cube mesh instance and has all cubes data (like transformations) stored in its VBOs.I construct each chunk VAO once and render it fully in one call - glDrawElementsInstanced.If i need to change some cube data in a chunk, i will reconstuct VAO from ground up or change individual buffer data. That should be pretty efficient, right ?

3a8082e126