Even after all these years, this is still the best C++ game engine tutorial series. I hope you know that your videos have been a tremendous help and inspiration to me, and they greatly influenced my decision to enter this industry. Through your videos, I have gradually developed an engineer's mindset, not just limited to implementing certain features. I am extremely grateful.
I might not create my own engine through your tutorials but I love your videos anyway. It is nice to find a well-structured video about C++ coding with someone who's as experienced as you.
@@proferorz3778 This is not a good advice. No one cares about Windows 7 / 8.1 anymore. And if you start developing an engine now, by the time you are going to release something build on top of your engine, those operating systems will be even less relevant.
@@NymezWoW I know that this is a pretty old thread, but the statement "no one cares about windows 7 anymore" is just flat out false. Windows 7 still has a much higher market share than Linux for example, and I don't think you could say "nobody cares about Linux" as easily.
@@NymezWoW you're generalising a lot here. Linux is to Windows, not Windows 7. Saying Linux is still maintained is like saying Windows is still maintained. Doesn't make any sense at all. Older Linux such as version 3 are in fact already not maintained at all. There are a lot of features that exists only in latest Linux version, just like there are more features that exists in Windows 11 compared to Windows 7.
Definitely would like Vulkan support at some point. I do plan on adapting this engine and hopefully using it to make my own game(s) in the future. It would be super cool to get games on something like the Nintendo Switch and if that requires Vulkan, I want it, lol. Thanks again for this series, it's extremely valuable to me and I'm sure many others.
you can look up 'creating vulkan renderer from scratch' here on yt, it looks scary at first since it's very verbose, but once you get used to it it's quite fun to use
I like the way this series is heading. With more OpenGL videos we can learn more in-dev things about for example the frame buffers you mentioned while this series can focus more on the general approach of how a game engine can be designed. With OpenGL as it's base it also means we don't have to wait forever for the basic things to work. This way, people who want to use Vulkan can still implement Vulkan while others might go with DX11/12 or OpenGL or Metal 1/2 without having to wait so long just because it might be faster to implement with their API as it would be if you would go with Vulkan instead. Thought I'd love to see first of all Vulkan and later on DirectX in the future as well. It should be especially interesting to see how a game engine interacts with multiply rendering-api's in code. For my own projects so far, my biggest problem has always been where to draw this line between render API and renderer, especially as I'm still learning C++ and Vulkan. At the end of one project, I always find myself in the position that I could have done thousands of things differently, be it either because I learned new things in Vulkan/C++ or because one or another design decision didn't play out in the end. Guess I'll start another engine in the near future. It'll be interesting to see the differences between your design, someone who works on Games as a professional and the design decisions I made in the past. :) For scripting, I would love to see a C# integration. Another idea of mine would be to port the engine to Android. I always wondered how game engines create APK files and how they integrate with all those native java or kotlin based android libraries and APIs. Especially since so much changes between android versions, like the app permissions or the new app bundles or instant apps.
AIGC: - The video is part of a game engine series and focuses on rendering architecture. - The presenter expresses gratitude to patrons for supporting the series and keeping it going. - There are two sides to the rendering system in a game engine: the render API, which is specific to graphics APIs such as OpenGL and DirectX, and the platform-independent side. - The presenter talks about the various components needed for the render API, including the render context, swap chain, frame buffer, vertex buffer, index buffer, texture API, shared API states, pipelines, and render passes. - The video is geared towards practical implementation and will be using OpenGL as an example.
I have learned more here from these videos than any course I've taken to date!!! This is a little throw back to the C++ series. Would you be willing to do a video about best practices or the most efficient methods of 'interop-ing' between managed and unmanaged code?
The reason that's given for why Vulkan is a low priority in this project is that it's not beginner friendly. It sounds like there should be a wrapper library for Vulkan to make it more accessible. This game engine is a library though but regardless, DirectX 12 and Metal are proprietary. Looking at it from a teaching perspective and tech perspective, adopting proprietary APIs binds learners and end users to specific platforms and their respective business models.
I recommend looking into bgfx by bkaradzic on GitHub if you haven’t heard of it! c: It’s a low level wrapper around the most common graphics API’s. Vulkan is still WIP but on the way!
Thanks for the videos! Just a side note: some of your "Game engine series" videos (like this one) are actually not added to the playlist. It is recommended to make a filter that automatically adds these kind of videos to your playlist. :)
Congrats!, just do your thing man, always appreciate all your time and effort, you need to have time for yourself. Just don't get in any trouble at that Bach. party, we would like to see you again! Hehehe, hope you have a lot of fun man.
Rather than trying to create a renderer API engine for all Render APIs, would not game developers select a single Render API, and depending upon which platform one is developing for, select a render API for a single platform, or in the case of cross platform, select the API that is cross platform? So, would not for cross platform, it is Vulcan, or even openGL for lower requirements. And would not each Render API have different features not present on others that would determine which is selected depending upon ones needs ? But any way, I find all these videos quite informative and good to give a better understanding of C++ and how game engines are put together. Keep up the good altruistic work.
Every time someone mentions Vulkan I get an itch to learn it, but I've never even got a triangle up. Just the setup is miles more complicated than OpenGL. I'm gonna try it again, I really do want to learn.
I would love to see this engine in Vulkan. I'm concerned that if you start in OpenGL that you can't get all the benefits from Vulkan (or D3D12/PS4 graphics API) without refactoring a lot of code later on, like multiple draw call threads etc. Just an idea.
@@dw2843 That's just the setup. And like OpenGL, he won't explain the API in the game engine series. He has a separate series for that. And as such, he only needs to explain the game engine side. Setup is partially copy paste and tweaking the settings to your needs. Compared to the setup the rest is not much harder than D3D11, and though it's more code, it's quite straight forward.
Is it some kind of natural law, that the more low-level an API is, the more flexible and the more performant it is? Or could we some day reach a state where we can program very high-level and reach the same amount of performance as with Vulkan or DirectX 12? E.g. nowadays there is almost no need to program in Assembly, because compilers are well optimized and it is unlikely that you will do it better by hand than the compiler does it for you. And compiled languages like C++ are still very generalistic.
Why are you not using ogre3d or bgfx or nvidia optix, which already has decent rendering techniques. ? Bgfx support almost every rendering platforms. Is there any specific reason?
@@berthold64 Unity uses mono too, it's not that complicated. Though any GC language is not really desirable for game development. You're better off with using native scripting performance wise.
Not Yan, but IMO it's too much of an abstraction to get what you really want. What Yan was talking about here, that some parts would still need to be native, BGFX still tries to abstract. For high performance/high fidelity you will hit a ceiling sooner than later if you're using BGFX.
You keep talking about liking DirectX and how its better, nicer, faster( a lot faster from benchmarks I have run) Why do you do all your tutorials on OpenGL? When are we going to get a C++ DirectX tutorial already? There is not really many out there but tons of OpenGL tutorials. I want to see a DirectX 11 or 12 Tutorial from you instead.
@@dariusduesentrieb I know but at the same time the overall market share of linux hovers around 2% total so it basically is linux developers developing for nothing other then other linux developers lol. I think I got that recursion right. But seriously though, most people use Windows, and DirectX is much faster and better supported cleaner API since its native to the OS itself. As he himself states many times DX is better yet we see him doing no directX code. I personally would like to see it because OpenGL tutorials are a dime a dozen. I mean hell, if I am not mistaken Apple is cutting OpenGL in favor of Metal and Apple has a much larger share then linux so a tutorial should stress that before it panders to the linux market. Don't get me wrong, I like linux and do some code there myself but that is not the point right now. Almost everyone has Windows machines anymore.
@@seditt5146 You can develop with OpenGL on Linux for Windows and Linux so Linux developers do *not* develop only for other Linux users. Also, DirectX is not really faster than OpenGL. If it is indeed faster then not that much that it would matter for our level of understanding. Additionally, it seems like the current trend is towards portability (see for example how much Steam tries to get games working on Linux (Proton)). So it is easier to just start with OpenGL, instead of doing it with DirectX and then again with Vulkan or OpenGL.
@@dariusduesentrieb Your fucking kidding me, this new TH-cam reply system just caused me to lose a massive response I wrote for you. TL:DR because I aint writing that shit again... DX is for Windows, by Windows with a heavy hand in the hardware development. Its born and breed faster. I had a PS2 emulator( yes terrible benchmark but still) 120+ fps for DX11, 4fps for openGL if it didnt crash. The Linux thing, a joke, a slightly accurate joke lol, but still a joke. Sorry response is hacking but I aint writing that wall of text I just lost all over again because I clicked outside this friggin chat box.
@@seditt5146 Surely those PS2 emulator stats are meaningless. The framerate in each of those emulators is dependent on the prowess of the programmer who wrote them and not a reflection of the graphics API's rendering speed. And anyway this course seems to be focusing on general engine structure and management which is something covered publicly nowhere to my knowledge, huge deal, API is mostly irrelevant here, can't fucking wait holy shiiit.
Even after all these years, this is still the best C++ game engine tutorial series. I hope you know that your videos have been a tremendous help and inspiration to me, and they greatly influenced my decision to enter this industry. Through your videos, I have gradually developed an engineer's mindset, not just limited to implementing certain features. I am extremely grateful.
I might not create my own engine through your tutorials but I love your videos anyway.
It is nice to find a well-structured video about C++ coding with someone who's as experienced as you.
Yes, true
Wow I am loving your videos. I am writing my own dx12/vulkan engine and you've opened my eyes.
lucky! i suggest add dx 11, no all pc's have windows 10, someone have 7 or 8.1
@@proferorz3778 This is not a good advice. No one cares about Windows 7 / 8.1 anymore. And if you start developing an engine now, by the time you are going to release something build on top of your engine, those operating systems will be even less relevant.
@@NymezWoW I know that this is a pretty old thread, but the statement "no one cares about windows 7 anymore" is just flat out false. Windows 7 still has a much higher market share than Linux for example, and I don't think you could say "nobody cares about Linux" as easily.
@@iamlogdog Linux is still maintained. Windows 7 is not. It has no future.
@@NymezWoW you're generalising a lot here. Linux is to Windows, not Windows 7. Saying Linux is still maintained is like saying Windows is still maintained. Doesn't make any sense at all. Older Linux such as version 3 are in fact already not maintained at all. There are a lot of features that exists only in latest Linux version, just like there are more features that exists in Windows 11 compared to Windows 7.
Definitely would like Vulkan support at some point. I do plan on adapting this engine and hopefully using it to make my own game(s) in the future. It would be super cool to get games on something like the Nintendo Switch and if that requires Vulkan, I want it, lol. Thanks again for this series, it's extremely valuable to me and I'm sure many others.
This is how PowerPoint presentations (and presentations in general) should be made. It's straight to the point and easy to understand. Good work!
I have no idea how Vulkan code looks and it sounds scary but i'm looking forward to seeing you implement it and learn it myself as well.
Vulkan is beast, but if you already know OpenGL, then you'll hate it but secretly love it. Vulkan is very similar to DX12.
you can look up 'creating vulkan renderer from scratch' here on yt, it looks scary at first since it's very verbose, but once you get used to it it's quite fun to use
@@Shifticek Vulkan is very verbose, but somehow, it makes me feel better programming with it, no hidden code, no assumptions.
I won't be a GameEngine Dev without you
I like the way this series is heading. With more OpenGL videos we can learn more in-dev things about for example the frame buffers you mentioned while this series can focus more on the general approach of how a game engine can be designed. With OpenGL as it's base it also means we don't have to wait forever for the basic things to work. This way, people who want to use Vulkan can still implement Vulkan while others might go with DX11/12 or OpenGL or Metal 1/2 without having to wait so long just because it might be faster to implement with their API as it would be if you would go with Vulkan instead. Thought I'd love to see first of all Vulkan and later on DirectX in the future as well. It should be especially interesting to see how a game engine interacts with multiply rendering-api's in code. For my own projects so far, my biggest problem has always been where to draw this line between render API and renderer, especially as I'm still learning C++ and Vulkan. At the end of one project, I always find myself in the position that I could have done thousands of things differently, be it either because I learned new things in Vulkan/C++ or because one or another design decision didn't play out in the end. Guess I'll start another engine in the near future. It'll be interesting to see the differences between your design, someone who works on Games as a professional and the design decisions I made in the past. :)
For scripting, I would love to see a C# integration. Another idea of mine would be to port the engine to Android. I always wondered how game engines create APK files and how they integrate with all those native java or kotlin based android libraries and APIs. Especially since so much changes between android versions, like the app permissions or the new app bundles or instant apps.
AIGC:
- The video is part of a game engine series and focuses on rendering architecture.
- The presenter expresses gratitude to patrons for supporting the series and keeping it going.
- There are two sides to the rendering system in a game engine: the render API, which is specific to graphics APIs such as OpenGL and DirectX, and the platform-independent side.
- The presenter talks about the various components needed for the render API, including the render context, swap chain, frame buffer, vertex buffer, index buffer, texture API, shared API states, pipelines, and render passes.
- The video is geared towards practical implementation and will be using OpenGL as an example.
I have learned more here from these videos than any course I've taken to date!!! This is a little throw back to the C++ series. Would you be willing to do a video about best practices or the most efficient methods of 'interop-ing' between managed and unmanaged code?
The reason that's given for why Vulkan is a low priority in this project is that it's not beginner friendly. It sounds like there should be a wrapper library for Vulkan to make it more accessible. This game engine is a library though but regardless, DirectX 12 and Metal are proprietary. Looking at it from a teaching perspective and tech perspective, adopting proprietary APIs binds learners and end users to specific platforms and their respective business models.
I recommend looking into bgfx by bkaradzic on GitHub if you haven’t heard of it! c: It’s a low level wrapper around the most common graphics API’s. Vulkan is still WIP but on the way!
I, personally, am waiting on the DirectX 12 implementation in this series.
Thanks for the videos! Just a side note: some of your "Game engine series" videos (like this one) are actually not added to the playlist. It is recommended to make a filter that automatically adds these kind of videos to your playlist. :)
You are the only youtuber that I hit like button before even watching the video
Me too!
He is definitely a very honest guys!
I wish you the best with this channel and for your entire life!
Congrats!, just do your thing man, always appreciate all your time and effort, you need to have time for yourself. Just don't get in any trouble at that Bach. party, we would like to see you again! Hehehe, hope you have a lot of fun man.
Rather than trying to create a renderer API engine for all Render APIs, would not game developers select a single Render API, and depending upon which platform one is developing for, select a render API for a single platform, or in the case of cross platform, select the API that is cross platform? So, would not for cross platform, it is Vulcan, or even openGL for lower requirements. And would not each Render API have different features not present on others that would determine which is selected depending upon ones needs ?
But any way, I find all these videos quite informative and good to give a better understanding of C++ and how game engines are put together. Keep up the good altruistic work.
26:47 R.I.P.
Every time someone mentions Vulkan I get an itch to learn it, but I've never even got a triangle up. Just the setup is miles more complicated than OpenGL.
I'm gonna try it again, I really do want to learn.
There is a good write-up from Intel. Also if you wanna look at finished code you can lookup the granite renderer on GitHub.
This is amazing, thank you so much just wow
Looking forward to the dx12 and vulkan implimentation.
thanks!
Hey, thank you so much for your lessons)
I would love to see this engine in Vulkan. I'm concerned that if you start in OpenGL that you can't get all the benefits from Vulkan (or D3D12/PS4 graphics API) without refactoring a lot of code later on, like multiple draw call threads etc.
Just an idea.
It's way to complex for a tutorial series imo. Have you seen how hard it is to draw a triangle?
@@dw2843 Yes. I've done it, which is also why I'd like to see it in the series.
@@nextlifeonearth If you've done it, you would know how long it would take to explain all those lines of code. We wouldn't get too far.
@@dw2843 That's just the setup. And like OpenGL, he won't explain the API in the game engine series. He has a separate series for that.
And as such, he only needs to explain the game engine side. Setup is partially copy paste and tweaking the settings to your needs. Compared to the setup the rest is not much harder than D3D11, and though it's more code, it's quite straight forward.
@@nextlifeonearth Oh right. Forgot that he mentioned that. If he's not explaining the API, I would be interested in Vulkan too!
What would u say about render/frame graphs? It looks pretty cool but a downside would be async compute.
I'm Victorian too, thought you were European or something. Guess this proves that the best TH-camrs cone from 'straya
no it doesn't
@@brod515 I don't think he lives in Australia permanently.
i know ur on that engine grind but i would love a mutex video for c++
@Pro PlexTM sunday?
A lot of useful stuff!!!!!
Nice vid :P Keep going!
Is it some kind of natural law, that the more low-level an API is, the more flexible and the more performant it is? Or could we some day reach a state where we can program very high-level and reach the same amount of performance as with Vulkan or DirectX 12?
E.g. nowadays there is almost no need to program in Assembly, because compilers are well optimized and it is unlikely that you will do it better by hand than the compiler does it for you. And compiled languages like C++ are still very generalistic.
Excelent video
You are not supposed to know about the bachelor party in advance!
Vulkan!!
Excellent, keep it up ;)
17:41
Why are you not using ogre3d or bgfx or nvidia optix, which already has decent rendering techniques. ? Bgfx support almost every rendering platforms. Is there any specific reason?
Because this is an educational journey designed to teach you how to write your own.
Will you come to GDC this week??
hey can the scripting language be lua?
how about...
Javascript?
Or C#
@@loryon C#
@@loryon I think C# could be very complicated to implement, because you have to deal with MSIL compiler and runtime thingy.
@@berthold64 Unity uses mono too, it's not that complicated.
Though any GC language is not really desirable for game development. You're better off with using native scripting performance wise.
I would like to know... what do you think about BGFX?
Not Yan, but IMO it's too much of an abstraction to get what you really want. What Yan was talking about here, that some parts would still need to be native, BGFX still tries to abstract.
For high performance/high fidelity you will hit a ceiling sooner than later if you're using BGFX.
hmmm what whit skybox and lights?
huh?
Before 50 viewers
Can anyone recommend a book/video/ (paid/unpaid) to learn DirectX?
Chilli tomato noodle yt channel
@@adr_12_43: Awesome! thanks, not sure why couldn't find him before
include directx
Hewwo
this is so exciting! also 💒💍💕😊
A comment with 0 likes and 0 replies? With a creator heart? Wow, you don't see it everyday!
You keep talking about liking DirectX and how its better, nicer, faster( a lot faster from benchmarks I have run) Why do you do all your tutorials on OpenGL? When are we going to get a C++ DirectX tutorial already? There is not really many out there but tons of OpenGL tutorials. I want to see a DirectX 11 or 12 Tutorial from you instead.
DirectX does not really work for development on Linux and Linux has over 20% market share with developers.
@@dariusduesentrieb I know but at the same time the overall market share of linux hovers around 2% total so it basically is linux developers developing for nothing other then other linux developers lol. I think I got that recursion right.
But seriously though, most people use Windows, and DirectX is much faster and better supported cleaner API since its native to the OS itself. As he himself states many times DX is better yet we see him doing no directX code. I personally would like to see it because OpenGL tutorials are a dime a dozen.
I mean hell, if I am not mistaken Apple is cutting OpenGL in favor of Metal and Apple has a much larger share then linux so a tutorial should stress that before it panders to the linux market. Don't get me wrong, I like linux and do some code there myself but that is not the point right now. Almost everyone has Windows machines anymore.
@@seditt5146
You can develop with OpenGL on Linux for Windows and Linux so Linux developers do *not* develop only for other Linux users.
Also, DirectX is not really faster than OpenGL. If it is indeed faster then not that much that it would matter for our level of understanding.
Additionally, it seems like the current trend is towards portability (see for example how much Steam tries to get games working on Linux (Proton)). So it is easier to just start with OpenGL, instead of doing it with DirectX and then again with Vulkan or OpenGL.
@@dariusduesentrieb Your fucking kidding me, this new TH-cam reply system just caused me to lose a massive response I wrote for you. TL:DR because I aint writing that shit again... DX is for Windows, by Windows with a heavy hand in the hardware development. Its born and breed faster. I had a PS2 emulator( yes terrible benchmark but still) 120+ fps for DX11, 4fps for openGL if it didnt crash.
The Linux thing, a joke, a slightly accurate joke lol, but still a joke.
Sorry response is hacking but I aint writing that wall of text I just lost all over again because I clicked outside this friggin chat box.
@@seditt5146 Surely those PS2 emulator stats are meaningless. The framerate in each of those emulators is dependent on the prowess of the programmer who wrote them and not a reflection of the graphics API's rendering speed. And anyway this course seems to be focusing on general engine structure and management which is something covered publicly nowhere to my knowledge, huge deal, API is mostly irrelevant here, can't fucking wait holy shiiit.
Please do the directx API after opengl......Directx is a very good SDK...It would be better to implement it at first.....
DirectX is a good way to transition to Vulkan
Im ur first viewer
first