Hi I want to get a bit of feedback for my current architecture/code organisation.
TL;DR: Just me explaining a bit how and why I implemented things like I did and asking for feedback.
1. Just like Casey I pass a few platform services (currently only file IO and dll reload) via function pointer to the game dll, I have open/close, write/read, get/setposition and get file size. Instead of using Win32 functions I used only C runtime functions to implement these "services". Since I was a bit conflicted whether the CRT implementation should really sit in the platform launcher or not I moved the implementation of these functions to a header file in the engine and inlined them. The Win32 launcher just calls the CRT functions to "implement" the platform specific version just so that I get a function pointer to pass to the game but still can implement it another way later.
2. Since I use VS (compile in VS, not on the command line) I had to use a few workarounds to get dll hotloading and recompiling while debugging working like in HmH. Since the platform dependent code was so easy to format into just 3 functions (Load/Unload and HasChanged) I exposed them to the game via my platform services but is this sensible since I got a round trip in there to pass the HMODULE back to the Unload function?
3. I used the platform service to implement a replay system similar to the HmH one but again since I used only platform independent means for the implementation it felt wrong to stuff the functions and types into the launcher. Is it reasonable to expose the replay system to the game code so it can be used to implement...well replay?
4. Since I already tried using the replay system from the game code I stumbled into a problem: Where should a game allocated replay buffer live? Since I found only 3 reasonable options static in dll, static in launcher or in game memory I tried them and could eliminate dll and platform since dll memory would get lost if the code was hotloaded and in platform code it wouldn't be a game feature any more. If you stuff the replay buffer into game memory be aware that your playback/recording code handles setting replay state / writing/reading the game memory correctly or you will end up with a playback file that starts a recording at the first frame. Since I didn't want to deal with this at the moment I plugged a small buffer into my platform services to hold the replay buffer.
5. Later I thought about the buffer in my platform services and decided I would use it as my non game data buffer similar like a storage for view options in a MVC architecture(renderer settings/key mappings/etc). Is this a reasonable use of my "non game memory" the game get passed or should I get rid of it entirely?
I would really appreciate your feedback.
TL;DR: Just me explaining a bit how and why I implemented things like I did and asking for feedback.
1. Just like Casey I pass a few platform services (currently only file IO and dll reload) via function pointer to the game dll, I have open/close, write/read, get/setposition and get file size. Instead of using Win32 functions I used only C runtime functions to implement these "services". Since I was a bit conflicted whether the CRT implementation should really sit in the platform launcher or not I moved the implementation of these functions to a header file in the engine and inlined them. The Win32 launcher just calls the CRT functions to "implement" the platform specific version just so that I get a function pointer to pass to the game but still can implement it another way later.
2. Since I use VS (compile in VS, not on the command line) I had to use a few workarounds to get dll hotloading and recompiling while debugging working like in HmH. Since the platform dependent code was so easy to format into just 3 functions (Load/Unload and HasChanged) I exposed them to the game via my platform services but is this sensible since I got a round trip in there to pass the HMODULE back to the Unload function?
3. I used the platform service to implement a replay system similar to the HmH one but again since I used only platform independent means for the implementation it felt wrong to stuff the functions and types into the launcher. Is it reasonable to expose the replay system to the game code so it can be used to implement...well replay?
4. Since I already tried using the replay system from the game code I stumbled into a problem: Where should a game allocated replay buffer live? Since I found only 3 reasonable options static in dll, static in launcher or in game memory I tried them and could eliminate dll and platform since dll memory would get lost if the code was hotloaded and in platform code it wouldn't be a game feature any more. If you stuff the replay buffer into game memory be aware that your playback/recording code handles setting replay state / writing/reading the game memory correctly or you will end up with a playback file that starts a recording at the first frame. Since I didn't want to deal with this at the moment I plugged a small buffer into my platform services to hold the replay buffer.
5. Later I thought about the buffer in my platform services and decided I would use it as my non game data buffer similar like a storage for view options in a MVC architecture(renderer settings/key mappings/etc). Is this a reasonable use of my "non game memory" the game get passed or should I get rid of it entirely?
I would really appreciate your feedback.