So I'm glancing over the code introduced around episode 21 of handemade hero where he does the hot-reload setup, which I understand fine. The platform layer hands a chunk of memory to the game, and then a game_state struct is pointed to the beginning of that block of memory.
But what if you need to do dynamic allocation in the game? Is there a way to set things up so you can use malloc/new on the block of memory? Do you need to write your own allocator?
If this is addresses in the handmade hero series at some point, if anyone knows what EPs you can just point me there!
But what if you need to do dynamic allocation in the game? Is there a way to set things up so you can use malloc/new on the block of memory? Do you need to write your own allocator?
If this is addresses in the handmade hero series at some point, if anyone knows what EPs you can just point me there!
Edited by Jack Mott
on
You'll need to use the platform layer to allocate the memory for you.
In fact (it looks like) he redoes the allocation scheme at ep 160.
you can search the annotation for the episodes at: https://hero.handmade.network/episode/code#allocation
In fact (it looks like) he redoes the allocation scheme at ep 160.
you can search the annotation for the episodes at: https://hero.handmade.network/episode/code#allocation
Yes, regular malloc/free will also work.
Annotations are done mostly by Miblo (its mentioned on right side).
Annotations are done mostly by Miblo (its mentioned on right side).
As far as I know, there's no way to force malloc to return a fixed address inside the virtual memory space of the process. By using it, you can still hot-reload, but if you plan to load a memory dump from a different run of your program, you'll have to fix any pointers contained in it.
As for "why not just use malloc and free"
Casey does a lot of unnecessary things. He's really taking the "From scratch" thing super far. I'm not sure if he's trying to make a game "from scratch" or trying to get the Guiness Book of World Records: award for deepest level of game design procrastination possible!
(I'm a fan, but...)
Generally in C++ there are these thoughts, especially on Windows:
a) malloc and free are fine, especially in C, but realloc doesn't work all that efficiently, but anything malloc'd should be free'd
b) You shouldn't use malloc and free when you can use new and delete
c) you should use try {} catch() {} around these things to catch exceptions before you get a crashy-wah-shie so you can tell people they're out of memory when they are, or at the very least to help you when dealing with infinite loops, corrupted values and other mistakes in design
[Hotreload-related statement retracted, i thought it was something else]
Casey does a lot of unnecessary things. He's really taking the "From scratch" thing super far. I'm not sure if he's trying to make a game "from scratch" or trying to get the Guiness Book of World Records: award for deepest level of game design procrastination possible!
(I'm a fan, but...)
Generally in C++ there are these thoughts, especially on Windows:
a) malloc and free are fine, especially in C, but realloc doesn't work all that efficiently, but anything malloc'd should be free'd
b) You shouldn't use malloc and free when you can use new and delete
c) you should use try {} catch() {} around these things to catch exceptions before you get a crashy-wah-shie so you can tell people they're out of memory when they are, or at the very least to help you when dealing with infinite loops, corrupted values and other mistakes in design
[Hotreload-related statement retracted, i thought it was something else]
Edited by Lost Astronaut Studios
on
Just to make sure readers know that there is a diversity of opinion on this thread...
I'll disagree here. Free memory if you don't want it to be around for the lifetime of the program. In some cases, freeing isn't necessary (all modern operating systems will free up the memory on program exit). Whether some memory is freed or not is irrelevant to the functioning of the program. Usually you probably want to, but there are cases where you just don't care.
This isn't the entire picture- I'll refer readers who'd like to know the difference to a clip from Handmade Hero.
I disagree here as well- I recommend explicitly handling errors (in my opinion, this is the only type of error handling that should occur). Exceptions are not necessary for that.
lost
a) malloc and free are fine, especially in C, but realloc doesn't work all that efficiently, but anything malloc'd should be free'd
I'll disagree here. Free memory if you don't want it to be around for the lifetime of the program. In some cases, freeing isn't necessary (all modern operating systems will free up the memory on program exit). Whether some memory is freed or not is irrelevant to the functioning of the program. Usually you probably want to, but there are cases where you just don't care.
lost
b) You shouldn't use malloc and free when you can use new and delete
This isn't the entire picture- I'll refer readers who'd like to know the difference to a clip from Handmade Hero.
lost
c) you should use try {} catch() {} around these things to catch exceptions before you get a crashy-wah-shie so you can tell people they're out of memory when they are, or at the very least to help you when dealing with infinite loops, corrupted values and other mistakes in design
I disagree here as well- I recommend explicitly handling errors (in my opinion, this is the only type of error handling that should occur). Exceptions are not necessary for that.
lost
b) You shouldn't use malloc and free when you can use new and delete
Actually in modern C++ you wouldn't be using new and delete at all. Instead you would use the smart pointers for single objects and std::vector for an array of them. Then let RAII take care of cleanup.
Though there are cases where that isn't sufficient and a more involved allocation scheme is needed.
@lost: you are missing point what Casey is teaching with Handmade Hero. He is not teaching "always write everything from scratch". He is teaching people to understand what they are writing, how it works and why it is needed, instead of blindly following "advices" like "always use X", for example, "always use new and delete".
Hot-Reload .. well, I'm not sure why you would implement this unless you expected your game engine to be very volatile and poorly implementedYou are also missing point of hot reload. Its to quickly tweak values of small code samples without need to restart whole game. Its a huge time saver. For example, instead of loading game every time and go to specific place in level just to test one change in one constant... Haven't you see HH videos where Casey tweaks values or code? He opens both - editor and game, puts game in specific situation he needs to test and then just edits code. With simple press of key (build) game reloads newest code. No need for scripting languages, no need for glitchy edit-and-continue implementations from IDE. Just a quick reload of dll and new code runs. I suggest check the episode archives. This was demonstrated multiple times.
you should use try {} catch() {} around these things to catch exceptions before you get a crashy-wah-shie so you can tell people they're out of memory when they are,No need for try/catch in this situation. std::nothrow works fine for new in C++.
When you use malloc and free, you are using something from C.
When you use new and delete, you are using something from C++ pre-2023 (j/k).
When you use "smart pointers" you are using C++11 and beyond, sans std::auto_ptr -- as for "vectors", you are using something from STL.
https://www.geeksforgeeks.org/new...rators-in-cpp-for-dynamic-memory/
And then there's the scary future (keep in mind C++ refinement was supposed to "end" before 2015)
http://www.modernescpp.com/index.php/no-new-new (It may be just an April Fools joke)
When you use new and delete, you are using something from C++ pre-2023 (j/k).
When you use "smart pointers" you are using C++11 and beyond, sans std::auto_ptr -- as for "vectors", you are using something from STL.
https://www.geeksforgeeks.org/new...rators-in-cpp-for-dynamic-memory/
And then there's the scary future (keep in mind C++ refinement was supposed to "end" before 2015)
http://www.modernescpp.com/index.php/no-new-new (It may be just an April Fools joke)
Edited by Lost Astronaut Studios
on
@mmozeiko
Re: "@lost: you are missing point what Casey is teaching with Handmade Hero. He is not teaching "always write everything from scratch". He is teaching people to understand what they are writing, how it works and why it is needed, instead of blindly following "advices" like "always use X", for example, "always use new and delete"."
- You should use new and delete in C++.
- Should doesn't mean always.
- As for not handling errors, well that's up to your project's requirements. It's good to handle errors in some form. The person with the top answer here agreed with you, but the commentators disagreed. Perhaps join the argument there: https://stackoverflow.com/questio...146/why-is-exception-handling-bad
As for Casey, well, in 2255 when he is "nearly done" wake me out of cryosleep. I think blindly stumbling around in the dark with a team of blindfolded patrons is what it is. He spends more episodes describing some obscure deep and sometimes inaccurate facet of computing than he does describing theories of game design, plot, inventory, statistics, rewards systems or anything else remotely game-like. While sometimes sneezingly-interesting, it definitely does not live up to its claim on the cover. I thought by now I'd be engrossed in dozens of videos about plot, inventory, statistics and game visions, rather than discussing the importance of redesigning a procedural engine test kit that replaced an abandoned attempt at a 2D grid-based world, that grew out of 200+ multi-hour sessions, and a year of setting up and explaining C++ and a manageable OpenGL window in Visual Studio.
The website's claim:
"Handmade Hero is an ongoing project to create a complete, professional-quality game accompanied by videos that explain every single line of its source code."
SPOILER ALERT: This ain't gonna happen any time soon.
Sure. Great. Except, he has admitted time and time again on camera that he's not going to make a complete game on the video, so you're not going to get anything other than his stumbles in the "from scratch" world of game engine design -- instead of actually doing much game design, he's just going to describe its source code, as he writes and then rewrites the engine stumbling through what is basically not game design at all, but rather obliquely game engine design. And we're 400 long-winded, albeit descriptive and sometimes educational, but often frustratingly irrelevant and affected videos exploring into what is probably the world's most publicly well-intention-ed vaporware project of all time.
I was very excited in the beginning. I can only stop by and watch after 10 or 30 videos now simply because I'm afraid to even have Casey on in the background, unintentionally confusing me with this explorations as I program my own projects.
I don't mean to be critical, I think Casey should continue developing and videoing and whatever the hell he likes, but I also want to be honest that I've largely lost interest in the series -- however, it has a positive influence: I really like Melodist Devlog's style and content.
Re: "@lost: you are missing point what Casey is teaching with Handmade Hero. He is not teaching "always write everything from scratch". He is teaching people to understand what they are writing, how it works and why it is needed, instead of blindly following "advices" like "always use X", for example, "always use new and delete"."
- You should use new and delete in C++.
- Should doesn't mean always.
- As for not handling errors, well that's up to your project's requirements. It's good to handle errors in some form. The person with the top answer here agreed with you, but the commentators disagreed. Perhaps join the argument there: https://stackoverflow.com/questio...146/why-is-exception-handling-bad
As for Casey, well, in 2255 when he is "nearly done" wake me out of cryosleep. I think blindly stumbling around in the dark with a team of blindfolded patrons is what it is. He spends more episodes describing some obscure deep and sometimes inaccurate facet of computing than he does describing theories of game design, plot, inventory, statistics, rewards systems or anything else remotely game-like. While sometimes sneezingly-interesting, it definitely does not live up to its claim on the cover. I thought by now I'd be engrossed in dozens of videos about plot, inventory, statistics and game visions, rather than discussing the importance of redesigning a procedural engine test kit that replaced an abandoned attempt at a 2D grid-based world, that grew out of 200+ multi-hour sessions, and a year of setting up and explaining C++ and a manageable OpenGL window in Visual Studio.
The website's claim:
"Handmade Hero is an ongoing project to create a complete, professional-quality game accompanied by videos that explain every single line of its source code."
SPOILER ALERT: This ain't gonna happen any time soon.
Sure. Great. Except, he has admitted time and time again on camera that he's not going to make a complete game on the video, so you're not going to get anything other than his stumbles in the "from scratch" world of game engine design -- instead of actually doing much game design, he's just going to describe its source code, as he writes and then rewrites the engine stumbling through what is basically not game design at all, but rather obliquely game engine design. And we're 400 long-winded, albeit descriptive and sometimes educational, but often frustratingly irrelevant and affected videos exploring into what is probably the world's most publicly well-intention-ed vaporware project of all time.
I was very excited in the beginning. I can only stop by and watch after 10 or 30 videos now simply because I'm afraid to even have Casey on in the background, unintentionally confusing me with this explorations as I program my own projects.
I don't mean to be critical, I think Casey should continue developing and videoing and whatever the hell he likes, but I also want to be honest that I've largely lost interest in the series -- however, it has a positive influence: I really like Melodist Devlog's style and content.
Edited by Lost Astronaut Studios
on
lost
he does describing theories of game design, plot, inventory, statistics, rewards systems or anything else remotely game-like
He had told numerous times that he will not teach and explain game design because he is not game designer. He is programmer, so he goes into game engine-like in details. Not design, only as minimal as possible to get game complete. I feel he gets asked this question in Q&A almost every month. Look up this in episode guide, I'm sure its easy to find.
setting up and explaining C++ and a manageable OpenGL window in Visual Studio.That's the whole point of Handmade Hero. To explain things what and how, so nothing is "black-box". Otherwise it will be - do this, because "reasons". If everybody will care only about "game design" who will be the one which will know how to create "game engine"? This has been discussed many times in HH.
Edited by Mārtiņš Možeiko
on
@mmozeiko
Then why is he programming a game? By that logic: He's obviously not a game programmer, either. And why are most of his credits and resume centered around games? He appears to be a game developer, not a flutist, sharpshooter, nascar driver, or harpsichord player. Game developers develop things other than game engines. They develop game systems, combat systems, combat effects, hitpoints and healing, scorekeeping, AI systems, UIs, UI frameworks, map file formats, map editors, plot and dialog screens, level up systems, inventory management systems, procedural monster generators, statistics and attributes, transitional effects systems, video loaders, library wrappers, highscore servers, multiplayer systems, world generators, particle systems, not just random bobbily heads and randomized grid height thingywigs ... and spending a ton of time displaying debug data for systems you're going to ultimately chuck, well, probably not a good idea . . . . . what ELSE is Casey teaching, aside from about his exploration?
UPDATE: Casey is finally doing something interesting! he's doing room generation...
Then why is he programming a game? By that logic: He's obviously not a game programmer, either. And why are most of his credits and resume centered around games? He appears to be a game developer, not a flutist, sharpshooter, nascar driver, or harpsichord player. Game developers develop things other than game engines. They develop game systems, combat systems, combat effects, hitpoints and healing, scorekeeping, AI systems, UIs, UI frameworks, map file formats, map editors, plot and dialog screens, level up systems, inventory management systems, procedural monster generators, statistics and attributes, transitional effects systems, video loaders, library wrappers, highscore servers, multiplayer systems, world generators, particle systems, not just random bobbily heads and randomized grid height thingywigs ... and spending a ton of time displaying debug data for systems you're going to ultimately chuck, well, probably not a good idea . . . . . what ELSE is Casey teaching, aside from about his exploration?
UPDATE: Casey is finally doing something interesting! he's doing room generation...
Edited by Lost Astronaut Studios
on
Because it is best way how to show how to create game engines. If people will know only how to use "Unity", who will be the one that will create next/better "Unity"? But that's not the only reason. Again - look up more detailed discussions on this topic in episode guide. It was done many times already. Creating game engine just for sake of creating game engine is hard. Without any use case. Exactly same how to write good API's - write usage code first (API = engine, usage code = game).
Edited by Mārtiņš Možeiko
on
@mmozeiko
"Because it is best way how to show how to create game engines."
Not true. It's one way and it's his way only. I'd never do it that way and someone else would do it entirely different. There's a guy on Discord who streams his Unity work and it's amazing, and he focuses on making systems, not just fiddling for 32 hours with what ENDIANESS to prefer. I've written a fine engine with 1800+ classes and I know how easy it is with C++ to wander off into the darkness.
"If people will know only how to use "Unity", who will be the one that will create next/better "Unity"? But that's not the only reason."
People will not only know how to use "Unity" because there are more game engines than just "Unity" -- and, as far as $$$ it's probably a good idea to learn Unity as long as it has a paying skillset. It's an irrational fear rooted in ignorance that Unity is going to be the Adolf Hitler Nazi Reich of Game Engines. Just because there is Apache Cordova doesn't mean there won't be native mobile app developers.
Other game engines than Unity: https://en.wikipedia.org/wiki/List_of_game_engines
This is one of those "People own cars so they won't ever be able to ride horses again" arguments. Just ain't true.
"Because it is best way how to show how to create game engines."
Not true. It's one way and it's his way only. I'd never do it that way and someone else would do it entirely different. There's a guy on Discord who streams his Unity work and it's amazing, and he focuses on making systems, not just fiddling for 32 hours with what ENDIANESS to prefer. I've written a fine engine with 1800+ classes and I know how easy it is with C++ to wander off into the darkness.
"If people will know only how to use "Unity", who will be the one that will create next/better "Unity"? But that's not the only reason."
People will not only know how to use "Unity" because there are more game engines than just "Unity" -- and, as far as $$$ it's probably a good idea to learn Unity as long as it has a paying skillset. It's an irrational fear rooted in ignorance that Unity is going to be the Adolf Hitler Nazi Reich of Game Engines. Just because there is Apache Cordova doesn't mean there won't be native mobile app developers.
Other game engines than Unity: https://en.wikipedia.org/wiki/List_of_game_engines
This is one of those "People own cars so they won't ever be able to ride horses again" arguments. Just ain't true.