Around 15:45 you are passing the uniform vec4 i.e. the colour into a shader that is not yet bound, because it is bound in the Renderer::Submit, which is called after. It apparently works anyway in this configuration, but OpenGL (glGetError) actually reports Invalid Operation (GL_INVALID_OPERATION). Of course this gets "fixed" down the line with the proper implementation, but I find it interesting/noteworthy that the state machine still works.
@19:31 This depends on what rendering pipeline you're implementing. Sure, in a deferred renderer, it wouldn't make much sense to include any lighting information since that will be a separate pass later in your pipeline. However, if you've written a forward renderer, then it absolutely would make sense to include lighting information for your material.
Just a thought, but I think it would be pretty cool if you would sometimes, especially when explaining concepts, draw comparisons with your design approach vs. other engines like Godot. I'm always really interested to learn about the thought process behind engineering decisions made due to constraints like amount of developers, budget, etc.
@@richardlighthouse5328 yo ofc 3D > 2D, but as iHelp said plus we are learning so we might as well learn 2d stuff from the best teacher and its fun mostly so yeah
@@syne1456 In my opinion, wrapping your head around 2D is easy as pie, but 3D in other hand is very difficult, you got things to worry about, mainly performance.
I'd say do 2D first, then start with the other core components such as ECS, messaging/event system, serialization/file format/loading/saving. While getting 3D up and running would be nice and impressive, there isn't much else you can do just with that, hence I'd rather see the other core components first :D
//Not A Vote but a Note!\\ Everyone is here to learn Game Engine development, but following tutorials while being a newbie potato in Game engine development, it is very depressing to follow them for 9 months or so and get a triangle with few blocks on the screen. Of course most of us want 3D renderer because it’s cool and interesting, but if he was to do 3D renderer first, it would probably be few more months of a shaded ball or something. If he made a 2D Renderer, we could already make games and experiment, and after few more episodes, he would still cover 3D rendering. I’d say be patient and see moving 2D images that you drew and programmed them to move and after that get your prize and create a 3D renderer! At least it won’t be as depressing to work when you have results.
You seem to be missing the point of these tutorials. These tutorials won't teach you how to make games, more or less they'll teach you the concepts behind the stuff happening under the hood of a game engine, example based. If your goal is to make a game, I'd recommend you try either Unity, Unreal or Godot instead of trying to make your own tech. A game engine requires A LOT of work, and if you're all by yourself you won't create a production ready game engine from scratch, as a beginner, anytime soon. It never hurts to try though, you'll learn either way :D
I think it would be good to complete the 2D renderer first and polish the engine around 2D rendering, so we can have an overall look of a working engine (at least the 2D compartment) and how each component interact with each other. After that we can move on to 3D rendering.
I agree with some other comments here, 3D renderer should be the main focus of this series. It is really unique that we get to see all the concepts and ideas that go behind a 3D game engine. From the little preview of the private development branch we saw in a previous video, I believe it looks really amazing and I hope this series goes towards there. A 2D renderer could be like a separate "branch" series from this one, after the 3D renderer gets to a certain point.
Bill Vardouniotis Either of ways he will do both. So why not create a 2D renderer first so you can start developing 2D games or at least experimenting and then a 3Dd renderer which will take a lot of time?
I have a question, So some of the material will require a certain order and result of some of them will be needed on the next ones. How we can achieve this ? As an example we have shadow pass that it's result is used in lighting passes as well.
I would love to start making 2D games first, As he said, 3D will come later. If 2D renderer won’t take long to do, then what’s the point of making 3D renderer, spending way more time and throughout making 3D renderer and stuff you can’t really make any games.
Kevin Lackó Kevin Lackó Kevin Lackó I am here to learn Game engine development and actually using the engine. What’s the point of learning the engine development and not really putting it to use? Also, I do already use engines like Unity and Gamemaker and Godot or frameworks like Monogame for Gamejams and such but I prefer making tools and backend for games, that’s the main reason I am following these tutorials. But just saying, If you are making something for this long, you want to find a use for that.
Very nice video! Thank you, man :) Regarding your question: Fully functional 3D renderer would be much better. Looking forward to the scripting integration with the engine,. Do you have plans for it?
configure the pixel shaders (textures) only run on the output screen buffer after all geometry (flat shaded) vertex shaders have run, a-synch prefetch discard is possible to get shaders/materials before the whole image has finished, most should be fetched in second pass, for detail pass
You're probably thinking about Deferred Shading which a lot of games use, but do note that it has it's own entire set of drawbacks. Not least that it makes it near impossible to have per material custom shaders
@@TheMrKeksLp nothing is impossible, I just describe a process how it should be made, not trying to match what is currently being used, or current mistakes, that have been made
@@CalSeedy yes it's essentially the same thing. Rearranging the equation: x % 2 = y % 2 ('programming' syntax) x = y (mod 2) (math syntax) x - y = 0 (mod 2) x + y = 0 (mod 2) (x + y) % 2 = 0 ('programming' syntax) The second to last step can be done because any negative integer is equivalent to it's positive version mod 2
You mentioned querring uniform positions. Which is better: this aproach or using an uniform buffer object ? The latter seems easier to implement much more efficient and convinient but I might be wrong.
I have a suggestion why not split the game engine series into multiple playlists like a playlist for rendering only other for events and engine architecture and etc i think this will help you a little bit in the future
My vote for 2D is by far in the minority, and last time you asked it was pointed out in the comments that you already did 2D with Sparky. But I want to see 2D first. I'd like to see how you would do it differently now. It may only be a minority, but it's still a lot of people that want to have 2D and be able to have something functional now. Also, a firm grasp (or refresher) on 2D could help a lot of people who haven't gone through the Sparky videos or anything similar. But this is all just my thoughts on the matter, and whatever you do, I'm sure it will be great.
I have tried mapping Uniform locations on a few different occasions in the past using unordered_map, std::map, etc but every time without fail it resulted in noticeably worse performance instead of getting the location every frame from the GL call. An explanation of a system that is capable of getting our Uniform locations ahead of time while still making it user friendly to set the values of our Uniforms would be great. Nothing I have tried to Map my Uniforms name to a value result in anything that can out perform glGetUniformLocation.
@@hayabusa1x Yeah, maps are just inherently not the best at performance. For a key/value pair they are better than many things for what they are but they are not good for performance and generally not the sort of thing you are going to want to do every frame. You are best off setting up your Uniform, getting the uint handle to it and using that from that point on than you are attempting to use the string or c-string version of that uniform. Of course, by all means try it for yourself, your mileage my vary and if you can get the map to perform anywhere near getting the uniform by all means but I personally suspect the Driver is simply caching this value and returning it to you in subsequent calls meaning directly calling it results in no huge performance issue at all and is simply asking for an integer from the driver.
@@seditt5146 Sounds like the reasonable thing for it to do. I actually added a map to my shader class for caching the uniform locations but never finished implemented it as it wasn't ever an issue for my small project. I have however recently come by the knowledge that maps are not good for performance due to it being linked lists under the hood, and having to search through the list to find keys that could be in different memory locations causing a lot of cache misses. I recently implemented a stupidly simple version of a map that uses a vector to store elements, and I'll do a performance test when I get the time.
@@hayabusa1x Ah, something to note, the map you said you made using a vector, Benchmarks all around have shown, due to cache coherency, that as long as you have relatively few key/value pairs to search through you are better with a basic linear search than using any form of a match. We are talking like 10-20 elements though because the cons of the linear search start to appear heavily. I tried it and got different results but its more due to my awful implementation at the time of string comparison and not so much good linear and key/value pair searching on smaller arrays.
@@seditt5146 It is just a linear search over all the keys and doing a comparison: a string comparison is the only use case I have of it, I haven't bothered to do any kind of hashing yet. The current use case is checking an asset database to see if a mesh/animation/texture has already been loaded, and if so getting a pointer to that asset, otherwise load it and add it to the database. I'm using the file name as the key, hence the string comparison. The container actually has two vectors, one for the actual data, the other a pair of key type and index to an element in first vector. So when it searches it only goes through the key/index list to see if there's a match. It's pretty naive like I said. The goal of the current project is to implement a streaming system so at some point I'll add a load of assets and have something to test it with.
Do you expect it to just happen magically? Obviously there are different techniques to minimize draw calls, like instancing but that might not be ideal in all situations. There are different rendering techniques, but at the end of the day the information needs to be passed to the gpu somehow. Draw calls aren't as bad as some make them sound, obviously doing as much as possible at the same time on a gpu is gonna result in better performance but don't dedicate all your energy to remove every possible draw call ever.
I've been watching the series from the beginning, not only do think it's high quality, but it's unique in many aspects. Some of the unique aspects are that this series includes modern C++ and which renders 3D graphics. I've been doing game programming for a while now, I think making a 2D game (or engine) is a doable and easier task with today's tools. Furthermore, 2D I think doesn't really require C++ and can be done other languages like Java, C# or Python as the performances requirements are generally not as high. So the scope is much wider for making 2D games. Whereas 3D seems to be more limited to languages that can offer that performance. So with that said, I would highly recommend this series focus on a strengthen the 3D rendering and other 3D aspects, before focusing on 2D.
Everyone is here to learn Game Engine development, but following tutorials while being a newbie potato, it is very depressing to follow them for 9 months or so and get a triangle with few blocks on the screen. If he was to do 3D renderer, it would probably be few more months of a shaded ball or something. If he spent a few episodes on 2D Renderer, we could already make games!
@@iHelpOfficial Creating 2D Renderer alone doesn't mean that you have an engine that's ready to make 2D games. Far from it. In 2D you still need some kind of sprite system (characters, buttons and other assets), how do these sprites interact with each other, probably need some kind of physics system. Sounds and music, need some kind of audio system. If the game is multiplayer, probably need some of network socket system for that. If the game is persistent, most likely need a database system or database connection. AI also needs to be considered. I wouldn't be depressed, the reason why so much time was dedicated to the code was that he wanted to focus on the API and get the foundations of the code right. He mentioned this several times.
If you do a 3D game engine PLEASE PLEASE PLEASE can the engine auto generate optimal lightmaps or better have no lightmapping, because UDK makes you do it manually, and that is something no human should have to do. Texture UVs are already too much.
Theres already a good 2D renderer in Sparky, and there's also a big playlist, which covers everything you might need. So why repeat what u already did before?
I love the dedication to get these videos out, even though your not in the best situation to do so.
Keep up the good work! 👍
Around 15:45 you are passing the uniform vec4 i.e. the colour into a shader that is not yet bound, because it is bound in the Renderer::Submit, which is called after. It apparently works anyway in this configuration, but OpenGL (glGetError) actually reports Invalid Operation (GL_INVALID_OPERATION).
Of course this gets "fixed" down the line with the proper implementation, but I find it interesting/noteworthy that the state machine still works.
@19:31 This depends on what rendering pipeline you're implementing. Sure, in a deferred renderer, it wouldn't make much sense to include any lighting information since that will be a separate pass later in your pipeline. However, if you've written a forward renderer, then it absolutely would make sense to include lighting information for your material.
Focus on 3D! Thanks for all of your hard work. I'm really enjoying this series.
I am probably the only one that still loves to watch his old java videos lmao.
Nope, me too
I am mostly here for the bunny but thank you for this material systems intro
3d, thanks for the series btw
Just a thought, but I think it would be pretty cool if you would sometimes, especially when explaining concepts, draw comparisons with your design approach vs. other engines like Godot. I'm always really interested to learn about the thought process behind engineering decisions made due to constraints like amount of developers, budget, etc.
Gogot shill.
You are an inspiration. Thank you so much for this series. Just choose whatever you feel it's going to be better.!
i think it would be good to go for the blazing fast 2d renderer imo, just to scale the engine more, no need to rush to 3d this fast!
3D > 2D
MemesTV Yeah but you could already make games with 2D renderer and it would take way less time to make. And he would do 3D later
@@richardlighthouse5328 yo ofc 3D > 2D, but as iHelp said plus we are learning so we might as well learn 2d stuff from the best teacher and its fun mostly so yeah
@@syne1456 In my opinion, wrapping your head around 2D is easy as pie, but 3D in other hand is very difficult, you got things to worry about, mainly performance.
Yep I agree. I would want to see results faster just so that I'm not gonna lose interest.
This is an amazing series! THANK YOU!!!
Since the Sparky Engine series already focused on 2D at the beggning, maybe it'll be more appropiate for this one to start on 3D
I'd say do 2D first, then start with the other core components such as ECS, messaging/event system, serialization/file format/loading/saving. While getting 3D up and running would be nice and impressive, there isn't much else you can do just with that, hence I'd rather see the other core components first :D
Continue with 3D 👏
I say Full 3D Rendering!
//Not A Vote but a Note!\\
Everyone is here to learn Game Engine development, but following tutorials while being a newbie potato in Game engine development, it is very depressing to follow them for 9 months or so and get a triangle with few blocks on the screen. Of course most of us want 3D renderer because it’s cool and interesting, but if he was to do 3D renderer first, it would probably be few more months of a shaded ball or something. If he made a 2D Renderer, we could already make games and experiment, and after few more episodes, he would still cover 3D rendering. I’d say be patient and see moving 2D images that you drew and programmed them to move and after that get your prize and create a 3D renderer! At least it won’t be as depressing to work when you have results.
You seem to be missing the point of these tutorials. These tutorials won't teach you how to make games, more or less they'll teach you the concepts behind the stuff happening under the hood of a game engine, example based.
If your goal is to make a game, I'd recommend you try either Unity, Unreal or Godot instead of trying to make your own tech. A game engine requires A LOT of work, and if you're all by yourself you won't create a production ready game engine from scratch, as a beginner, anytime soon. It never hurts to try though, you'll learn either way :D
I would love to see (blazing fast) 2D rendering done first :)
I think it would be good to complete the 2D renderer first and polish the engine around 2D rendering, so we can have an overall look of a working engine (at least the 2D compartment) and how each component interact with each other. After that we can move on to 3D rendering.
i agree !!!
I am all in for 2D! By understanding that 3D renderer will take a lot longer than 2D, It can wait! I want to create something!
GR00G0 True, but what about sprite batching? I don’t think that it is done in 3D renderer
Let's welcome bunny back!
I agree with some other comments here, 3D renderer should be the main focus of this series. It is really unique that we get to see all the concepts and ideas that go behind a 3D game engine. From the little preview of the private development branch we saw in a previous video, I believe it looks really amazing and I hope this series goes towards there. A 2D renderer could be like a separate "branch" series from this one, after the 3D renderer gets to a certain point.
Bill Vardouniotis Either of ways he will do both. So why not create a 2D renderer first so you can start developing 2D games or at least experimenting and then a 3Dd renderer which will take a lot of time?
I have a question, So some of the material will require a certain order and result of some of them will be needed on the next ones. How we can achieve this ? As an example we have shadow pass that it's result is used in lighting passes as well.
3D >>>>>>>>>>>
Material should be a component of game objects that have renderable components.
I would love to start making 2D games first, As he said, 3D will come later. If 2D renderer won’t take long to do, then what’s the point of making 3D renderer, spending way more time and throughout making 3D renderer and stuff you can’t really make any games.
If I wanted to make a game I'd just use Unreal instead. I'm here to learn how a 3D Game Engine works under the hood.
Kevin Lackó Kevin Lackó Kevin Lackó I am here to learn Game engine development and actually using the engine. What’s the point of learning the engine development and not really putting it to use? Also, I do already use engines like Unity and Gamemaker and Godot or frameworks like Monogame for Gamejams and such but I prefer making tools and backend for games, that’s the main reason I am following these tutorials. But just saying, If you are making something for this long, you want to find a use for that.
2D or not 2D? That is the question! (3D gets my vote)
i was waitin to say zis fo long i dono wy zis long bu, man! ur hand gesture is killin me bro, u gud tho
Why MaterialRef is created with new? Ref reminds me of a reference, not a pointer.
thanks!!!
Very nice video! Thank you, man :)
Regarding your question: Fully functional 3D renderer would be much better.
Looking forward to the scripting integration with the engine,. Do you have plans for it?
oh yeeeeee, finally
configure the pixel shaders (textures) only run on the output screen buffer after all geometry (flat shaded) vertex shaders have run, a-synch prefetch discard is possible to get shaders/materials before the whole image has finished, most should be fetched in second pass, for detail pass
I mean fetch the high detail pixel shaders only for the actually displayed pixels, low detail for all scene materials, like the mesh-shading technique
You're probably thinking about Deferred Shading which a lot of games use, but do note that it has it's own entire set of drawbacks. Not least that it makes it near impossible to have per material custom shaders
@@TheMrKeksLp nothing is impossible, I just describe a process how it should be made, not trying to match what is currently being used, or current mistakes, that have been made
if (x % 2 == y % 2)
can be used to make a checkerboard pattern
alternately
if ((x + y) % 2 == 0) blah
else other blah
@@CalSeedy yes it's essentially the same thing. Rearranging the equation:
x % 2 = y % 2 ('programming' syntax)
x = y (mod 2) (math syntax)
x - y = 0 (mod 2)
x + y = 0 (mod 2)
(x + y) % 2 = 0 ('programming' syntax)
The second to last step can be done because any negative integer is equivalent to it's positive version mod 2
I think that it would be a lot easier to understand the concepts related to how things are rendered (Specifically in OpenGL) with the 3D rendering.
You mentioned querring uniform positions. Which is better: this aproach or using an uniform buffer object ? The latter seems easier to implement much more efficient and convinient but I might be wrong.
thanks cherno,later learn cpp and opengl,i'm continue,if i can use visa,i must support you by $.
Full 3D please
I have a suggestion why not split the game engine series into multiple playlists
like a playlist for rendering only other for events and engine architecture and etc
i think this will help you a little bit in the future
My vote for 2D is by far in the minority, and last time you asked it was pointed out in the comments that you already did 2D with Sparky. But I want to see 2D first. I'd like to see how you would do it differently now. It may only be a minority, but it's still a lot of people that want to have 2D and be able to have something functional now. Also, a firm grasp (or refresher) on 2D could help a lot of people who haven't gone through the Sparky videos or anything similar. But this is all just my thoughts on the matter, and whatever you do, I'm sure it will be great.
i made a matierl system that loads a json file to build an object that i pass to a fragment/pixel shader. a material system assists with shader input.
I have tried mapping Uniform locations on a few different occasions in the past using unordered_map, std::map, etc but every time without fail it resulted in noticeably worse performance instead of getting the location every frame from the GL call. An explanation of a system that is capable of getting our Uniform locations ahead of time while still making it user friendly to set the values of our Uniforms would be great. Nothing I have tried to Map my Uniforms name to a value result in anything that can out perform glGetUniformLocation.
Really? Interesting.
@@hayabusa1x Yeah, maps are just inherently not the best at performance. For a key/value pair they are better than many things for what they are but they are not good for performance and generally not the sort of thing you are going to want to do every frame.
You are best off setting up your Uniform, getting the uint handle to it and using that from that point on than you are attempting to use the string or c-string version of that uniform.
Of course, by all means try it for yourself, your mileage my vary and if you can get the map to perform anywhere near getting the uniform by all means but I personally suspect the Driver is simply caching this value and returning it to you in subsequent calls meaning directly calling it results in no huge performance issue at all and is simply asking for an integer from the driver.
@@seditt5146 Sounds like the reasonable thing for it to do. I actually added a map to my shader class for caching the uniform locations but never finished implemented it as it wasn't ever an issue for my small project.
I have however recently come by the knowledge that maps are not good for performance due to it being linked lists under the hood, and having to search through the list to find keys that could be in different memory locations causing a lot of cache misses. I recently implemented a stupidly simple version of a map that uses a vector to store elements, and I'll do a performance test when I get the time.
@@hayabusa1x Ah, something to note, the map you said you made using a vector, Benchmarks all around have shown, due to cache coherency, that as long as you have relatively few key/value pairs to search through you are better with a basic linear search than using any form of a match. We are talking like 10-20 elements though because the cons of the linear search start to appear heavily. I tried it and got different results but its more due to my awful implementation at the time of string comparison and not so much good linear and key/value pair searching on smaller arrays.
@@seditt5146 It is just a linear search over all the keys and doing a comparison: a string comparison is the only use case I have of it, I haven't bothered to do any kind of hashing yet. The current use case is checking an asset database to see if a mesh/animation/texture has already been loaded, and if so getting a pointer to that asset, otherwise load it and add it to the database. I'm using the file name as the key, hence the string comparison. The container actually has two vectors, one for the actual data, the other a pair of key type and index to an element in first vector. So when it searches it only goes through the key/index list to see if there's a match.
It's pretty naive like I said. The goal of the current project is to implement a streaming system so at some point I'll add a load of assets and have something to test it with.
is renderer::submit called for every object every frame? that's a lot
Ideally I think it won't be like that. I think the idea eventually will be to have as few calls as possible but I'm learning just like you
Do you expect it to just happen magically? Obviously there are different techniques to minimize draw calls, like instancing but that might not be ideal in all situations. There are different rendering techniques, but at the end of the day the information needs to be passed to the gpu somehow. Draw calls aren't as bad as some make them sound, obviously doing as much as possible at the same time on a gpu is gonna result in better performance but don't dedicate all your energy to remove every possible draw call ever.
@@sablanex Doesnt the gfx card deal with all that lifting?
Is this george hotz v2?
2D first!
Can we write unit or integration tests for the engine?
Continue with 3D
awesome! please don't forget to update git repository, last commit is for 19 days ago. and oh yea please let's go with 3D stuff.
Go 3D
That's interesting
Complete 3d renderer first
I've been watching the series from the beginning, not only do think it's high quality, but it's unique in many aspects. Some of the unique aspects are that this series includes modern C++ and which renders 3D graphics. I've been doing game programming for a while now, I think making a 2D game (or engine) is a doable and easier task with today's tools. Furthermore, 2D I think doesn't really require C++ and can be done other languages like Java, C# or Python as the performances requirements are generally not as high. So the scope is much wider for making 2D games. Whereas 3D seems to be more limited to languages that can offer that performance. So with that said, I would highly recommend this series focus on a strengthen the 3D rendering and other 3D aspects, before focusing on 2D.
Everyone is here to learn Game Engine development, but following tutorials while being a newbie potato, it is very depressing to follow them for 9 months or so and get a triangle with few blocks on the screen. If he was to do 3D renderer, it would probably be few more months of a shaded ball or something. If he spent a few episodes on 2D Renderer, we could already make games!
@@iHelpOfficial Creating 2D Renderer alone doesn't mean that you have an engine that's ready to make 2D games. Far from it. In 2D you still need some kind of sprite system (characters, buttons and other assets), how do these sprites interact with each other, probably need some kind of physics system. Sounds and music, need some kind of audio system. If the game is multiplayer, probably need some of network socket system for that. If the game is persistent, most likely need a database system or database connection. AI also needs to be considered.
I wouldn't be depressed, the reason why so much time was dedicated to the code was that he wanted to focus on the API and get the foundations of the code right. He mentioned this several times.
3D
Hai bro, I have a simple question when will you start using the game engine to make some games?
i’d prefer 2D Renderer. I want to create something and get used to developing on this engine and then do 3D
x & 1 better than x % 2
2D first Please
If you do a 3D game engine PLEASE PLEASE PLEASE can the engine auto generate optimal lightmaps or better have no lightmapping, because UDK makes you do it manually, and that is something no human should have to do. Texture UVs are already too much.
3D plz
first
No shit
omg you're getting old
It's just beard lmao😂
Theres already a good 2D renderer in Sparky, and there's also a big playlist, which covers everything you might need. So why repeat what u already did before?