Thanks for watching! What do you want to see next? Don't forget you can try everything Brilliant has to offer-free-for a full 30 days - visit brilliant.org/TheCherno. The first 200 of you will get 20% off Brilliant’s annual premium subscription!
Regarding the sprite array...the memory won't be contiguous because the vector is a vector of sprite pointers. Also, if you're using indices and inserting and removing sprites in the list, you'll have to update all relevant indices which is about the same complexity as recursively processing them. If you store actual sprites in the vector rather than pointers then you'll hit up against other issues such as not being able to use different sized sprite objects and extra copy details for inserting and deleting. Using indices would also mean that it's harder for a sprite to examine its parent (or children) because now it'll need a reference to the vectors /and/ the index number into the vector - rather than just a pointer. Not saying which one is better or worse, it's all down to trade-offs. Just pointing out that using indices comes with it's own set of concerns.
TheCherno, IMO, a series of videos explaining the details of setting up for a big project. How to organize solutions, modules, and so forth. It wouldn't need a real project because I think the extra details of a real project distracts from the information we need.
Hello Man! i just wanna ask you that can you create a Series for Physics Programming as I am currently working on a Game Engine Project in which I am stuck in physics programming stuff. I checked out youtube etc but I didn't find anything useful neither a documentation nor any sort of hands on tutorial, can you help the guys like me by creating a short series of Physics Programming?
I would love to see a series of game engine 'basics' or 'essentials' that doesn't necessarily show how to build a full engine but build or show the concepts (EG. Scene systems, best code structure practices, world vs local transforms) so we can take the knowledge and build.on it in our own way, even just as another point of view
@@itkutyaHe's already has a Game Engine series, that shows all of this and a lot more. I'm kinda surprise that Cherno sometimes still uploads new streams on Game Engine series.
@@KennyTutorialsYou missed the point, somewhat. It's not about how to build the engine in 40 hours of streams, but rather what the main "20 pillars" of the code structure should be, for example. As in, said video could be just 20 minutes long but cover whole engine. His engine series goes into details.
@@GonziHere Just git gud? You want everything on a silver platter in a 10min video when theres 200hours of game engine videos? YOU WANT A TIK TOK MAYBE BUDDY?
Don't rush these videos, we're getting more used to everything happening in an instant. Creators usually follow that flow, so long form and thorough content such as yours is increasingly difficult to find. You will find resistance from the audience, but the value of your resources are incredible
I’m developing an entity/component based C++ engine myself and am pretty chuffed that I already have most of Cherno’s suggestions in place. JSON scenes and prefabs, plus a JSON project file to define them, with a bit of code generation at compile time works really well for me. You’ll have to pry ‘this->’ from my cold, dead hands though, I use it all the time :D Edit: being able to add/modify scenes, entities and components without re-compiling is a really cool side-effect.
I was also used to "this->" in the past bcs I was not using the "m_" convention for member variables, but actually using "m_" is wayyyy better, and you avoid using "this->" because you will not be able to clash with parameters variables when using "m_".
@@whoshotdk I'm doing the same, I think it makes easier distinguish a variable from a parameter. Even if technically nowadays with IDE like VS, Rider etc... there is a different color code for both, I just prefer this way too. It's also bcs it's a remanant of me of the past lol When I was not using "m_" convention ending doing thing like this in a constructor: blahblah(int test) { test = test } So solved the issue by prefixing with an underscore lol blahblah(int _test) { test = _test }
For the last month I've been dissecting an old engine that is falling into deprication... Because I wanted a scene manager it's DLL Entry point.. it also has a nice system for interchanging the gfx libs, gui, etc.... so glad to see this video reinforcing how good of an idea this was ... Building that whole system from scratch would be a nightmare but I don't put my projects in the same solution because IDE loading time. I'll use it like any other dependency
This video shows the horrors of memory management everybody forgot about... lol... What I believe he tried to was essentially impliment his own deallocator manually. Which is fine. The problem is he tried to do it through a bunch of convoluted parent-child and entity based child structures. This is really hard to manage and error prone. If you want to structure you data this way, RAII (hate the name, Resource Aquisition Is Initisation) was meant to solve this exact problem. Basically, its an implicit scope destructor, you write a destructor and when the code block or statement ends the destructor will call itself, starting with child classes first to prevent invalidation. Alternatively, do you can what Cherno said in the video and just has a flat 1D list (array-like) of every resource of a given type allocated and just iterate over the list and call those deallocates. Alternatively. Use an arena-allocator style structure and keep every object relevant within its own arena. When it comes to deallocate, if everything in that class is irrelevant (ie, scene data). you can just snap the whole list to dust. Deallocate everything without calling functions. Make sure to delete the class destructor if you do this. (~my_class() = delete)
A vector of trees (represented as the root node) is a terrifying data structure indeed. And if you ARE going to walk a tree, you want to consider whether using the visitor pattern is a good idea. Also worth considering is if it's not a huge structure, and performance is less of a concern, using std::optional for parent/child relationships might make sense (it certainly makes encoding the "none" state more type safe).
Developing a game engine is my passion of all the time. During my journey of studying all those concepts and stuffs, I have learned a lot from you and there is a lot to learn as well. Your channel means a lot to me. Thank you for sharing your knowledge with others in this kinda platform... ❤
Hello, thanks so much for the 3rd episode of my engine!!! So i actually manage all the sprites in this single vector, i just did this addChildsToDelete stuff, because i would get a bug when deleting the parent because i didnt save how many sprites i deleted and then the vector gets out of range. So just storing all pointers to delete in a list and then iterating over the list and deleting them doesnt produce any bugs And for the scene system - yes this is SO WIERD and you cant also add any scenes to the game in runtime. Im gonna probably rewrite this system, and the idea with the project file is amazing, i never thought about something like that! And also you need to build the Assets project which got copied manually - (by hand :( sorry) Thats why you couldn't hit play in the editor. (There was actually a debug message in the console) And another bad design thing is the default.png its stored in the engine ressources and not in the assets project so when you actualy run the game and have the default.png in a sprite of your game it will not be rendered. So please change it to any sprite you want but not the default.png. You can drag and drop a png image in the sprite renderer. (this is because the editor used to edit only 1 game, and i just forgot to move the default.png into the template project) And the UI - I dont really know why that happened. I tried it only on 1920 * 1080 , and yes it does only work properly on 1920 * 1080 (bad design, i know i know). And you can click on these arrow to resize the ui windows 21:52 - What is these???, i busted out laughing in school Im hyped for the next episode!!!
hey can I just appreciate how well you are taking his constructive criticisms. Back in high school, I wouldn't even be able to comprehend half of the work you've done. I hope you're proud of your accomplishments and keep up the awesome work. That being said, I'm looking forward to The Roast of The 2000 Hour Game Engine Part III :)
I'm halfway through my 20s now, and so far I've had a youth full of big ideas but only occasionally any actual work on (smaller) projects... I have never been able to stick with something serious for that many hours, dude. Closest thing is my playtime in KSP and Minecraft back when I was in HS 😅 (no regrets tbh, just wish I'd've been recording or streaming or something lol). Anyways, the point is; serious props to you for being able to put in so much work on this! Even when you inevitably move on to future projects, keep up that skill of knowing how to stick to the good ones!
@@revenevan11 I appreciate that alot man!!!!! I love programming, and minecraft (i actually have double the playtime in minecraft) and it motivates me alot when someone writes this. Thanks dude
Another time this-> is useful is when you need a dependent type resolution and the type name is too long. I don't know if every compiler supports it that way, but it's really nice.
What is missing from your suggestion to use a flat list with indices is how to dynamically add or remove a sprite to/from any place in the hierarachy of parent-children.
Well, adding is easy. You just add it to the end of the vector and change the indices on the parent and children like you would with a normal tree. But removing is more difficult for sure, since you don't want to change any of the indices in the array. Probably you just mark as invalid and then do a clean-up every so often where you remap all the indices to their new positions? IDK sounds messy.
@@APaleDot Yes it was really messy, and actually all the sprites in the scene are in the m_sprites vector including the childs. SO what i did was i added all the childs to a list which should get deletet (iterating over the the sprite tree recursive) and then iterating again over hte list which sprites need to be deletete,
I imagine the sprite list would be static, for each scene, when ran as an actual game. When editing, the editor could have a singular null sprite defined that replaces the value at those deleted indices. That way the editor could leave the clean-up to the clear() done during the scene change and just save those sprites that aren't the null sprite. Another alternative is to turn the deletion into a hiding of the sprites by setting the parent index to -2 or something. That way you could allow for an undo of sorts by having a toggle for showing deleted sprites in some list.
Regarding the tree-vector discussed from 21:52 and onward. Having an index to a vector of stuff in a child adds a lot of indirection to the lookup of the child item. A child would need a reference to the storage vector and each lookup would need to call the [ ] operator. In this case, provided the tree-structure is indeed necessary, the proper way to do it is to separate concerns: 0. Have each 'parent' hold all of the 'children' by pointer, but not _manage_ their memory. This removes the indirection. 1. Have a storage/allocator class which makes sprites and holds a reference to them for the duration of the game session. Once a loading screen/scene change occurs, this class just deletes all the stored sprites. 2. Have a flat list of sprites to iterate through, if an operation is done on all of them. 3. Have a tree structure for doing operations which require such access. 4... and have another structure organized in whatever manner is necessary to provide the functionality needed. This pattern would also allow to pool sprites by the allocator for reuse to avoid costly memory allocation, filesystem access for resources and so on.
Looking to the solution as you suggested, you will discover that the contiguous solution is not as easy as it sounds. Inserting, deleting will destroy the whole concept of having flat index for parents. Let us suppose that index 20 has 4 children. you have hundred of items after no.20 .. Removing obj 20 will cause a shift of the whole indexes. Or you have to make it invalid (for ex -1) and later you will get fragmentation and you need to fix them. Fixing the fragmentation will cause that you have to shift the whole vector and their children data about parent. Let me know if I am wrong but that is what I feel. This is not so good .. How would you do it? otherwise? Note: I suppose you use vectors position as index .. another solution would be to generate separate unique ID (ID generator class maybe).
Yeah you never want to be in a position to shift elements of a vector if something is deleted, instead replace it with the last value. This does bring up the index problems you described. Instead of using indexes for children you can still use pointers, it's just that the parent doesn't OWN the child pointer, the main vector does. This makes deletion and addition easy, and parents would not have to recursively delete children. I would also recommend having a parent reference in the child so that if a deletion occurs you know exactly which parent should stop referencing it
@@RIK0-1 I would just use a linked list in this case, that way nothing will get shifted. also there should be a parent class in which you have a vector of children stored and that parent class should contain a function to delete all the children.
I only disagree that "tree structure" is a bad thing and you should store all the nodes in one flat array, but overall yes, this engine has a lot of bazaar decisions, however the author anyway did a great job, keep going buddy!
It's a performance thing. Contiguous memory can make your code literally multiple times faster. Working with sprites is too important not to do it. That's why game engines use an ECS (Entity Component System).
public: I never fail to leave a video without having learnt something and/or thought about trying something a bit different that may make my work flow better. I look forward to watching your educational videos, which says a lot because I only watch other peoples educational style videos when I seek them out for something specific. private: This is why you are awesome and honestly a gifted educator. Never change.
Question: while criticizing the sprite data structure (list vs tree), you say that you’d choose the data structure based on your use-case. In this case what you’ll do most with these sprites is to linearly update them and linearly render them. You then proceed to explain how to reconstruct or store the hierarchical tree information in the elements stored in the list using parent/child indexes and mention that having this information is important to reconstruct the world transform. I’m not a game or engine developer, so excuse me if this is a stupid question, but doesn’t this imply that you cannot actually linearly render these sprites but that you do need to hierarchically walk the tree structure (to build the correct world transform per sprite) when rendering them? I’m assuming that you need that information to actually render every individual sprite.
Not an expert here, but even there, you'd probably loop over all sprites one after another to render only those you want in with the transforms you calculate. The tree relationship is definitely important. However, it does not mean the underlying data has to be physically saved as a tree. Having a contiguous block of memory where all the data resides is a good idea, and implementing the tree relationships via indexing into this array is trivial.
Directly concerning your question: You can allso store the world position in each sprite. That way, when you are going through the list, you don't need to go looking for any external information. Having to recompute the world-position each frame seems like a lot of work that could potentially grow even worse depending on how deep your sprite-tree is. When updating relative positions it is probably easier to compute the absolute position as well and just keep the information around. Since most sprites will likely never change their position it's better to store it (for them specifically) as well. When rendering you don't want to jump all over memory and pay for the cache miss, which you will avoid this way. So you have an ideal path for rendering from the perspective of memory layout, but can still treat the list as a tree (through the indexes) when that particular access pattern is useful for other stuff.
Like always a cool video 👍 Btw could you make a video explaining Frameworks and how they differ from libraries? It seems the only content out there is trying to explain it so abstract or metaphorical that I don't get the actual difference. Thanks and keep up the great quality of videos
I would love to know how you delete entities in the flat array approach. If you remove them from the array immediately, that changes all the indices and breaks the whole system, so do you have to do a messy clean-up step where you update all the indices in the tree? Is that really simpler?
Depending on how big your entities are, you could just leave them in the array in a de-activated state. Alternatively you could use an indirection to keep keep indices held by the user valid. Or use something like an arena or pool allocator and keep cache coherent that way.
Hi Cherno, great video!! Going back to the sprites vector, if for some reason you deleted a sprite (and its children) how would you go about the 'gaps' in the vector?
That's a problem I had when trying to delete the children. I added all of the child's to a separated vector and then iterate over this vector and deletet the children. So the gap = srites_to_delete.size()
@@y4ni608 And what about the children of some child? Isnt it the same as doing a tree like structure like the one in the video that the cherno critisized?
@@guilhermedabolsa927 I hope i understood your question (my english is kinda bad) So I guess that its stil the same, you need to iterate recursive over it, regardless what you do, but i guess there is a big con when having the childs as indices and not ptrs, because you need to reduce the indices if you remove a sprite from the list for example
@@y4ni608 Yeah, you would need to reduce the indices, unless you dont shift the vector and leave 'gaps' in the array. Doing this way you dont need to recalculate all indices... but you would have a lot of 'holes' in your data... and this goes back to my initial question :v (sorry my english is also kinda bad)
Can you make a video on how to make good C++ modules pls? As a VST-Plugin developer I always have a lot of code I wanna reuse throughout multiple projects. So far I have just copied files around, which is often seen as the most crude approach. I can see why. It takes a long time sometimes to figure out how to integrate copied stuff and it just feels silly to do that when it's not meant to be edited in a project, but just used. So I suppose those "modules" solve that, right? Would be an excellent topic for a video I think. Edit: But just saying: Would be cool if you made an extremely small example project for that and not this entire game engine, to make it easy to see what to do, you know? Just saying because most C++ videos on TH-cam are too basic, where you don't even see what's the point of a certain language feature, but you sometimes are the opposite, where you show things in a too complicated context, which can diffuse the actual point.
That was it?! I was expecting you to keep making a longer video. Your word videos are so helpful. Hopefully you one day accept making a code review on my game engine. I think its core functionality are well designed and part of it is because of you.
Can you teach how to make a game engine with Vulkan and C++ and how to set it up with either GCC or Clang and VSCode because i cant figure it out to save my life
21:45, it's not required to write 'this->', because the 1st thing compiler will look is member data/f()s. 21:52, for a lib or generic code to be used in several projects, I always initialize string with ' = "" ', to avoid UB if the user starts adding things with += operator. getIndexAtName could be public, since it's only meant for information. But the system of converting name to index is slow. Much better is to use 'const int's, like enums, that already give their names. Plus, this prevents typos at compile time.
1:53 I did some axis modeling and scene rotating. This experience is so if you really have to fight about not dropping out of university. I won't fix that math problem, because that is so much math I don't remember since first class until twenty years after graduating so you better use the relation database making tools and then try to dive deeper with that math. Rigid body you might remember, but why you would want to do that if you PowerPoint gets 3 views and as much hours to do it. You won't know that unless you work with headphones - you see other things if concentrating to the task.
Dude, please create a paid course on c++, but better then that, an updated version on all of that setup that we actually cannot learn properly anywhere. I actually learned a lot on your egine series about htat but do not know if still the same.. idk, you make very good content specially because you focus on architecture as well
Sure, public first sounds good, but it's more important to "declare first, use later"... which often will result in private first :) (If any public inline method calls a private method or use a private variable, constant...) The problem is that there are 2 main competing uses cases: 1/ you want to understand how it works (maybe even modify it); 2/ just want to know how to use it. It's important for code to be easily readable. For 1 this means stuff has to be declared before they are used. And this is where the private first comes from. (It's not the goal, or requirement, it's a consequence.) So what about 2? Well in an ideal world this is where documentation comes in handy. If you just want to know how to use it, RTFM :) But even if you just want to use it, it might be helpful to look at the private members, to see at a glance how heavy an object is... so private first... or more importantly data first.
I encourage - don't do that and use already build Laravel/Symfony. Those might have community version and don't have any legal issues about using the model Victoria Secret or anything surfing the waves. So I must begin with this - how am I making an Iskaar fish and cooking it. I try this add some of that. This c++ now possibly is not that RAW as it was ten years ago, but I don't know - it's not a real process about creating animation.
Next video: Reviewing this README video - it sucks! But on a more serious note, where are the comments in the code? Why does the coder need to figure out everything instead of comments indicating the control flow, specially non-obvious ones? Documentation?
the lack of comments wouldn't be so bad, if it wasn't a spaghetti codebase with terrible naming (e.g. `m_sprites` instead of `m_sprites_roots` or `m_sprites_top_level`) if you write code clearly enough, you don't need comments to indicate what are you doing, because it's obvious what are you doing
@@atijohn8135 I have heard this argument before and we can agree to disagree, but I don't subscribe to this school of thought. Comments, and documentation, in general is a design choice, and my design recipe is to provide comments whenever there is unusual control flow (and yes, good naming can minimize it). Also, document what each function takes, does, side-effects, and returns. Sometimes I have had to look at code that I wrote 20 years ago, and good commenting has saved me a lot of hassle.
@@atijohn8135 But cherno misunderstood that, m_sprites are actually all sprites in the scene. And the reason why i didnt write any comments is because i just never really thought that he would review it, and im still a kid who is learning
@@y4ni608 well, my bad, it's still a massive feat that you were able to put this engine together as a kid, though if you want to continue doing this, you need to improve the cleanness of your code
@@agentm10 I have a rule where if I use more than two nested control flow statements, then I will rewrite the code to make it more clean, likely introducing some utility function that I may use again in the future, simultaneously reducing code repetition. It's particularly easy in C++20 and especially C++23, since it now has official support for ranges/views, so for instance instead of writing a for + a nested if statement, you can just write a range for with std::views::filter, and it's more readable to me that way. Also, yeah, documenting functions is a must, but commenting on the code of the function itself is something I usually stray from, because as I said, it should be clear from the function code. Write short, pure, useful functions instead of big ones with a lot of repetition, ninja assignments and control flow, and if you feel like you can't do that, you probably need some utility function to carry you around.
I just noticed TH-cam automatically removed my subscription to your channel. The video appeared in my feed and noticed totally randomly I'm not sub anymore ...
The obsession with OOP over the past 20yrs has really screwed with the idea of pragmatism in code. Once upon a time you had experts in the problem or things to solve who learned to program, and having that intuitive knowledge allowed a better understanding of the approaches to use for each data set or operation, whereas the OOP generation starts with OOP and tries to solve the world with it.
run a mouth course? omg. k.i.s.s. in engineering. if you need to use a separate build system in an IDE, nope. then you have to setup the build system also, build it from scratch. nonstandard use of IDE is not adviced (tm)(r). whoever has to use your code, will be messed up if the code uses a separate build system. instead, make the IDE code compile-able by its own tools.
There is no reason to use Rust over C++ in this case. The language of choice is mostly dependent on what you're comfortable with and what you enjoy. Rust although modern and fancy may not be enjoyable for everyone especially considering the paradigm differences. Also the main benefits of Rust typically come from people who don't understand the quirks of C++ which if you are experienced enough in C++ that should not be an issue. Granted some of the syntax sugars of Rust are nice but too many pollutes a language especially when people rely on them religously.
Thanks for watching! What do you want to see next?
Don't forget you can try everything Brilliant has to offer-free-for a full 30 days - visit brilliant.org/TheCherno. The first 200 of you will get 20% off Brilliant’s annual premium subscription!
could you look at my c vulkan engine next? i've started working on it again.
Hey there Cherno, your visual studio theme looks cool can you please share if possible.
Regarding the sprite array...the memory won't be contiguous because the vector is a vector of sprite pointers. Also, if you're using indices and inserting and removing sprites in the list, you'll have to update all relevant indices which is about the same complexity as recursively processing them. If you store actual sprites in the vector rather than pointers then you'll hit up against other issues such as not being able to use different sized sprite objects and extra copy details for inserting and deleting. Using indices would also mean that it's harder for a sprite to examine its parent (or children) because now it'll need a reference to the vectors /and/ the index number into the vector - rather than just a pointer.
Not saying which one is better or worse, it's all down to trade-offs. Just pointing out that using indices comes with it's own set of concerns.
TheCherno, IMO, a series of videos explaining the details of setting up for a big project. How to organize solutions, modules, and so forth. It wouldn't need a real project because I think the extra details of a real project distracts from the information we need.
Hello Man! i just wanna ask you that can you create a Series for Physics Programming as I am currently working on a Game Engine Project in which I am stuck in physics programming stuff. I checked out youtube etc but I didn't find anything useful neither a documentation nor any sort of hands on tutorial, can you help the guys like me by creating a short series of Physics Programming?
I would love to see a series of game engine 'basics' or 'essentials' that doesn't necessarily show how to build a full engine but build or show the concepts (EG. Scene systems, best code structure practices, world vs local transforms) so we can take the knowledge and build.on it in our own way, even just as another point of view
Yes, this please
@@itkutyaHe's already has a Game Engine series, that shows all of this and a lot more. I'm kinda surprise that Cherno sometimes still uploads new streams on Game Engine series.
@@KennyTutorialsYou missed the point, somewhat. It's not about how to build the engine in 40 hours of streams, but rather what the main "20 pillars" of the code structure should be, for example. As in, said video could be just 20 minutes long but cover whole engine.
His engine series goes into details.
@@GonziHere Just git gud? You want everything on a silver platter in a 10min video when theres 200hours of game engine videos?
YOU WANT A TIK TOK MAYBE BUDDY?
@@EdwardWork-m5t I've written my own engine, I was clarifying the question, buddy ;)
Don't rush these videos, we're getting more used to everything happening in an instant. Creators usually follow that flow, so long form and thorough content such as yours is increasingly difficult to find. You will find resistance from the audience, but the value of your resources are incredible
Maybe not rush it but put effort into keeping the content meaningful. He repeated himself a lot in some of the videos
@@MallchadFair point
I’m developing an entity/component based C++ engine myself and am pretty chuffed that I already have most of Cherno’s suggestions in place. JSON scenes and prefabs, plus a JSON project file to define them, with a bit of code generation at compile time works really well for me. You’ll have to pry ‘this->’ from my cold, dead hands though, I use it all the time :D
Edit: being able to add/modify scenes, entities and components without re-compiling is a really cool side-effect.
I was also used to "this->" in the past bcs I was not using the "m_" convention for member variables, but actually using "m_" is wayyyy better, and you avoid using "this->" because you will not be able to clash with parameters variables when using "m_".
@@K3rhos Fortunately, I have a nasty habit of prefixing all arguments with an underscore lol
@@whoshotdk I'm doing the same, I think it makes easier distinguish a variable from a parameter.
Even if technically nowadays with IDE like VS, Rider etc... there is a different color code for both, I just prefer this way too.
It's also bcs it's a remanant of me of the past lol When I was not using "m_" convention ending doing thing like this in a constructor:
blahblah(int test)
{
test = test
}
So solved the issue by prefixing with an underscore lol
blahblah(int _test)
{
test = _test
}
Dear Cherno, please don't rush it - i really like those videos and deep discussions!
cherno: I was hoping it'd fall
literally right there - gravity=0
😆😆😆
For the last month I've been dissecting an old engine that is falling into deprication... Because I wanted a scene manager it's DLL Entry point.. it also has a nice system for interchanging the gfx libs, gui, etc.... so glad to see this video reinforcing how good of an idea this was ... Building that whole system from scratch would be a nightmare but I don't put my projects in the same solution because IDE loading time. I'll use it like any other dependency
This video shows the horrors of memory management everybody forgot about... lol...
What I believe he tried to was essentially impliment his own deallocator manually. Which is fine.
The problem is he tried to do it through a bunch of convoluted parent-child and entity based child structures. This is really hard to manage and error prone.
If you want to structure you data this way, RAII (hate the name, Resource Aquisition Is Initisation) was meant to solve this exact problem. Basically, its an implicit scope destructor, you write a destructor and when the code block or statement ends the destructor will call itself, starting with child classes first to prevent invalidation.
Alternatively, do you can what Cherno said in the video and just has a flat 1D list (array-like) of every resource of a given type allocated and just iterate over the list and call those deallocates.
Alternatively. Use an arena-allocator style structure and keep every object relevant within its own arena. When it comes to deallocate, if everything in that class is irrelevant (ie, scene data). you can just snap the whole list to dust. Deallocate everything without calling functions. Make sure to delete the class destructor if you do this. (~my_class() = delete)
A vector of trees (represented as the root node) is a terrifying data structure indeed. And if you ARE going to walk a tree, you want to consider whether using the visitor pattern is a good idea.
Also worth considering is if it's not a huge structure, and performance is less of a concern, using std::optional for parent/child relationships might make sense (it certainly makes encoding the "none" state more type safe).
Developing a game engine is my passion of all the time. During my journey of studying all those concepts and stuffs, I have learned a lot from you and there is a lot to learn as well. Your channel means a lot to me. Thank you for sharing your knowledge with others in this kinda platform... ❤
Hello, thanks so much for the 3rd episode of my engine!!! So i actually manage all the sprites in this single vector, i just did this addChildsToDelete stuff, because i would get a bug when deleting the parent because i didnt save how many sprites i deleted and then the vector gets out of range. So just storing all pointers to delete in a list and then iterating over the list and deleting them doesnt produce any bugs
And for the scene system - yes this is SO WIERD and you cant also add any scenes to the game in runtime. Im gonna probably rewrite this system, and the idea with the project file is amazing, i never thought about something like that!
And also you need to build the Assets project which got copied manually - (by hand :( sorry)
Thats why you couldn't hit play in the editor. (There was actually a debug message in the console)
And another bad design thing is the default.png its stored in the engine ressources and not in the assets project so when you actualy run the game and have the default.png in a sprite of your game it will not be rendered. So please change it to any sprite you want but not the default.png. You can drag and drop a png image in the sprite renderer.
(this is because the editor used to edit only 1 game, and i just forgot to move the default.png into the template project)
And the UI - I dont really know why that happened. I tried it only on 1920 * 1080 , and yes it does only work properly on 1920 * 1080 (bad design, i know i know). And you can click on these arrow to resize the ui windows
21:52 - What is these???, i busted out laughing in school
Im hyped for the next episode!!!
hey can I just appreciate how well you are taking his constructive criticisms. Back in high school, I wouldn't even be able to comprehend half of the work you've done. I hope you're proud of your accomplishments and keep up the awesome work. That being said, I'm looking forward to The Roast of The 2000 Hour Game Engine Part III :)
@@ajilpappachan Thanks man, you are really motivating me :D
I'm halfway through my 20s now, and so far I've had a youth full of big ideas but only occasionally any actual work on (smaller) projects... I have never been able to stick with something serious for that many hours, dude. Closest thing is my playtime in KSP and Minecraft back when I was in HS 😅 (no regrets tbh, just wish I'd've been recording or streaming or something lol).
Anyways, the point is; serious props to you for being able to put in so much work on this! Even when you inevitably move on to future projects, keep up that skill of knowing how to stick to the good ones!
@@revenevan11 I appreciate that alot man!!!!! I love programming, and minecraft (i actually have double the playtime in minecraft) and it motivates me alot when someone writes this. Thanks dude
I love the extended takes. Learned a lot from that!
Another time this-> is useful is when you need a dependent type resolution and the type name is too long. I don't know if every compiler supports it that way, but it's really nice.
A use case for ‘this’ is in a lambda capture list
What is missing from your suggestion to use a flat list with indices is how to dynamically add or remove a sprite to/from any place in the hierarachy of parent-children.
Well, adding is easy. You just add it to the end of the vector and change the indices on the parent and children like you would with a normal tree.
But removing is more difficult for sure, since you don't want to change any of the indices in the array. Probably you just mark as invalid and then do a clean-up every so often where you remap all the indices to their new positions? IDK sounds messy.
@@APaleDot Yes it was really messy, and actually all the sprites in the scene are in the m_sprites vector including the childs. SO what i did was i added all the childs to a list which should get deletet (iterating over the the sprite tree recursive) and then iterating again over hte list which sprites need to be deletete,
I imagine the sprite list would be static, for each scene, when ran as an actual game.
When editing, the editor could have a singular null sprite defined that replaces the value at those deleted indices.
That way the editor could leave the clean-up to the clear() done during the scene change and just save those sprites that aren't the null sprite.
Another alternative is to turn the deletion into a hiding of the sprites by setting the parent index to -2 or something. That way you could allow for an undo of sorts by having a toggle for showing deleted sprites in some list.
Regarding the tree-vector discussed from 21:52 and onward.
Having an index to a vector of stuff in a child adds a lot of indirection to the lookup of the child item. A child would need a reference to the storage vector and each lookup would need to call the [ ] operator. In this case, provided the tree-structure is indeed necessary, the proper way to do it is to separate concerns:
0. Have each 'parent' hold all of the 'children' by pointer, but not _manage_ their memory. This removes the indirection.
1. Have a storage/allocator class which makes sprites and holds a reference to them for the duration of the game session. Once a loading screen/scene change occurs, this class just deletes all the stored sprites.
2. Have a flat list of sprites to iterate through, if an operation is done on all of them.
3. Have a tree structure for doing operations which require such access.
4... and have another structure organized in whatever manner is necessary to provide the functionality needed.
This pattern would also allow to pool sprites by the allocator for reuse to avoid costly memory allocation, filesystem access for resources and so on.
Looking to the solution as you suggested, you will discover that the contiguous solution is not as easy as it sounds. Inserting, deleting will destroy the whole concept of having flat index for parents. Let us suppose that index 20 has 4 children. you have hundred of items after no.20 .. Removing obj 20 will cause a shift of the whole indexes. Or you have to make it invalid (for ex -1) and later you will get fragmentation and you need to fix them. Fixing the fragmentation will cause that you have to shift the whole vector and their children data about parent.
Let me know if I am wrong but that is what I feel. This is not so good ..
How would you do it? otherwise?
Note: I suppose you use vectors position as index .. another solution would be to generate separate unique ID (ID generator class maybe).
Yeah you never want to be in a position to shift elements of a vector if something is deleted, instead replace it with the last value. This does bring up the index problems you described. Instead of using indexes for children you can still use pointers, it's just that the parent doesn't OWN the child pointer, the main vector does. This makes deletion and addition easy, and parents would not have to recursively delete children. I would also recommend having a parent reference in the child so that if a deletion occurs you know exactly which parent should stop referencing it
@@RIK0-1 I would just use a linked list in this case, that way nothing will get shifted. also there should be a parent class in which you have a vector of children stored and that parent class should contain a function to delete all the children.
I only disagree that "tree structure" is a bad thing and you should store all the nodes in one flat array, but overall yes, this engine has a lot of bazaar decisions, however the author anyway did a great job, keep going buddy!
It's a performance thing. Contiguous memory can make your code literally multiple times faster. Working with sprites is too important not to do it. That's why game engines use an ECS (Entity Component System).
Good point about having a flat list. Even if it might seem the data is then worse because its seems redundant, it's tipsy-turvy
I prefer using "this" invariably. It makes it much more obvious what it's referring to when reading the code.
Agreed, I've always preferred this because it makes it immediately clear you referring to _this class instance_ specifically.
The irony of saying "I'm the cherno" then you look at the channel's name just to find the same name xd 😂. Old habits, don't worry we're used to it.
Hi Cherno, I would like to you do a video talking about event handling and threads in events handling.
0:15 Wow what kind of jerk would say that
I really would like a video about multi project modulation, may a side by side comparation with Lua and CMake
loved the energy in this video, cherno
Would love to see abit more explanation about sprite storage.
loving your vids. I really like this 2000 code series. LOL. Lots of fun.
I haven't been so excited about a serie since the first season of GoT!
public:
I never fail to leave a video without having learnt something and/or thought about trying something a bit different that may make my work flow better. I look forward to watching your educational videos, which says a lot because I only watch other peoples educational style videos when I seek them out for something specific.
private:
This is why you are awesome and honestly a gifted educator. Never change.
"Path tracing? Yeah yeah, chuck that in to the application! you know what I mean??" lmao that was a great ending
The last part of the video about vector of pointers. Fixing that could literally make the engine runs 100x faster
The thumbnail is fire though😂😂
Loving your vids, man! I’m learning so much from them, and having fun 😁
Question: while criticizing the sprite data structure (list vs tree), you say that you’d choose the data structure based on your use-case. In this case what you’ll do most with these sprites is to linearly update them and linearly render them. You then proceed to explain how to reconstruct or store the hierarchical tree information in the elements stored in the list using parent/child indexes and mention that having this information is important to reconstruct the world transform. I’m not a game or engine developer, so excuse me if this is a stupid question, but doesn’t this imply that you cannot actually linearly render these sprites but that you do need to hierarchically walk the tree structure (to build the correct world transform per sprite) when rendering them? I’m assuming that you need that information to actually render every individual sprite.
Not an expert here, but even there, you'd probably loop over all sprites one after another to render only those you want in with the transforms you calculate.
The tree relationship is definitely important. However, it does not mean the underlying data has to be physically saved as a tree.
Having a contiguous block of memory where all the data resides is a good idea, and implementing the tree relationships via indexing into this array is trivial.
Directly concerning your question:
You can allso store the world position in each sprite. That way, when you are going through the list, you don't need to go looking for any external information.
Having to recompute the world-position each frame seems like a lot of work that could potentially grow even worse depending on how deep your sprite-tree is.
When updating relative positions it is probably easier to compute the absolute position as well and just keep the information around.
Since most sprites will likely never change their position it's better to store it (for them specifically) as well.
When rendering you don't want to jump all over memory and pay for the cache miss, which you will avoid this way.
So you have an ideal path for rendering from the perspective of memory layout, but can still treat the list as a tree (through the indexes) when that particular access pattern is useful for other stuff.
Like always a cool video 👍
Btw could you make a video explaining Frameworks and how they differ from libraries?
It seems the only content out there is trying to explain it so abstract or metaphorical that I don't get the actual difference.
Thanks and keep up the great quality of videos
Hey cherno! What do you use as your visual studio font? It looks great.
This one was actually pretty good!
whats the color theme you use?
Can you review Unturneds code?
please do show how you'd reorganize the project.
Awesome review, well done.
I would love to know how you delete entities in the flat array approach. If you remove them from the array immediately, that changes all the indices and breaks the whole system, so do you have to do a messy clean-up step where you update all the indices in the tree? Is that really simpler?
Depending on how big your entities are, you could just leave them in the array in a de-activated state. Alternatively you could use an indirection to keep keep indices held by the user valid. Or use something like an arena or pool allocator and keep cache coherent that way.
Yes please, rework that project. That would be great to learn. Thx for what you do.
RIP Raytracing Series
We must keep the complexity demon out of our codebases
Grug happy
You came to a game engine coding series for that?
@@arushford it's a reference to a very insightful article called "the grug brained developer"
personally enjoyed the way the previous videos was done
Hi sir, how to config color code in visual like you. It's so nice! Can you share the tips?
I guess its properties > colors and fonts > and here you can costimize the keywords
@@y4ni608 thanks sir
How do you do the writing on screen mid video? (The part where you go over the vector of sprites, you write on the screen)
I'd like to know what is the theme of your VS
Thats some good advice
GOD you have great hair, geezus
You can see the pain Yan is having reading this mess as his body bends 😂
Hi Cherno, great video!! Going back to the sprites vector, if for some reason you deleted a sprite (and its children) how would you go about the 'gaps' in the vector?
That's a problem I had when trying to delete the children. I added all of the child's to a separated vector and then iterate over this vector and deletet the children. So the gap = srites_to_delete.size()
@@y4ni608 And what about the children of some child? Isnt it the same as doing a tree like structure like the one in the video that the cherno critisized?
@@guilhermedabolsa927 I hope i understood your question (my english is kinda bad) So I guess that its stil the same, you need to iterate recursive over it, regardless what you do, but i guess there is a big con when having the childs as indices and not ptrs, because you need to reduce the indices if you remove a sprite from the list for example
@@y4ni608 Yeah, you would need to reduce the indices, unless you dont shift the vector and leave 'gaps' in the array. Doing this way you dont need to recalculate all indices... but you would have a lot of 'holes' in your data... and this goes back to my initial question :v (sorry my english is also kinda bad)
@@guilhermedabolsa927 Ah, i use vector.erase() so it should shift it automaticly
Can you make a video on how to make good C++ modules pls? As a VST-Plugin developer I always have a lot of code I wanna reuse throughout multiple projects. So far I have just copied files around, which is often seen as the most crude approach. I can see why. It takes a long time sometimes to figure out how to integrate copied stuff and it just feels silly to do that when it's not meant to be edited in a project, but just used. So I suppose those "modules" solve that, right? Would be an excellent topic for a video I think.
Edit: But just saying: Would be cool if you made an extremely small example project for that and not this entire game engine, to make it easy to see what to do, you know? Just saying because most C++ videos on TH-cam are too basic, where you don't even see what's the point of a certain language feature, but you sometimes are the opposite, where you show things in a too complicated context, which can diffuse the actual point.
Audio developer here too. We use git submodules to handle inclusion of third party libraries and other libraries we've written. Works really well.
if the source code for the binding of isaac : rebirth ever is made public, i would love to see a code review of it.
10:17, also because "Private" comes before "Public" alphabetically. 🤣
Hi! Can you pls share your color scheme?
The Cherno says "...when you...", he actually means "...when the CPU...". Think CPU, what are you making the chip do?
"You have no idea what I'm capable of"
I hope you get into your final form in the next video 😁
"you need to do this, you need to do that" - way not enough reasoning WHY Your way is better Cherno
Can anybody tell which theme is he using
22:06 where are the children stored? the cherno after hazle failiure (sry it morning)
THAT FACE RMSNWODKJD
LOOKS LIKE BOB ROSS
F... the code! HE FIXED THE PILLOW!
That was it?! I was expecting you to keep making a longer video. Your word videos are so helpful. Hopefully you one day accept making a code review on my game engine. I think its core functionality are well designed and part of it is because of you.
Can you teach how to make a game engine with Vulkan and C++ and how to set it up with either GCC or Clang and VSCode because i cant figure it out to save my life
21:45, it's not required to write 'this->', because the 1st thing compiler will look is member data/f()s.
21:52, for a lib or generic code to be used in several projects, I always initialize string with ' = "" ', to avoid UB if the user starts adding things with += operator.
getIndexAtName could be public, since it's only meant for information. But the system of converting name to index is slow. Much better is to use 'const int's, like enums, that already give their names. Plus, this prevents typos at compile time.
1:53 I did some axis modeling and scene rotating. This experience is so if you really have to fight about not dropping out of university. I won't fix that math problem, because that is so much math I don't remember since first class until twenty years after graduating so you better use the relation database making tools and then try to dive deeper with that math. Rigid body you might remember, but why you would want to do that if you PowerPoint gets 3 views and as much hours to do it. You won't know that unless you work with headphones - you see other things if concentrating to the task.
Dude, please create a paid course on c++, but better then that, an updated version on all of that setup that we actually cannot learn properly anywhere. I actually learned a lot on your egine series about htat but do not know if still the same.. idk, you make very good content specially because you focus on architecture as well
Take it slow don't speed it up
Sure, public first sounds good, but it's more important to "declare first, use later"... which often will result in private first :) (If any public inline method calls a private method or use a private variable, constant...)
The problem is that there are 2 main competing uses cases: 1/ you want to understand how it works (maybe even modify it); 2/ just want to know how to use it.
It's important for code to be easily readable. For 1 this means stuff has to be declared before they are used. And this is where the private first comes from. (It's not the goal, or requirement, it's a consequence.)
So what about 2? Well in an ideal world this is where documentation comes in handy. If you just want to know how to use it, RTFM :)
But even if you just want to use it, it might be helpful to look at the private members, to see at a glance how heavy an object is... so private first... or more importantly data first.
love your videos
Quality over quantity always. Just take your time
config hell
Children in databases similar method with parent ids.
😊
"childs_to_delete"💀
Hahahahaa
Alright, only 5 more videos to go.
Me in Uni finding out trees are actually shit for performance 🥶🥵
I encourage - don't do that and use already build Laravel/Symfony. Those might have community version and don't have any legal issues about using the model Victoria Secret or anything surfing the waves. So I must begin with this - how am I making an Iskaar fish and cooking it. I try this add some of that. This c++ now possibly is not that RAW as it was ten years ago, but I don't know - it's not a real process about creating animation.
Custom text formats.... look no further than Dwarf Fortress.
Next video: Reviewing this README video - it sucks!
But on a more serious note, where are the comments in the code? Why does the coder need to figure out everything instead of comments indicating the control flow, specially non-obvious ones? Documentation?
the lack of comments wouldn't be so bad, if it wasn't a spaghetti codebase with terrible naming (e.g. `m_sprites` instead of `m_sprites_roots` or `m_sprites_top_level`)
if you write code clearly enough, you don't need comments to indicate what are you doing, because it's obvious what are you doing
@@atijohn8135 I have heard this argument before and we can agree to disagree, but I don't subscribe to this school of thought. Comments, and documentation, in general is a design choice, and my design recipe is to provide comments whenever there is unusual control flow (and yes, good naming can minimize it). Also, document what each function takes, does, side-effects, and returns. Sometimes I have had to look at code that I wrote 20 years ago, and good commenting has saved me a lot of hassle.
@@atijohn8135 But cherno misunderstood that, m_sprites are actually all sprites in the scene. And the reason why i didnt write any comments is because i just never really thought that he would review it, and im still a kid who is learning
@@y4ni608 well, my bad, it's still a massive feat that you were able to put this engine together as a kid, though if you want to continue doing this, you need to improve the cleanness of your code
@@agentm10 I have a rule where if I use more than two nested control flow statements, then I will rewrite the code to make it more clean, likely introducing some utility function that I may use again in the future, simultaneously reducing code repetition. It's particularly easy in C++20 and especially C++23, since it now has official support for ranges/views, so for instance instead of writing a for + a nested if statement, you can just write a range for with std::views::filter, and it's more readable to me that way.
Also, yeah, documenting functions is a must, but commenting on the code of the function itself is something I usually stray from, because as I said, it should be clear from the function code. Write short, pure, useful functions instead of big ones with a lot of repetition, ninja assignments and control flow, and if you feel like you can't do that, you probably need some utility function to carry you around.
Yo that UI is wack
I just noticed TH-cam automatically removed my subscription to your channel. The video appeared in my feed and noticed totally randomly I'm not sub anymore ...
Stopped watching at 7:09. When you went on a tangent about display resolution.
Is this just me or does he seem to kinda be passively pissed in the newer videos??? 😝
What are those comments lmao
My gods, this is far far too complicated and messy
The obsession with OOP over the past 20yrs has really screwed with the idea of pragmatism in code. Once upon a time you had experts in the problem or things to solve who learned to program, and having that intuitive knowledge allowed a better understanding of the approaches to use for each data set or operation, whereas the OOP generation starts with OOP and tries to solve the world with it.
day 3 of strategically comment to get a ❤reply from the Cherno
780th viewer and i am 13yr old😊
Vector is a really bad data structure for this in general. Time complexity for any search operations will be O(n)
When would you need search operations in this case?
Do you look like Chris Pratt or is it me?
Just saying i saw the thumbnail, then clicked the video, then downvoted and unsubscribed for what it's worth.
run a mouth course? omg. k.i.s.s. in engineering. if you need to use a separate build system in an IDE, nope. then you have to setup the build system also, build it from scratch. nonstandard use of IDE is not adviced (tm)(r). whoever has to use your code, will be messed up if the code uses a separate build system. instead, make the IDE code compile-able by its own tools.
Why don't you rewrite your game engine in rust? Or at least the parts that are critical?
'cause rust is pointless
Either you're meming or asking ridiculous questions seriously. Neither is a good look
There is no reason to use Rust over C++ in this case. The language of choice is mostly dependent on what you're comfortable with and what you enjoy. Rust although modern and fancy may not be enjoyable for everyone especially considering the paradigm differences. Also the main benefits of Rust typically come from people who don't understand the quirks of C++ which if you are experienced enough in C++ that should not be an issue. Granted some of the syntax sugars of Rust are nice but too many pollutes a language especially when people rely on them religously.