Programming games: Should SDL be hidden behind an interface?
Moderator: Forum Moderators
-
benheath85
- Posts: 13
- Joined: October 15th, 2004, 3:31 am
- Location: dang near the mexican border
Programming games: Should SDL be hidden behind an interface?
How's it going, everyone? I'm working on a 2D game engine in C that at present uses SDL. I'm looking for some help and advice on it, and I thought I would post here about it rather than the Coder's Corner. If you're interested, please e-mail me at theincredibleben@yahoo.com.
One of my concerns while I write this engine of mine is how much of it will have to be re-written later on. At present, my program uses SDL and its addons for multimedia, and I'm considering hiding all of these structures and function calls behind an interface of some sort, even though SDL is itself an interface. The idea is to follow ESR's rule of separating engines from interfaces[1], brought on by reading old programs by Diana Gruber and Andre LaMothe. Their programs used FastGraph and DirectX, respectively, and they all did essentially the same thing. Their code also did not last long, even though both of these APIs were sold to last forever. As much I as I want to say that SDL will last longer because it is Free, there have been enough X toolkits gone extinct to prove me wrong.
One design option is to model my engine after Mark Kilgard's Glut, where events are tied to function callbacks and everything eventually comes down to a "main loop" function call. This is a very conservative setup that privatizes much of the engine, which really shouldn't be very large anyway. My concern with this is speed, whether or not the frequent calls to function pointers for events will be fast enough. It will probably be fine on today's machines, but I'll really have to have it tested on older machines as well.
A system similar to Quake 2's "game api" system could also be used. Here, some private engine functions could be put in an interface structure that is passed to the game subsystem. In return, the game subsystem would give an interface to its own functions to our engine. That way, the game knows only what it needs to know about our engine, and the engine knows only what it needs to know about our game. The game itself could also be placed in a dynamic library, again like Quake 2. This would ease compilation and development by quite a bit.
Wow. This started as a post about hiding SDL behind an interface, and look where I went with it. :P I can't wait for your response. :) Agape.
[1] See the Art of Unix Programming, 2003 by Eric S. Raymond.
One of my concerns while I write this engine of mine is how much of it will have to be re-written later on. At present, my program uses SDL and its addons for multimedia, and I'm considering hiding all of these structures and function calls behind an interface of some sort, even though SDL is itself an interface. The idea is to follow ESR's rule of separating engines from interfaces[1], brought on by reading old programs by Diana Gruber and Andre LaMothe. Their programs used FastGraph and DirectX, respectively, and they all did essentially the same thing. Their code also did not last long, even though both of these APIs were sold to last forever. As much I as I want to say that SDL will last longer because it is Free, there have been enough X toolkits gone extinct to prove me wrong.
One design option is to model my engine after Mark Kilgard's Glut, where events are tied to function callbacks and everything eventually comes down to a "main loop" function call. This is a very conservative setup that privatizes much of the engine, which really shouldn't be very large anyway. My concern with this is speed, whether or not the frequent calls to function pointers for events will be fast enough. It will probably be fine on today's machines, but I'll really have to have it tested on older machines as well.
A system similar to Quake 2's "game api" system could also be used. Here, some private engine functions could be put in an interface structure that is passed to the game subsystem. In return, the game subsystem would give an interface to its own functions to our engine. That way, the game knows only what it needs to know about our engine, and the engine knows only what it needs to know about our game. The game itself could also be placed in a dynamic library, again like Quake 2. This would ease compilation and development by quite a bit.
Wow. This started as a post about hiding SDL behind an interface, and look where I went with it. :P I can't wait for your response. :) Agape.
[1] See the Art of Unix Programming, 2003 by Eric S. Raymond.
Benjamin Heath
For those about to rock...
For those about to rock...
Personally, I think that you'll effectively do this anyway. Your drawing routines should all be collected into a single code module; the same goes for your UI code. All that code is intimately and necessarily involved with your underlying drawing library anyway: if you change drawing libraries, either you can fix your code with (more or less) a search-and-replace, or the concepts used by the libraries are incompatible and you need to make deeper changes anyway. Building an extra pass-through wrapper around SDL sounds like overengineering to me.
For UI code (like dialogs and stuff) I'd recommend using libsigc++, a very nice abstraction of the signal/slot approach to typesafe callbacks. It's a really nice foundation for a widget framework (and I've actually used it to do that...although the "drawing backend" was ncurses). If the callbacks are only being invoked in response to "real-time" events (like user input or a 30fps counter), I wouldn't worry about the speed on any computer: (a) it can handle that without blinking if it was made in the last decade or so (and that's a conservative estimate), (b) whatever goes on inside the callback will typically be several orders of magnitude more time-consuming than a single pointer lookup anyway; and (c) premature optimization is the root of all evil.
Daniel
For UI code (like dialogs and stuff) I'd recommend using libsigc++, a very nice abstraction of the signal/slot approach to typesafe callbacks. It's a really nice foundation for a widget framework (and I've actually used it to do that...although the "drawing backend" was ncurses). If the callbacks are only being invoked in response to "real-time" events (like user input or a 30fps counter), I wouldn't worry about the speed on any computer: (a) it can handle that without blinking if it was made in the last decade or so (and that's a conservative estimate), (b) whatever goes on inside the callback will typically be several orders of magnitude more time-consuming than a single pointer lookup anyway; and (c) premature optimization is the root of all evil.
Daniel
-
benheath85
- Posts: 13
- Joined: October 15th, 2004, 3:31 am
- Location: dang near the mexican border
Integral: You're right. :) It would be very illogical to hide SDL behind some glue layer. The design would be anemic. :(
The idea of a "main loop" function could also be removed. The idea is only to hide everything from main(), which is ridiculous. Event callbacks could still be supported and would add a great deal of flexibility to the engine. (Thank you, Integral, for your words of encouragement on this. :)
The idea of a "main loop" function could also be removed. The idea is only to hide everything from main(), which is ridiculous. Event callbacks could still be supported and would add a great deal of flexibility to the engine. (Thank you, Integral, for your words of encouragement on this. :)
Benjamin Heath
For those about to rock...
For those about to rock...