2000 HOUR 2D Game Engine! // Code Review

To 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!
Patreon ► / thecherno
Instagram ► / thecherno
Twitter ► / thecherno
Discord ► / discord
Code ► github.com/jkatsanis/SpriteEn...
Send an email to chernoreview@gmail.com with your source code, a brief explanation, and what you need help with/want me to review and you could be in the next episode of my Code Review series! Also let me know if you would like to remain anonymous.
Hazel ► hazelengine.com
🕹️ Play our latest game FREE (made in Hazel!) ► studiocherno.itch.io/dichotomy
🌏 Need web hosting? ► hostinger.com/cherno
💰 Links to stuff I use:
⌨ Keyboard ► geni.us/T2J7
🐭 Mouse ► geni.us/BuY7
💻 Monitors ► geni.us/wZFSwSK
This video is sponsored by Brilliant.

Пікірлер: 221

  • @TheCherno
    @TheCherno7 ай бұрын

    Thanks for watching! Should we continue looking at this 2000-hour 2D Game Engine? Also 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!

  • @matin.f139

    @matin.f139

    7 ай бұрын

    do itttttt please!

  • @dracula5752

    @dracula5752

    7 ай бұрын

    part 2 when

  • @LovepreetSingh-ye9hd

    @LovepreetSingh-ye9hd

    7 ай бұрын

    Let's dive in please!

  • @Dr_OmarYaser

    @Dr_OmarYaser

    7 ай бұрын

    very helpful ... continue

  • @ferdynandkiepski5026

    @ferdynandkiepski5026

    7 ай бұрын

    Yes

  • @nestor1208
    @nestor12087 ай бұрын

    "I won't roast you too much" *proceeds to making a 30-minute video of roasing the README file alone*

  • @monad_tcp

    @monad_tcp

    6 ай бұрын

    After reading the README file, I've seen it all

  • @Renschi.
    @Renschi.7 ай бұрын

    At 2:23 Cherno mentioned he doesn't know the tool Rene. This is because it is literally me. The person who created this Engine is one of my friends and I asked him to add me as a tool because I gave some recommendations about the UI of the Engine :)

  • @NoThing-ec9km

    @NoThing-ec9km

    7 ай бұрын

    Lmao. Loved it😅

  • @xTriplexS

    @xTriplexS

    6 ай бұрын

    Lol

  • @blackcitadel37

    @blackcitadel37

    6 ай бұрын

    wait, add you as a... tool? lmfao XD

  • @and_then_I_whispered

    @and_then_I_whispered

    6 ай бұрын

    you mean the egnine?

  • @hasankaraman

    @hasankaraman

    6 ай бұрын

    He can now add cherno as well

  • @bulentgercek
    @bulentgercek7 ай бұрын

    Cherno is a type of guy can do code review without looking the code. :D

  • @sneed1208

    @sneed1208

    7 ай бұрын

    He does look into the code that is presented in the README though, so that's not true.

  • @MahmoudSayed-hg8rb

    @MahmoudSayed-hg8rb

    6 ай бұрын

    I haven't finished the video yet, but i think there might be part 2 and maybe more.

  • @blackcitadel37

    @blackcitadel37

    6 ай бұрын

    senior dev sorcery

  • @kzone272

    @kzone272

    6 ай бұрын

    This is accurate, except its actually an insult not a compliment.

  • @bulentgercek

    @bulentgercek

    6 ай бұрын

    @@kzone272 This is only a joke. This is an internet meme. It's not an insult or anything. Cherno has an important place in my life.

  • @y4ni608
    @y4ni6086 ай бұрын

    Hello!! Thanks for reviewing my game engine for some reason my previuos commentar got deleted. it looks like im missing a concept about pointers 😅. I did discuss this vector SpriteRepository structure with my teacher (He is a teacher teaching mainly about os's) (Im still in highschool, 2nd grade) and he actually agreed with this structure. It's cool seing different opinions coming together, but i will defenetly value the advice of a professional gameengine dev more. I can't wait to see the part 2! by the way, if you guys got any questions about my game engine feel free to ask here :)

  • @giobbymenta

    @giobbymenta

    5 ай бұрын

    He agreed with your structure cause for an highschool student is really good enough lol. Good job

  • @gelis07
    @gelis077 ай бұрын

    12:24 that literally can become the best bell curve programming meme ever.

  • @jadrop0037
    @jadrop00377 ай бұрын

    Please continue the review on a future video. I’m really curious to see the engine running!

  • @marctse3556
    @marctse35567 ай бұрын

    Please continue with this engine. This is super informational! I also like the high level design aspect of this review

  • @felixp535

    @felixp535

    7 ай бұрын

    Yeah I really enjoy these kinds of videos, learning about how game engines work and are usually structured, and especially WHY it's done this way. It feels like this developer was trying to reinvent the wheel, but to be fair, how do you know you're reinventing the wheel if you don't even know how a wheel looks like and how it works? I started my own game engine a while ago, following Yan's amazing Game Engine series (except I was doing it in a language called Jai). I managed to render simple images, but I stopped following the series when it got to the ECS stuff, as I didn't want to have that in my engine. I just wanted to continue working on the rendering, but most of the stuff was being off-screened, so I really felt stuck when trying to actually create the structure for the rendering system. It's soooo complex, there's just sooooo much to think about. In various projects I've tried to explore there's RenderingContexts, RenderingConfigurations, all sorts of Buffers and Passes, rendering on separate threads, making all of this mess API-agnostic... I just gave up. I would love a series of videos explaining how all of that stuff works, explained with simple text and drawings just like in this video.

  • @y4ni608

    @y4ni608

    7 ай бұрын

    @@felixp535 Hello, yeah i kinda wanted to try something new, but i can see what issues i have here, i really didnt think that much about it

  • @NathanHedglin

    @NathanHedglin

    6 ай бұрын

    ​@@felixp535exactly. JAI?! You got access? How do you like it?

  • @Diventurer
    @Diventurer7 ай бұрын

    That raw pointer confidence chart is way too relatable. I can't believe how much I trusted myself with them before.

  • @LightTheMars
    @LightTheMars7 ай бұрын

    Instead of UUIDs for referencing entities during runtime you can also use generational indices. Keeps the index simple and small and takes care of validity.

  • @HairyPixels

    @HairyPixels

    7 ай бұрын

    UUIDs are extremely slow to generate too.

  • @funns7uf

    @funns7uf

    7 ай бұрын

    @@HairyPixels how so? UUID v4 is just a random 128-bit number with a couple of the bits set to specific values

  • @HairyPixels

    @HairyPixels

    7 ай бұрын

    @@funns7uf it's how the numbers are generated I guess. Maybe for sprites it's no so bad but if you start making them real time it's measurable.

  • @jonforhan9196

    @jonforhan9196

    7 ай бұрын

    @@HairyPixelscreate them in batches and utilize the mm registers maybe

  • @dealloc

    @dealloc

    7 ай бұрын

    @@HairyPixels Extremely slow to generate? What are you on an Amiga? Also, you don't need to generate UUIDs every single frame. You generate them only when you create the instances. It doesn't have to be generate UUIDs from a cryptographically secure random number generator either.

  • @sub-harmonik
    @sub-harmonik7 ай бұрын

    As someone who isn't a game dev but is peripherally interested, I really liked the conceptual overviews, thanks. This kind of thing is still relevant to other areas of system design.

  • @hullukana214
    @hullukana2147 ай бұрын

    Please make another video about this engine. I'm sure a deeper look into the engine would reveal many more memory management related issues for you to get stuck on for half an hour.

  • @verminology9999
    @verminology99996 ай бұрын

    In my opinion, this was one of your best code reviews, and you didn't even open the project yet. The way you explained everything visually was very cool and extremely informative. I would love to see a part two!

  • @donsk324
    @donsk3247 ай бұрын

    12:40 Can releate haha. At first I used to avoid dynamic memory management, then I started to embrace pointers after I got the hang of them and considered smart pointers 'pointless', that is after attaching address sanitizer and spending approximately an hour trying to fix memory leaks and memory corruption on a small sized project and later realized how important ownership is and how raw pointers laked ownership.

  • @sigxfs
    @sigxfs7 ай бұрын

    currently making my own 3d engine and this is the exact design problem i was thinking about

  • @aryanbhatia4872
    @aryanbhatia48727 ай бұрын

    loved your review of this, please cover more of this.

  • @CatzHoek
    @CatzHoek7 ай бұрын

    This project really seems to have some meat to it so i love that you can really talk about stuff. Would love to see that disected even more in other videos.

  • @adamrushford
    @adamrushford7 ай бұрын

    Thank you Yan that was very helpful and appreciated as always can't wait for more!

  • @K.R.O1875
    @K.R.O18757 ай бұрын

    You should do a follow up on this. There was still plenty for people to learn from here. But the kid states at the very start of the documentation that it may be outdated. It would be cool to have a look at the actual code and engine and offer some advice on that.

  • @TopConductor
    @TopConductor7 ай бұрын

    I like the code review without even looking at code directly xd It was very interesting to hear this UUID idea. I also was writing some small projects, and came up with the idea of storing the integer instead of the ptr myself, but it always felt awkward for me, and kind of unpreffessional, idk. thanks for the great video

  • @thygrrr
    @thygrrr7 ай бұрын

    Many (Generation-X and older) Germans call the "Strg" key the "String" key, and it really grinds my gears. :D

  • @hayabusa1x
    @hayabusa1x5 ай бұрын

    Very helpful explanation on pointers vs identifiers. Would love to see you review the rest of this code base.

  • @NathanHedglin
    @NathanHedglin6 ай бұрын

    Please continue! This is a great breakdown

  • @ParticalStudios
    @ParticalStudios7 ай бұрын

    Cherno, with the video content you create, you are very inspiring for people like me who want to become a game engine developer in the future. Thank you for that, keep that great work up!

  • @MrBrunovp21
    @MrBrunovp217 ай бұрын

    I loved it, please continue

  • @MotionLive
    @MotionLive6 ай бұрын

    Really helpful video, thank you !

  • @exosupesu
    @exosupesu7 ай бұрын

    This guy roasted the whole engine without even seeing the source code

  • @parabalani

    @parabalani

    7 ай бұрын

    Which is questionable

  • @Mitch_Crane

    @Mitch_Crane

    7 ай бұрын

    Isn't that what everyone does

  • @topg3067

    @topg3067

    7 ай бұрын

    He just needs ad revenue and relevancy, and took the easiest part to pick on. He ran out of libraries to use in his own engine lmao

  • @turner7777
    @turner77777 ай бұрын

    Would be cool if you did a vid on how to properly design a project

  • @irfanjames6551
    @irfanjames65517 ай бұрын

    31:31 Yes... Yan. This is a beautiful format. Can't wait for future reviews. Also, the PacMan Game you were going to build yourself. Would really appreciate it, if you can manage to take some time.

  • @Patrick_pw345
    @Patrick_pw3457 ай бұрын

    I rarely comment on videos. I really liked this video and would love to see more of this engine reviewed. The drawing really helped me understand the concepts. My initial impression is, that a bit more spacing and logically connected structuring would really boost my understanding and make it easier to follow. e.g. stacked in a way that matches the data flow top to bottom. like Scene -> Sprite Objects -> Sprites -> How the memory is referenced / handled. I probably missed a layer in this example. Writing that, a summary in such a structure at the end would've probably really helped me recap and form a better understanding of what concepts you just pointed out. You partly or may have done that in the part about Scenes. Long comment, really loved the video. Hope you can take something from my feedback. :-)

  • @y4ni608

    @y4ni608

    7 ай бұрын

    Yep you are right! I should have done it like this, i actually do have a scene system but its kinda wierd lol. It just loads the contents from for example scene 2 in memory and deletes the content from Scene 1. I should have wrapped that content that gets loaded into a scene object, like you did it in your comment also managing scenes (refreshing/loading/deleting) etc is much easier with this way

  • @yieldjedimaster1040
    @yieldjedimaster10407 ай бұрын

    Yes, it's really helpful, let's continue!

  • @simiuciacia

    @simiuciacia

    7 ай бұрын

    I was expecting something more of a "continue we shall" with that pfp

  • @kevinthesome
    @kevinthesome7 ай бұрын

    Man i like this style a lot more plz more

  • @gnifer
    @gnifer7 ай бұрын

    Why didn't you roast that the readme had code without syntax highlighting?

  • @y4ni608

    @y4ni608

    7 ай бұрын

    For some reason it doesnt work

  • @EmilyGraceSeville7cf
    @EmilyGraceSeville7cf7 ай бұрын

    I love your content, keep going😄

  • @natanaelrabello
    @natanaelrabello7 ай бұрын

    Please keep roasting this engine. I feel like amazing lessons could come out of it. Thanks :)

  • @-lolus-
    @-lolus-7 ай бұрын

    i'd love to se another part about this engine

  • @SquidSnipes
    @SquidSnipes6 ай бұрын

    Please continue with this

  • @spidermanlift4527
    @spidermanlift45277 ай бұрын

    I wanna see more of this engine

  • @defter6800
    @defter68006 ай бұрын

    You can also introduce some typed ID (for different types of objects) by using syntax sugar of C++ and allocate this ID by increment atomic int variable (or even non atomic). Only downside if too many threads do this frequently with atomic variable, but there is always way to pre-allocate N ID's very fast and unroll some loops or make like ranged limited local ID allocator that use ID ranges from global ect.

  • @loctite417
    @loctite4177 ай бұрын

    Thank you for extremely helpful video especially since I recently made a sprite rendering system with a c style array of size 2048 storing pointer to sprites lmao

  • @loiphin
    @loiphin7 ай бұрын

    You sounded so excited whilst reading your Brilliant sponsor script... hahaha

  • @cpaulicka
    @cpaulicka7 ай бұрын

    This was fun but…very little discussion of abstraction at the very end. Also, discuss user of software vs developer of software (which often have different priorities). Instead you kind of jump into details (charmingly so, yes). API design before implementation helps; you could do that with the implied api here and clean it up, and then walk through possible implementation details afterwards. ;-)

  • @austinbachurski7906
    @austinbachurski79066 ай бұрын

    I'd really like to hear more about this UUID storage works. I don't believe I'm properly grasping it, obviously (I assume) you're not using the id as the index of the vector or whatever container you're using right? Would like to hear more if possible, and please continue the code review if you have time. Thanks.

  • @The1RandomFool
    @The1RandomFool7 ай бұрын

    I'm more of a beginner in C++, but I won't make pointers for the sake of having a pointer. From what I learned, it could lead to unsafe memory handling. If I have to pass something to a function, I'll pass it by reference instead. If I need to make something on the heap, I'll use a smart pointer instead. I made a command line scientific calculator at one point and used std::function to create a function map instead of using raw function pointers.

  • @oscarsmith-jones4108

    @oscarsmith-jones4108

    7 ай бұрын

    Pointers to functions are perfectly safe. Real bugs start happening when you have a pointer to a variable that no longer exists. Like, if you spawn a character in a game, refer to it using a pointer, then destroy the character. Now you have a pointer that no longer refers to the character it once referred to (because you deleted it). If you ever made a game in Unity and you've coded something in C#, this situation will result in the quite common "null-reference" error. This is because you are trying to use a pointer that refers to something that no longer exists. This problem never occurs if you use a pointer that refers to something that always exists (like a function) or the pointer is on the stack and it refers to another variable previously on the stack. Just ensure that the thing your pointer refers to still exists and doesn't move around. This is quite a simple rule to keep in mind, and it's generally only broken when there's something fundamentally wrong with the logic/structure of your program. std::vector is a unique exception because a vector will move its contents around when new elements get added to it, so be careful when using std::vector. Also, & (reference type) is essentially just a pointer, so using pointers as references is perfectly safe and quite common. Just use smart pointers when you are allocating on the heap. std::shared_ptr is a good alternative to normal pointers but it has overhead (performance cost) so use it only when you need it. Edit: the use of pointers in this video is particularly not good because entities in games can be spawned or deleted anytime, which as I said before can lead to these issues.

  • @the_gobbo
    @the_gobbo5 ай бұрын

    1:59 Boy was he right about this being a ride lol 🤣

  • @markp1634
    @markp16347 ай бұрын

    Please keep going!

  • @TehHeiks
    @TehHeiks6 ай бұрын

    That sprite stunlock truly is something

  • @mikael8276
    @mikael82767 ай бұрын

    Whoa, I didn't know that pushing a new element into a vector would invalidate all earlier references.

  • @fappylp2574

    @fappylp2574

    6 ай бұрын

    Most of the lines of code I have ever written in C++ have turned out to be undefined behaviour... It's astonishing what you can miss without formal training!

  • @aarondcmedia9585
    @aarondcmedia95857 ай бұрын

    I have read more game egnine books than you could shake a shared pointer at, but discussing something real is what solidifies the concepts in my mind. Much appreciated for this content, and please keep going with this engine.

  • @not_herobrine3752
    @not_herobrine37527 ай бұрын

    i wonder if thecherno would review a c styled rust codebase

  • @Brolexios
    @Brolexios6 ай бұрын

    @TheCherno, what do you use to draw on the screen and whiteboard these webpages?

  • @zombi1034
    @zombi10347 ай бұрын

    more please❤

  • @NeuroScientician
    @NeuroScientician7 ай бұрын

    What is a good way to track hours spent in VSCode/Game Engine? Something bit more automatic that just stopwatch and a spreadsheet?

  • @notlekrut

    @notlekrut

    7 ай бұрын

    You can use apps/sites that have extensions for IDEs, like Wakatime, there's several others. There's also some apps that track OS windows and window titles to figure out what you're working on and then you can categorize, but I only know specific ones for mac(ie. Timing), but I'm sure there's similar ones for Windows.

  • @InfiniteCoder01

    @InfiniteCoder01

    7 ай бұрын

    Wakatime

  • @kiiikoooPT
    @kiiikoooPT7 ай бұрын

    I have a stupid question maybe, but is just curiosity I guess, the case you talked in the video and some people are talking in the comments about a really low chance of a 128bit random nr coliding or repeating, isn't it a good idea to make the nr and check if it already exists? Just to make it impossible to happen at all. I just say that, because in this case, the sprites will be loaded once only, and they stay in memory or cache or whatever, it will slow down the loading of the sprites cause it has an if in every sprite nr generation, but it will only happen once right? at the beggining of the game launch. then you just ask to print a specific sprite that is already there or to hide it. I don't know if im making myself clear in what I mean. Is kind of my logic, but I never made a game or engine or anything usefull at all, just few projects that I started to try to learn it, but never finished, or needed to load gigabytes of stuff. Only things with small content. Few images to make buildings with colision and my character images, the way I did it if im not mistaken was with class sprites and push pull to the class array of sprites, kind of what you did with the cherno engine in the begining I believe.

  • @tbc1880
    @tbc18802 ай бұрын

    As someone in a similar spot as the guy here, (not 2k hrs deep but grinding through my own engine as basically a higher level novice) I want to shoot two questions I have into the void in hopes I may finally get answers. For my scenes I have the main loop run their update function and every now and then a different one for a transition that may send data over to the new scene (like if I move to the main menu from settings I keep the music playing vs from title screen which has it's own music.) The main just gets a pointer to the new scene while the old one clears itself of all objects and such. Main then runs and creates the new scene. While memory usage is still low I wonder if this is okay due to a not exactly memory leak I am seeing. Basically if I move between scene 1 and 2 the memory use will rise but will stop after a bit. Move to scene 3 and the cap rises. Scene 4 and so on. I have no clue what maybe causing this as I am deleting everything and if it were a true leak would it not continue indefinitely? Is it just my computer managing data in that way or an actual issue with my code.

  • @unkgames-abdullahali4048
    @unkgames-abdullahali40487 ай бұрын

    Another video of this engine

  • @nicksdrumsticks
    @nicksdrumsticks7 ай бұрын

    7:04 - What the hell? That pronunciation was so accurate

  • @px2059
    @px20597 ай бұрын

    Most of the times engines have to move objects around in the heap to fill the holes created by freed memory. If you access pointers directly, you either can't move objects or you can't use memory efficiently.

  • @jakubgiesler6150
    @jakubgiesler61503 ай бұрын

    My first line was written around 2009 in Java (i was 11 btw), and when I learned pointers and c++ around 2015 I felt super smart and used them everywhere, and now it's 2024, and I rarely use pointers, so yeah the statement is true.

  • @lucasgaming4793
    @lucasgaming47937 ай бұрын

    i would like to see more

  • @topg3067
    @topg30677 ай бұрын

    Back to the engine.

  • @alastairtheduke
    @alastairtheduke5 ай бұрын

    great video

  • @beigebacchus1
    @beigebacchus16 ай бұрын

    Hey I was wondering if you could do an updated coding tutorial for opengl please?

  • @ludologian
    @ludologian6 ай бұрын

    I'm c# developer, and I consider myself something between beginner & intermediate lvl but generally I can follow up with you.. please stay with this format

  • @rafaelmateodev
    @rafaelmateodev7 ай бұрын

    I hope they make the changes, this seems imperative.

  • @anispinner
    @anispinner7 ай бұрын

    Basically a 30 minute sprite review

  • @kiririn39m8
    @kiririn39m87 ай бұрын

    Hi Cherno, thanks for another code review. By the way, could you maybe consider reviewing game entity design in Unreal engine? (namely Actors and components) And maybe a UI system? And maybe Compare it with Unity or Cryengine or Hazel or something. The reason is that there's this aura of ideal AAA grade around Unreal and everything related to it's design is perfect, but for me it's exactly the opposite, after unity an O3DE. Every other engineer I have spoken to (Unreal devs) don't even get what's wrong (from my personal opinion ofk) with their favorite engine etc. I think that could be a realy insightful and interesting kind of video

  • @GonziHere

    @GonziHere

    7 ай бұрын

    Yeah. Unreal is incredibly overhyped thanks to it's features, to the point, where we cannot have a normal discussions about it's shortcomings.

  • @anon1963

    @anon1963

    7 ай бұрын

    ​@@GonziHereI'd rather use polymorphism as well instead of creating an array for every type of an entity

  • @simiuciacia
    @simiuciacia7 ай бұрын

    People should pay for content like this, this is my kind of videos really, thx again

  • @mldy1
    @mldy15 ай бұрын

    25:48 probability would be 1 in 2^64, or 1 in ~18 quintillion or 1 in ~18 billion billion so probably more likely a cosmic ray would case the program to crash

  • @SiltyWheat7
    @SiltyWheat76 ай бұрын

    I'm not sure I interpreted this correctly. How would you use a random GUID or UUID as an index for a vector? Wouldn't these IDs potentially be massive (i.e. 0 to 2^64 - 1) meaning the vector would have a ridiculous number of elements?

  • @tardistrailers

    @tardistrailers

    6 ай бұрын

    You could use a hashmap instead of a vector in that case.

  • @fappylp2574

    @fappylp2574

    6 ай бұрын

    Lol, just buy more ram...

  • @fappylp2574

    @fappylp2574

    6 ай бұрын

    @@tardistrailers But how do you get around losing the contiguous memory? Does it make sense to store a map of (UUID -> Index) and keep that updated somehow? The whole point of this contiguous allocation is better performance during iteration (ECS etc.).

  • @TheMrTka4
    @TheMrTka47 ай бұрын

    I expected some code in code review :D But that was useful anyway! I would like to see a continuation about this engine. I miss code reviews from you!

  • @gyorgyreisch440
    @gyorgyreisch4407 ай бұрын

    I don't understand why is better to storing the objects in that vector than storing pointers to them?! I can imagine one reason: if ALL of the stored object are the same type (aka same size in memory)? (Ok, I haven't program any game engine yet, but in the other programming tasks I experienced that storing pointers [of course unique, shared or weak] is the solution.)

  • @machimanta

    @machimanta

    7 ай бұрын

    If you store all the objects in a vector directly, you are guaranteed that they are contiguous in memory. If you store pointers, you have no guarantee that the pointed-to addresses (where the object data would be) are spatially local in memory. This has huge implications because accessing memory is SIGNIFICANTLY slower for a CPU than arithmetic/logical operations. CPU architecture attempts to solve this problem by having "cache." Every time you access a memory location, the CPU first checks whether it has that memory in its cache. If it is, great! (That's called a "cache hit" and is very fast.) If not, it must fall back to RAM and grab it (called a "cache miss" and is very slow). Contiguous memory is important because when CPU has a cache miss and fetches the memory from RAM, it grabs more than just the memory you requested. It actually grabs larger block determined by the size of the "cache line." The size of the cache line depends on the CPU & cache level, but its typically ~64 bytes for the closest (fastest) cache. So if I linearly access a vector of 4 byte integers, the first access would be a slow cache miss and then the next 15 integers would be very fast since they were put in cache by the initial miss. In practice it gets a bit more complicated (i.e. the CPU has ways to predict cache misses and compensate for them and compilers can do clever tricks to optimize code around cache access) but the takeaway is that linear, contiguous memory accesses are fast and random accesses are slow.

  • @y4ni608

    @y4ni608

    6 ай бұрын

    ​@@machimanta Hi i didnt quite get your explanation, so what advantage do i actually have when i store the objects as objects and not pointers? So do i like always have my sprites in cache to access them always with a cache hit when i store them as object, and when i store them as pointers i just need to go back to memory because i have the pointers in the cache and do a cache miss?

  • @machimanta

    @machimanta

    6 ай бұрын

    @@y4ni608 In order to have an object, it has to be kept /somewhere/ in memory. So storing the objects directly within the vector (rather than having a vector of pointers to objects) is the most efficient way to do it from the eyes of the CPU. If you're currently storing pointers to objects, then you're likely allocating them individually with calls to new/make_shared/make_unique/malloc/etc. (pick your poison). Doing so means they are more-or-less stored "randomly" in memory. That's bad since it means the CPU will stall a lot trying to find their data (cache miss penalty). Computers are good at doing predictable things, so having to randomly jump around in memory from object-to-object is not ideal

  • @Andrumen01
    @Andrumen017 ай бұрын

    I agree with your statement about pointers. I hate them...not that I don't understand them, but it's a pain to keep track of them when they are juggled around and it's better to avoid them whenever possible. It's nothing else, really.

  • @oussamasoudassi

    @oussamasoudassi

    7 ай бұрын

    If you know who owns whatever pointer and who is responsible for clean up why hating and avoiding them??

  • @Andrumen01

    @Andrumen01

    7 ай бұрын

    @@oussamasoudassi Have you ever worked on projects that have dozens (maybe hundreds) of files, each 2000+ lines long and full of pointers going here and there without indicating who owns what? Yes, fixing a memory leak due to badly un-referenced pointers in those projects is like fixing a hole in the Hoover damn with duct tape. I myself would be careful, but when projects grows out of hand, it is unavoidable to have those leaks, and finding them is a nightmare. Yes, C++20 has helped to mitigate that issue, but still pretty bad!

  • @anispinner
    @anispinner7 ай бұрын

    00:18 Ah, looks like a typo for "Egg nine"

  • @marcelbarbosa281
    @marcelbarbosa2817 ай бұрын

    Yes, i want sir.

  • @trampflips101
    @trampflips1017 ай бұрын

    With 64 bit identifiers you have a 0.7% chance of a collision with 500 million uids, and 35% with 4 billion.

  • @kplays_6000

    @kplays_6000

    7 ай бұрын

    Even in games such as Elite Dangerous or No Man's Sky, they don't come close to having to make use of 500 million UUIDs at once, let alone 4 billion, so this really is a non-issue with any scale of video game. The game won't store all the planets in one data structure - I'd imagine more of a tree where you segment the universe into quadrants, each quadrant stores its system or planets, then each planet stores its own entities. With careful consideration to structure, the UUIDs only have to be unique per level of the tree, rather than globally. That's where you start considering the difference between UUID and GUID

  • @trampflips101

    @trampflips101

    7 ай бұрын

    @@kplays_6000 All true, he just asked someone to put the collision chance in the comments in the video.

  • @olegallito5742
    @olegallito57426 ай бұрын

    Minute 9 is when I started asking myself like "where the fuck is the engine" rather than a few classes and a half (that aren't even handy to use). It's pretty much like making a game from scratch, but using some questionable libraries.

  • @niallrussell7184
    @niallrussell71847 ай бұрын

    I expected this to be about optimizing drawcalls or something.. didn't even get that far! 🤣

  • @ScibbieGames
    @ScibbieGames7 ай бұрын

    Structure of arrays enthusiasts unite

  • @edmunns8825
    @edmunns88256 ай бұрын

    An egnine is three short of a dozen, but just enough for 2 dosen and an egnine

  • @TheViperZed
    @TheViperZed7 ай бұрын

    wow this was basic, anyway what this is really missing is a decent description on pointer arithmetic and why that is a very inexpensive operation. This is of course assuming that all the sprite objects have an equal, known, size at compile time and no further de-referencing to other data on the heap happens, cause then the original method of just storing pointers is actually more efficient when drawing the sprite. If you have to explain this to someone, this really should really include an in depth discussion of stack and heap allocations and what that actually means, as that is the underlying optimization issue.

  • @CoolModderJaydonX
    @CoolModderJaydonX7 ай бұрын

    Well, if it isn't another code review from Mr. Chernikov himself!

  • @weirddan455
    @weirddan4557 ай бұрын

    "Code Review" - Never even looks at the code. He just saw the new keyword and went off on a tangent about entity component systems...

  • @ZeroUm_

    @ZeroUm_

    7 ай бұрын

    Architecture review is code review. It's way more important to catch wrong assumptions about how stuff works than nitpicking variable names or any easily refactorizable code.

  • @NathanHedglin

    @NathanHedglin

    6 ай бұрын

    If you don't get the architecture correct, the code basically doesn't matter

  • @maximiliannowak7860
    @maximiliannowak78607 ай бұрын

    Man, all this talking about sprites made me thirsty

  • @y4ni608

    @y4ni608

    7 ай бұрын

    Hahaha

  • @Fly_The_Sky
    @Fly_The_Sky7 ай бұрын

    32 minutes on 4 lines of pseudo code. That is pretty good! I am a Programmer but not a game engine developer, keep more videos coming about this egnine!

  • @y4ni608

    @y4ni608

    7 ай бұрын

    Haha

  • @rudolfbouzek6944
    @rudolfbouzek69446 ай бұрын

    eh :D so pro :D im looking at basic c++ videos... it was 6 years ago... this is like level: GOD :D

  • 7 ай бұрын

    You are a very good KZreadr.

  • @tawandagamedevs
    @tawandagamedevs7 ай бұрын

    Rust developers in shock seeing a reference to an element in an array

  • @michaelsteffensen6844

    @michaelsteffensen6844

    6 ай бұрын

    Why would that shock rust developers?

  • @InShadowsLinger
    @InShadowsLinger6 ай бұрын

    The Sprite object and its knowledge of sprites vector seems like anti pattern to me and against OOP principles.

  • @ari-mcbrown
    @ari-mcbrown4 ай бұрын

    Here's some actionable advice: ... set your autofocus to a fixed setting.... pls. :'(

  • @hawns3212
    @hawns32127 ай бұрын

    25:45 The odds of two random 64 bit numbers colliding is 2.916x10^-39% AKA 0.0000000000000000000000000000000000000002196% With more decimals after, of course, but roughly that It is a chance of 1 in 340,282,366,920,938,463,463,374,607,431,768,211,456 chance or a 1 in 2^128 chance or a 1 in 340.2 undecillion chance. Very very unlikely. If this ever happens to you, go buy a lottery ticket. You're likely to win the lottery 11,645,529,300,000,000,000,000,000,000 times more likely to win the lottery than get two 64 bit integers being the same Edit: I made a mistake, its not 1 in 2^127, but 2^128

  • @HiHi-ur3on

    @HiHi-ur3on

    7 ай бұрын

    That doesn't make sense. Shouldn't the chance of two random 64 bit numbers be a straight up 1 in 2^64? Since the second number has to be exactly the first number and can be any of 2^64 numbers?

  • @felixp535

    @felixp535

    7 ай бұрын

    How can it be a 1 in 2^127 when there's only 64 bits? This makes no sense. If we both pick a number between 1 and 10, the chance we pick the same number is 1/10 (the number you pick doesn't matter, the only thing that matters is that I pick the same). Following the same logic, the chance for a computer to pick two identical numbers between 1 and 2^64 is 1 in 2^64.

  • @hawns3212

    @hawns3212

    7 ай бұрын

    @@felixp535 Lets make it a bit simpler. Imagine you have two dice and you want them both to roll 6s. Each die has a 1 in 6 chance of landing 6, so dice A has 1/6 chance, and dice 2 has 1/6 chance. These are statistically independent events, therefore to calculate the odds of them both happening we multiply them, therefore both dice have a 1/6 chance. This is called taking the intersection of the probabilities, when two events happen together. The odds of having one number from a 64 bit integer is 1 in 2^64. Assuming perfect randomness in the generation we multiply it (aka square it) just like the dice. 2^64 squared is 2^128, therefore we have odds of 1 in 2^128.

  • @Rizza257

    @Rizza257

    7 ай бұрын

    @@felixp535 this is a common misconception. The probability of person 1 picking does not affect the probability of person 2. This means they are independent events. The probability for independent events is calculated P = P(A) * P(B). So in your example the probability of both picking the same number out of ten is 1/10 * 1/10 = 1/100. This is because you have to consider every combination they can pick the same number.

  • @felixp535

    @felixp535

    7 ай бұрын

    ​@@Rizza257 You made me doubt so I double checked using Excel. The probability of both picking the same number is indeed 1/10 and not 1/100 as you mention. The number chosen by A doesn't matter. The only thing that matters is that B also chooses the same one, which has a 1/10 chance to happen. The events are dependant because B must pick the same number as A. When you think about it, A does not have to pick the same number as B, so P(A) is the probability that A picks any number, which is 1.

  • @dejoma.
    @dejoma.6 ай бұрын

    When somebody writes "You can give the pointer an address by calling ..." you know that this person does not understand how memory allocation works in C++. Which is absurd after 2000 hours :D

  • @y4ni608

    @y4ni608

    6 ай бұрын

    I apolozige for any confusion in the Readme file, to put it simply my english is just very bad. i meant with this line "You can give the Sprite ptr a address by calling the s2d::Sprite::getSpriteByName("name"); " that well since s2d::Sprite* my_ptr is a nullptr on start you are assigning the nullptr a adress i dont really know how to put it in good english for you. So thats what i meant, and yeah i do agree that it sounds wierd when you say "Give the pointer a adress" but i dont know how to say it better, sorry.

  • @ghostlucian12
    @ghostlucian127 ай бұрын

    Data Orientated Programming is where you optimize programming for efficient CPU caching, because when you access a certain part of memory the CPU will grab a chunk of memory, and copies it to the CPU cache, so when reading the next item will try first to read it from the cache if it is, if it is not will grab another chunk of data memory. Having pointers or linked lists for example the data will not be on the same place of the memory(which is not too efficient), and the CPU will grab from memory your data. each time it accesses the data. in this case a iterating through the list will take a lot of time. If you instead have a vector or an array of sprite metadata the CPU will grab a chunk of memory containing the metadata from multiple sprites, you can access the data when you process the sprite. In this case iterating through the list will take a faster time since the CPU will not have to access the memory each time.

  • @anon1963

    @anon1963

    7 ай бұрын

    you don't need to worry about this most of the time

  • @oscarsmith-jones4108

    @oscarsmith-jones4108

    7 ай бұрын

    @@anon1963 Cache miss has a huge performance cost, so it depends on the game you are making. It's still a very real performance consideration.

  • @anon1963

    @anon1963

    7 ай бұрын

    @@oscarsmith-jones4108 nuh uh

  • @maltaparkhelp
    @maltaparkhelp7 ай бұрын

    The downside to a vector of objects is that when the vector resizes, the all the objects need to be moved, instead of just the pointers. Depending on the size of the objects, this could make a big difference.

  • @mjthebest7294

    @mjthebest7294

    7 ай бұрын

    Traversing the vector is usually done muuuuch more frequently than vector resizing, so optimizing that is a priority. If resizing is happening so frequently that is slows you down, you have an architectural design issue

  • @parabalani
    @parabalani7 ай бұрын

    This was weird. You didn't even look at the code and instead reviewed a description and pseudocode. Also, giving a concrete demonstration on how to rewrite his code without using pointers would be helpful.

  • @user-hh7cy8tr6h
    @user-hh7cy8tr6h6 ай бұрын

    Please help Battlestate Games make their game FASTER! Its so unique game!!! )

  • @olgafedyanova
    @olgafedyanova6 ай бұрын

    How have you not experienced burnout in so many years of working in the company? all programmers get burnout in their work after 5-10

  • @AldoInza
    @AldoInza6 ай бұрын

    this looks like a primative egten

  • @soheibmemes2594
    @soheibmemes25947 ай бұрын

    hi

  • @owdoogames
    @owdoogames7 ай бұрын

    2000 hours? Them’s rookie numbers. I’ve probably spent twice that trying to learn Godot and trying to make a crappy Metroidvania and failing miserably. Off to write my own game egnine instead.

  • @Svatko

    @Svatko

    6 ай бұрын

    xd