Advertisement Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

Bonsai - Dynamic window backend

Sign in to follow this  


So, as noted in my last entry, for this 'thing' to be cross platform it's going to need something other than my own windowing framework for bring up windows and processing events, simply due to how tied to windows it is and the lack of a Linux and OS X version.

So, with that in mind I sat down and figured out just what I'd need to abstract in order to make 'stuff' plugable at runtime.

The window manager was basically needed for the following functions;

- On Gfx engine startup an new instance was made
- Needed to create a window
- Needed to destory a window
- Register events for handling
- Unregister events for handling
- Register the Lua event "constants"
- Deal with event 'dispatch'
- Swap the buffers

Intrestingly, each of those breaks down to a function call, well more or less, which was handy. So, from there it was a simple matter of working out the interface and in the process adding a 'show' function. So, the DLL's public interface is just;

WINDOWMGR_API void createManager(void);
WINDOWMGR_API void shutdownManager();
WINDOWMGR_API int createWindow(int width, int height, int fullscreen);
WINDOWMGR_API void showWindow()
WINDOWMGR_API void destroyWindow();
WINDOWMGR_API void swapBuffers();
WINDOWMGR_API void registerWindowEvents(int window);
WINDOWMGR_API void clearWindowEvents(int window);
WINDOWMGR_API void getEvents(lua_State *L);
WINDOWMGR_API void registerEvents(lua_State *L);

So, in theory, any DLL which sanely impliments these functions can be used as a windowing backend.

All this just required one final change; I decided to make this library dynamic, I'm sure I had a good rational at the time, but we'll not worry about that. So, a few mins of code later and we have a 'dynamic loaded' section of code which loads the dll and extracts the correct function names.

After that it was a matter of changing various graphics and event functions to point at the new dyanamically setup functions, hit compile, sort out the error [grin], hit compile, hit run and watch the application do what it did before but this time with a dynamic backend.

So, in theory, if an SDL backend was written this 'engine' would now work on any of the platforms which supports SDL and OpenGL; win [grin]
(Well, ok, a couple of the Win32 only pieces of functionality would need to be ported as well but currently that stands at two source files).

Still need to get keyboard support into the message loop, I'll probably do that tonight as I'm on a bit of a roll.

Once keyboard support is in it's a matter of figuring out what else I need to add to support the game I wrote a few months back for my degree, I think I'm nearly there however (a few colour constants are needed, I know that for certain, and I need a way to deal with sprite sheets).

It goes well [grin]
Sign in to follow this  

1 Comment

Recommended Comments

If you need platform-specific stuff that isn't handled by SDL, you could probably go rooting through Propane Injector. I know I have a bunch of stuff in there for getting window caps on OS X and Linux and Windows, CPUID, dialogue box stuff and other assorted gubbins.

Lemme know if you want me to cut you a fresh branch.

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!