- Forum
- General C++ Programming
- Modern OpenGL C++ Game Programming
Modern OpenGL C++ Game Programming
I have finished loads of C++ Courses and now I want now get into Games Development in C++ and Modern OpenGL, Are there any books for that purpose. I want to develop 3D Games BTW. I have checked learnopengl.com but, that was unable to help me! Are there any websites or books?
I once wanted to learn OpenGL but gave up because of lack of documentation and code samples.
On the other side DirectX is easier to learn from my experience, there are plenty of resources mostly on MSDN.
On the other side DirectX is easier to learn from my experience, there are plenty of resources mostly on MSDN.
If you want to learn something, look at Vulkan. It seems to take OpenGL's place. (No, I don't know what to read for either.)
In the 21st century there is absolutely no sense in making games by directly targeting OpenGL or DirectX. From a marketability standpoint it would tie such a product to one platform direction, and limit the future of that product severely.
It is an interesting study. @malibor, having worked with and used OpenGL for over 30 years I can't figure out how one would come to the conclusion that OpenGL is poorly documented. It is among the most documented 3D graphical API's in history. DirectX is about as well documented, and both are similar (DirectX was largely inspired by the OpenGL design).
However, OpenGL is a dead end now. Vulkan is replacing it. DirectX is fractured between all pre-DirectX 12 and DirectX 12, for much the same reasons. On Apple, there is OpenGL, but the primary API is now Metal.
With 3 API's facing a game developer, the only proper, reasonable response is to use a game engine. There is no other reasonable choice.
Now, if you want to make game ENGINES, you need all 3 of these API's, and you must be expert in each of them. The modern method is far more complex than the previous era, and for a short while (a few years), some platforms will still need OpenGL ES support (Android especially), but that will fade in favor of Vulkan soon.
A game developer would never be able to keep up. It would soak up more time in "engine" development than in game development.
Games are AT LEAST as much about physics, audio, AI, user interface, artwork, texture design, materials programming, and psychology than it is about a graphics API. You have way, way too much to consider to even get bogged down in an engine development.
Let me put this another way. If you approach game development from an OpenGL or DirectX (or Metal) viewpoint, you're going to make the same things everyone else who walked that path from decades ago. Your thinking about the game itself will be oriented primarily by the graphics API.
If you focus on the game, it's look and feel, the sounds (sound effects and music are their own rather large study), the reward system, the user interface notions, you end up making games people actually want to play.
There are 4 major game engines to consider at this point. Lumberyard isn't as well known (Amazon's engine) - it is a rework of CryEngine. It's probably the last on the list before you get to the lesser engines. CryEngine is PC and Console only. Lumberyard can support mobile (but virtually no modest devices). Then, there's Unity or UE4. Beyond that you have a large number of compromises that simply can't compare to the results these provide. Of the set, Unity is peculiar in that it uses C# as the primary coding language, though C++ is certainly possible (and I use that for Unity myself). Unity is far better for supporting mobile targets, while UE4 is better (a little) at really good looking, advanced graphics.
If you're not using one of these, you're in for a compromised development workflow.
Let me say it from the viewpoint of the bottom line. If you started right now, within 5 minutes of reading my post, to start a game, and you knew both OpenGL and DirectX fairly well (but not much else), you would need months to get reasonable looking results with a physics engine, graphics artwork, sound, UI on multiple platforms. Not 2 months or 3 months, it would be 4 to 6 months.
If you chose one of these game engines, you'd have a similar result working, with physics, audio (music depends on your skills and sound effects depend on your cash), artwork (depending on your art skills), etc. in a matter of about 6 weeks.
...and the result would be portable to a much wider range of devices that would actually work.
One reason - every device is different. Knowing OpenGL or DirectX is barely the beginning. Every device has different levels of support for the API's. You have to test your game engine on everything, lest you end up having no idea how the several hundred different models react to your code. You might have things working perfectly on a PC with a fair graphics card, but the game may not even function on slightly more modern GPU's or alternative brands (there are really only two, AMD or NVidia on PC/Console, but on mobile there are at least 3 or 4 others). That doesn't even account for what happens when an OS upgrade stomps on everything you've built.
Now, that DOES happen even with game engines, but think. Would you rather have to scramble to update your own code by first BUYING the new, offending hardware or operating system or driver version of some card you customers are complaining about, or would you rather catch the update from UE4 or Unity and publish an update?
Trust me, you don't want to make games on the raw API's, unless you're just tinkering around.
As a business model it's a total failure. If you're looking for a job in a firm, unless you're going to work for one of those 4 companies that make the modern game engines, you're not going to be writing to the graphics API's. You're going to be writing for a game engine, one of those most likely - very rarely you might be working for an in-house engine that is actually very similar.
That said, you have the same issues for physics. Look into Bullet physics, PhysX and Havok. These are the major physics engines. Take a tour on how they're used. Get a taste for what's there. Without a physics engine, balls don't bounce, collisions don't hit anything, floors don't hold objects, bullets don't damage objects, tires don't roll.
Did you know there are two 3D models for most everything in a game?
There's a visual model that you see. It is dressed up with textures to look good.
There's a SECOND one you never see. It's the physics model. The two must be tied to each other to work. They're different from each other.
If you write your own graphics code to an API, you're going to need one of the standard physics engines, or nothing moves like a real world object. You can get things to move, sure - but not bounce or deflect.
If you just want to know how these API's work, you really should study them. It is a wonderful thing to understand. Here's a simple fact, though. You'll spend at least if not more time understanding how to write shaders than anything else in the 3D pipeline. Water...that's it's own thing. There's no water in the API. It's something you build with a combination of the API and shader development, and that's just how water looks. You must combine that with physics to get it to flow.
Smoke is surprisingly easy, at first.
Glass is yet another world of hurt. It's wonderful if you like physics and the math behind it. There's hardly anything quite like the thrill of finally getting reflection, refraction, caustics and chromium dispersion working correctly for glass materials. It is a thing of beauty. If you don't already know the math behind those 4 visual effects in that list, you're about 5 to 7 months away from getting it working, AFTER you know the API inside and out.
Of course, you're probably not interested in making good looking glass in the game you have in mind. You probably assume there's no flowing water in your vision of game play. I get that. Reverse that logic, though, and realize that defines for you that your game will follow the API options open to your. The tech defines the limits of your game, not for what the hardware can do, but for what you can implement yourself. Game engines bring ALL OF IT to the table for you.
It is an interesting study. @malibor, having worked with and used OpenGL for over 30 years I can't figure out how one would come to the conclusion that OpenGL is poorly documented. It is among the most documented 3D graphical API's in history. DirectX is about as well documented, and both are similar (DirectX was largely inspired by the OpenGL design).
However, OpenGL is a dead end now. Vulkan is replacing it. DirectX is fractured between all pre-DirectX 12 and DirectX 12, for much the same reasons. On Apple, there is OpenGL, but the primary API is now Metal.
With 3 API's facing a game developer, the only proper, reasonable response is to use a game engine. There is no other reasonable choice.
Now, if you want to make game ENGINES, you need all 3 of these API's, and you must be expert in each of them. The modern method is far more complex than the previous era, and for a short while (a few years), some platforms will still need OpenGL ES support (Android especially), but that will fade in favor of Vulkan soon.
A game developer would never be able to keep up. It would soak up more time in "engine" development than in game development.
Games are AT LEAST as much about physics, audio, AI, user interface, artwork, texture design, materials programming, and psychology than it is about a graphics API. You have way, way too much to consider to even get bogged down in an engine development.
Let me put this another way. If you approach game development from an OpenGL or DirectX (or Metal) viewpoint, you're going to make the same things everyone else who walked that path from decades ago. Your thinking about the game itself will be oriented primarily by the graphics API.
If you focus on the game, it's look and feel, the sounds (sound effects and music are their own rather large study), the reward system, the user interface notions, you end up making games people actually want to play.
There are 4 major game engines to consider at this point. Lumberyard isn't as well known (Amazon's engine) - it is a rework of CryEngine. It's probably the last on the list before you get to the lesser engines. CryEngine is PC and Console only. Lumberyard can support mobile (but virtually no modest devices). Then, there's Unity or UE4. Beyond that you have a large number of compromises that simply can't compare to the results these provide. Of the set, Unity is peculiar in that it uses C# as the primary coding language, though C++ is certainly possible (and I use that for Unity myself). Unity is far better for supporting mobile targets, while UE4 is better (a little) at really good looking, advanced graphics.
If you're not using one of these, you're in for a compromised development workflow.
Let me say it from the viewpoint of the bottom line. If you started right now, within 5 minutes of reading my post, to start a game, and you knew both OpenGL and DirectX fairly well (but not much else), you would need months to get reasonable looking results with a physics engine, graphics artwork, sound, UI on multiple platforms. Not 2 months or 3 months, it would be 4 to 6 months.
If you chose one of these game engines, you'd have a similar result working, with physics, audio (music depends on your skills and sound effects depend on your cash), artwork (depending on your art skills), etc. in a matter of about 6 weeks.
...and the result would be portable to a much wider range of devices that would actually work.
One reason - every device is different. Knowing OpenGL or DirectX is barely the beginning. Every device has different levels of support for the API's. You have to test your game engine on everything, lest you end up having no idea how the several hundred different models react to your code. You might have things working perfectly on a PC with a fair graphics card, but the game may not even function on slightly more modern GPU's or alternative brands (there are really only two, AMD or NVidia on PC/Console, but on mobile there are at least 3 or 4 others). That doesn't even account for what happens when an OS upgrade stomps on everything you've built.
Now, that DOES happen even with game engines, but think. Would you rather have to scramble to update your own code by first BUYING the new, offending hardware or operating system or driver version of some card you customers are complaining about, or would you rather catch the update from UE4 or Unity and publish an update?
Trust me, you don't want to make games on the raw API's, unless you're just tinkering around.
As a business model it's a total failure. If you're looking for a job in a firm, unless you're going to work for one of those 4 companies that make the modern game engines, you're not going to be writing to the graphics API's. You're going to be writing for a game engine, one of those most likely - very rarely you might be working for an in-house engine that is actually very similar.
That said, you have the same issues for physics. Look into Bullet physics, PhysX and Havok. These are the major physics engines. Take a tour on how they're used. Get a taste for what's there. Without a physics engine, balls don't bounce, collisions don't hit anything, floors don't hold objects, bullets don't damage objects, tires don't roll.
Did you know there are two 3D models for most everything in a game?
There's a visual model that you see. It is dressed up with textures to look good.
There's a SECOND one you never see. It's the physics model. The two must be tied to each other to work. They're different from each other.
If you write your own graphics code to an API, you're going to need one of the standard physics engines, or nothing moves like a real world object. You can get things to move, sure - but not bounce or deflect.
If you just want to know how these API's work, you really should study them. It is a wonderful thing to understand. Here's a simple fact, though. You'll spend at least if not more time understanding how to write shaders than anything else in the 3D pipeline. Water...that's it's own thing. There's no water in the API. It's something you build with a combination of the API and shader development, and that's just how water looks. You must combine that with physics to get it to flow.
Smoke is surprisingly easy, at first.
Glass is yet another world of hurt. It's wonderful if you like physics and the math behind it. There's hardly anything quite like the thrill of finally getting reflection, refraction, caustics and chromium dispersion working correctly for glass materials. It is a thing of beauty. If you don't already know the math behind those 4 visual effects in that list, you're about 5 to 7 months away from getting it working, AFTER you know the API inside and out.
Of course, you're probably not interested in making good looking glass in the game you have in mind. You probably assume there's no flowing water in your vision of game play. I get that. Reverse that logic, though, and realize that defines for you that your game will follow the API options open to your. The tech defines the limits of your game, not for what the hardware can do, but for what you can implement yourself. Game engines bring ALL OF IT to the table for you.
Everything Niccolo said is true. In fact, there was just recently another thread like this, where somebody was trying to learn OpenGL so that they can begin making a game. Please see this thread: http://www.cplusplus.com/forum/beginner/254857/
http://www.cplusplus.com/forum/beginner/254857/#msg1118369
http://www.cplusplus.com/forum/beginner/254857/#msg1118373
In short, this might not be best path. If you have an idea for a game, then you should focus on the steps needed to bring that idea to life. A game is so much more than just graphics!
(But personally I do think Khronos's documentation for the OpenGL API is great, I don't remember it being inaccurate ever.)
As I said in the other post, the site I recommend for modern OpenGL learning is: http://www.opengl-tutorial.org/
http://www.cplusplus.com/forum/beginner/254857/#msg1118369
http://www.cplusplus.com/forum/beginner/254857/#msg1118373
In short, this might not be best path. If you have an idea for a game, then you should focus on the steps needed to bring that idea to life. A game is so much more than just graphics!
(But personally I do think Khronos's documentation for the OpenGL API is great, I don't remember it being inaccurate ever.)
As I said in the other post, the site I recommend for modern OpenGL learning is: http://www.opengl-tutorial.org/
Last edited on
yikes what a thread, the man just wants some pointers.
You guys really think that after he read a couple pages of "opengl-tutorial" that making a game in this API is gonna be easy and that he never heard of "game engines"?
Like if your first language is C++ and that hasn't stopped you, opengl wont either, I think most people on this forum are like him to some degree, you masochistic people.
Opengl doesn't have any super valuable books, everything you need is on the web, and the most important helper is using probably to use the opengl error callback thing so you don't need to do C style error handling, and read the khronos documentation and wiki. I should warn you I don't really focus on 3D programming, just 2D (which opengl is not bad for).
http://www.opengl-tutorial.org/
http://openglbook.com/the-book.html
https://open.gl/introduction
http://ogldev.atspace.co.uk/index.html
http://duriansoftware.com/joe/An-intro-to-modern-OpenGL.-Table-of-Contents.html
You guys really think that after he read a couple pages of "opengl-tutorial" that making a game in this API is gonna be easy and that he never heard of "game engines"?
Like if your first language is C++ and that hasn't stopped you, opengl wont either, I think most people on this forum are like him to some degree, you masochistic people.
Opengl doesn't have any super valuable books, everything you need is on the web, and the most important helper is using probably to use the opengl error callback thing so you don't need to do C style error handling, and read the khronos documentation and wiki. I should warn you I don't really focus on 3D programming, just 2D (which opengl is not bad for).
http://www.opengl-tutorial.org/
http://openglbook.com/the-book.html
https://open.gl/introduction
http://ogldev.atspace.co.uk/index.html
http://duriansoftware.com/joe/An-intro-to-modern-OpenGL.-Table-of-Contents.html
| You guys really think that after he read a couple pages of "opengl-tutorial" that making a game in this API is gonna be easy and that he never heard of "game engines"? |
You missed the point.
It has nothing to do with OpenGL being approachable.
OpenGL is outdated, and there are now 3 separate API's to study, before one gets into actual development of a game.
What you ignore is just who the rest of us offering advice really are. Some of us have decades of experience and know more than the technologies, we know business, we know life.
I covered why OpenGL is a worthy study.
It is not if you, at this point, in 2019, intend to make games.
Why, for example, would you propose it is somehow appropriate to study OpenGL, today, half way to 2020, when it is already an obsolete API?
opinions, opengl is pretty good for performance.
edit:
I guess this post makes me seem like a bit of an asshole, sorry.
Do opengl, don't do opengl. Make a engine from scratch, don't make an engine from scratch. It really doesn't matter, I just went into this thread because I had a bunch of urls in my bookmarks that helped me a tiny bit with aspects of opengl. It's not like the alternatives to opengl solve the problem of making a "good game", and I think the secret to making a "good game" is to just have friends, and to just do hard problems, and finding the best solution. Even if you spends months to learn opengl, it takes years to learn C/C++ at a large scale anyways, and all games are pretty damn large codebases. If you can't do opengl because you don't like it, then it isn't that big of a deal, what matters is that you want to learn opengl, or learn anything that you have a desire for. Plus I think the coolest thing about C++ is that you can use emscriptem in websites, and the only (methinks?) graphics interface is opengl es (or SDL2 which uses opengl for 2D, oh yea and unreal and unity too, but ATM webassembly isn't cached on your disk and the loading speed is not good enough, also ureal engine has a pretty heafty minimum payload).
edit:
I guess this post makes me seem like a bit of an asshole, sorry.
Do opengl, don't do opengl. Make a engine from scratch, don't make an engine from scratch. It really doesn't matter, I just went into this thread because I had a bunch of urls in my bookmarks that helped me a tiny bit with aspects of opengl. It's not like the alternatives to opengl solve the problem of making a "good game", and I think the secret to making a "good game" is to just have friends, and to just do hard problems, and finding the best solution. Even if you spends months to learn opengl, it takes years to learn C/C++ at a large scale anyways, and all games are pretty damn large codebases. If you can't do opengl because you don't like it, then it isn't that big of a deal, what matters is that you want to learn opengl, or learn anything that you have a desire for. Plus I think the coolest thing about C++ is that you can use emscriptem in websites, and the only (methinks?) graphics interface is opengl es (or SDL2 which uses opengl for 2D, oh yea and unreal and unity too, but ATM webassembly isn't cached on your disk and the loading speed is not good enough, also ureal engine has a pretty heafty minimum payload).
Last edited on
| You guys really think that after he read a couple pages of "opengl-tutorial" that making a game in this API is gonna be easy and that he never heard of "game engines"? |
I agree, performance of OpenGL is fine. Although Vulkan could potentially make things better, that doesn't really matter unless OP is trying to make AAA games.
| wikipedia wrote: |
|---|
| NVIDIA notes that OpenGL is still a great option for a lot of use cases, as it comes at a much lower complexity and maintenance burden than Vulkan, while in many cases still providing great overall performance.[31] AMD says that Vulkan supports close-to-metal control, enabling faster performance and better image quality across Windows 7, Windows 8.1, Windows 10, and Linux. No other graphics API offers the same powerful combination of OS compatibility, rendering features, and hardware efficiency.[32] |
[31] https://developer.nvidia.com/transitioning-opengl-vulkan
[32] https://www.amd.com/en/technologies/vulkan
Last edited on
Patient: "Doctor, please give some painkillers! My leg hurts!"
The good doctor sees that a lion is gnawing the leg. Should she (A) give the requested painkillers (that are known to suppress the pain effectively), or (B) suggest removal of the lion?
Learning OpenGL might keep someone busy and happy for a while, but they will notice that they have to learn a different API in order to really get into "modern Game Development".
The good doctor sees that a lion is gnawing the leg. Should she (A) give the requested painkillers (that are known to suppress the pain effectively), or (B) suggest removal of the lion?
Learning OpenGL might keep someone busy and happy for a while, but they will notice that they have to learn a different API in order to really get into "modern Game Development".
@poteto,
Are you trying to be a troll here?
Vulkan, Metal and DX12 offer considerably more performance, which isn't an opinion.
It also isn't the point, which is why I have to wonder what you're really trying to do.
| opinions, opengl is pretty good for performance. |
Are you trying to be a troll here?
Vulkan, Metal and DX12 offer considerably more performance, which isn't an opinion.
It also isn't the point, which is why I have to wonder what you're really trying to do.
https://www.opengl-tutorial.org/
This is where I learned the basics. Pretty well explained. The tutorials use glfw as a window manager, but the code can be inserted into any GUI framework like Qt, SFML, SDL,...
But as others said openGL is being replaced by Vulkan.Sadly I haven't found any good vulkan tutorials out there yet.
Also, why make a whole new game engine and reinvent the wheel when there's loads openly available solutions out there. I personally recomend godot (https://godotengine.org/). It's fairly straight forward, supports C#, GDScript (pimped out python), the whole engine is written in c++ so you can make your game by extending the engine basically. And it's open source.
EDIT: And of course there's https://www.unrealengine.com/
EDIT 1: Promising Vukan tutorials:
https://www.youtube.com/playlist?list=PLUXvZMiAqNbK8jd7s52BIDtCbZnKNGp0P - YT Playlist
https://vulkan-tutorial.com/ - website / ebook / git repo
This is where I learned the basics. Pretty well explained. The tutorials use glfw as a window manager, but the code can be inserted into any GUI framework like Qt, SFML, SDL,...
But as others said openGL is being replaced by Vulkan.
Also, why make a whole new game engine and reinvent the wheel when there's loads openly available solutions out there. I personally recomend godot (https://godotengine.org/). It's fairly straight forward, supports C#, GDScript (pimped out python), the whole engine is written in c++ so you can make your game by extending the engine basically. And it's open source.
EDIT: And of course there's https://www.unrealengine.com/
EDIT 1: Promising Vukan tutorials:
https://www.youtube.com/playlist?list=PLUXvZMiAqNbK8jd7s52BIDtCbZnKNGp0P - YT Playlist
https://vulkan-tutorial.com/ - website / ebook / git repo
Last edited on
Topic archived. No new replies allowed.