mirror of
https://github.com/Ed94/HandmadeHero.git
synced 2024-09-20 11:47:34 -07:00
30 lines
2.2 KiB
Markdown
30 lines
2.2 KiB
Markdown
|
# Day 14
|
||
|
|
|
||
|
|
The `game_state` example felt like a forced way to start doing memory management but thats fine.
|
||
|
|
I'm not making any design changes to it other than setting it as engine::Memory instead of game_memory (since I'm doing 3 api layers instead of the 2 hes doing).
|
||
|
|
|
||
|
|
Learning about the virtual memory mapping was nice, it was something on a backburner for me to learn about but I never got around to it.
|
||
|
|
The address setting was quite awesome to see.
|
||
|
|
|
||
|
|
## Some thoughts on platform API
|
||
|
|
|
||
|
|
I like Casey's one call idea he emphasized in the Q&A, don't really want to detract from that.
|
||
|
|
|
||
|
|
Instead I just want to change it so that by the time you enter the engine loop you are guaranteed to have all the engine data provided by the platform layer.
|
||
|
|
But, without having to shove everything in the procedure captures. Instead, just have an global engine context thats invalid until engine initialization is done by the platfomr layer.
|
||
|
|
|
||
|
|
|
||
|
|
So it might end up something like this:
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
It ends up making two api paths, one for engine to do initialization when platform provides all the critical data engine needs, and another where the platform provides the engine update function.
|
||
|
|
|
||
|
|
It will be known to the user and engine that platform will update some of the engine data ( like input, render, sound, etc ), which will be done in the platform update function.
|
||
|
|
This is already the case, just need to convey it more strongly if I'm decoupling it from the procedure captures.
|
||
|
|
|
||
|
|
This is so that I don't have to do insane chaining to pass these captures when I know some of this data should be contextually known to all procedures within the engine.
|
||
|
|
I have a feeling Casey may already aleivate this or show that it's not a problem in the future so we'll see and I'll adjust accordingly.
|
||
|
|
|
||
|
|
I premtively also did the boxes for an 'editor' and 'game' api. Where there could be possible `n` amount of api layers. I'm not sure if I'll do this, but I'm leaving it open for now. What will most likely happen is they'll still be priority to keep it to a very minimal amount, and not give the game or editor the ability to poke at the engine much at all (which leads to the circular API Casey is warning about).
|