Inspired by some early Handmade Hero episodes and Karl Zylinski’s posts on Odin Hot-Reloading I had a go at implementing it in my Vulkan+GLFW renderer/game framework.
I liked the approach here (odin-raylib-hot-reload-game-template/source/main_hot_reload/main_hot_reload.odin at main · karl-zylinski/odin-raylib-hot-reload-game-template · GitHub), where the “application” .exe is a very thin wrapper around the game.dll, and only the game files import the used vendor library (raylib in that example).
This approach doesn’t really work for vulkan or glfw, since these have some global state, which gets “lost” when unloading the .dll. For vulkan, since the global state seems to be only the proc table in odin bindings, transfering that from old .dll to the new one seems pretty easy, but for glfw, since the global state is in C code, transfering that doesn’t seem viable.
The obvious solution would be to only import these platform-level libraries on the .exe application level, and define some API for the .dll to use, and while that probably works fine, I was wondering if there’s any way to keep the ability to have vulkan and glfw calls from anywhere in game code, since I really enjoy that for the sake of iteration.
I was wondering if there is some elegant way of having the thin wrapper style of application .exe and not modyfing existing game code, while using vulkan+glfw and other libraries that have some global state.