And now, there are three.

Three what? Three projects comprising Asylum itself. In the beginning, Asylum was monolithic, a single asylum.exe that held all the game code. Then, I spun the engine out from the game, giving me asylum.exe and asylum.dll. Today, I spun the platform-specific code from the engine, which now rests in asylum.exe, while the engine code is in engine.dll. The file formerly known as asylum.dll is now asylum/game.dll and game resources now share a folder with it.

Why did I do this? Because I needed a way to provide services to the game DLL from the engine, without going through callback hell. So, now asylum.exe calls game_main in engine.dll, passing along a struct of function pointers (well, virtual functions) as well as argc and argv. (For Win32 I've had to chop WinMain's lpCmdLine to make argc and argv. I'd show how, but there's more than enough code out on the internet that already demonstrates it.) The game DLL depends on the engine DLL (implicit dynamic linking) while the engine DLL is only interested in what the game DLL registers with it (game states, entities, etc). The engine DLL depends on the executable (reverse explicit dynamic linking -- that means that the executable calls LoadLibrary or dlopen on the DLL rather than the other way around) and when the engine's entry point, game_main, is called, it gets from the executable what it needs.

So far there's pretty much no platform specific code in engine.dll or game.dll, so to get Asylum building on other platforms all I need is to implement the platform specific side of things (getLibraryHandle, getLibraryFunction, getDirectoryPath, etc) and pass along control to game_main. Easier done than said.

Asylum stats: