Sign in to follow this  
jwezorek

porting an old codebase to SDL

Recommended Posts

jwezorek    2663
I've been thinking about finishing an old game project that I started and dropped a long time ago, maybe 10 years ago, and was wondering if there would be any value to porting the whole thing to SDL (or, I guess, Allegro). The game is 2D and is written to, I think, DirectX 8 or whatever was current around 2000 or 2001. I wrote a basic 2D graphics layer on top of DirectX and then never really had to worry about Direct3D once that layer was written. The core game is basically done, but it needs polish and needs to be bullet-proofed to go out into the wild. What I would hope to gain out of using SDL basically is stability/reliability, although portability would be great too if it's possible. My old code doesn't handle lost devices, will fail ungracefully if the graphics mode it wants isn't present on the system, and generally sets up DirectX without checking return values and so forth as quickly as I could do it so that it worked on my system and I could work on the game itself. Also it's using DirectInput which I think is deprecated right? Will SDL take care of the kinds of stability details that I am referring to here? How much work would it be to port a 2D DirectX 8 game to SDL? Does SDL have it's own blitting calls or would my game's rendering implementation still have to be on top of DirectX within my codebase?

Share this post


Link to post
Share on other sites
jyk    2094
Quote:
I've been thinking about finishing an old game project that I started and dropped a long time ago, maybe 10 years ago, and was wondering if there would be any value to porting the whole thing to SDL (or, I guess, Allegro).
Of the two libraries you mentioned (SDL and Allegro), I would recommend SDL.
Quote:
What I would hope to gain out of using SDL basically is stability/reliability, although portability would be great too if it's possible.
Unless you rewrote the renderer as well (e.g. to use OpenGL), you'd still be limited to platforms that support Direct3D, even if you ported the application to SDL. Since one of the main reasons to use SDL is for portability, it might therefore be the case that porting your app to SDL wouldn't gain you that much.
Quote:
My old code doesn't handle lost devices
SDL won't help with this. You can use SDL to set up a window to which you can then attach a Direct3D rendering context, but handling lost devices is still up to you.

I've read that later versions of Direct3D (later than version 9) handle device loss more gracefully, but I don't know the details.
Quote:
will fail ungracefully if the graphics mode it wants isn't present on the system
SDL can help with this (by providing a list of supported video modes), but you can of course do the same thing using native Direct3D/WinAPI code.
Quote:
and generally sets up DirectX without checking return values and so forth as quickly as I could do it so that it worked on my system and I could work on the game itself.
SDL won't help with this either (again, even if you use SDL to set up the window, you still have to do all the D3D setup 'manually' yourself).
Quote:
Also it's using DirectInput which I think is deprecated right?
Right. For mouse and keyboard input at least, Microsoft now recommends the use of the regular Windows message loop. If you were to use SDL, you would use the SDL event system (which itself is built on top of the Windows message loop).
Quote:
Does SDL have it's own blitting calls or would my game's rendering implementation still have to be on top of DirectX within my codebase?
You would still use your existing DirectX code (SDL does have support for software blitting, but you'd probably be better off sticking with D3D).

There's a new version of SDL in the works (1.3) that has some nice new features (e.g. built-in hardware-accelerated 2-d graphics via OpenGL), but it's still in development. There's also SFML, although I'm not sure if the OS X version of SFML is being supported right now. Of course if you wanted to completely rewrite your game and were open to switching languages, APIs, etc., there are quite a few other options as well, such as XNA.

I assume the original game was written in C or C++? If so, and if you intend to stick with Direct3D, you might be better off just sticking with native WinAPI code and getting your code cleaned up accordingly. Again, one of the main advantages of SDL is portability, so writing an SDL-based app that relies on Direct3D for rendering may or may not be worth the trouble. I'm not saying there'd be no reason to do it - SDL does handle a lot of details for you, and it would make porting the application to other platforms easier in the future. However, due to the fact that SDL is an abstraction of the underlying system and has to expose a 'lowest common denominator' subset of features, it can also be limiting in some ways.

Anyway, that's just my take on it - hope it's of some help.

Share this post


Link to post
Share on other sites
jwezorek    2663
Thanks for the reply. Yeah, the code is C/C++ (I should've mentioned that) so you've pretty much answered my questions.

I guess I was wondering if there was a way of configuring SDL for a 2D game such that it uses hardware acceleration under the hood and I don't have to know anything about it. From what you're saying this isn't possible with the current release but may be coming in version 1.3 via OpenGL. If I don't port my rendering code to OpenGL all I would get from SDL is that it would take care of the Win32 portion of the app and allow me to remove the app's dependence on DirectInput easily. This doesn't seem worth the trouble -- although porting it to OpenGL is a somewhat appealing idea but would be a ton of work given that I've never touched OpenGL in my life.

I'm just going to clean it all up and C++-ify a couple of files that I wrote in C because I thought C++ would be too slow, which in hindsight was just superstition.

Share this post


Link to post
Share on other sites
jyk    2094
Quote:
I guess I was wondering if there was a way of configuring SDL for a 2D game such that it uses hardware acceleration under the hood and I don't have to know anything about it. From what you're saying this isn't possible with the current release but may be coming in version 1.3 via OpenGL.
I believe that is correct. I remember there being something about 'hardware surfaces' in SDL, but I don't think many people use that functionality anymore. These days, I think 'real' hardware-accelerated graphics (e.g. via OpenGL or Direct3D) is probably the way to go.
Quote:
If I don't port my rendering code to OpenGL all I would get from SDL is that it would take care of the Win32 portion of the app and allow me to remove the app's dependence on DirectInput easily.
Yeah, pretty much. SDL offers a few other things as well, such as low-level support for sound (and higher-level support for sound via SDL_mixer), but if you're sticking with DirectX you should already have that functionality available.

Share this post


Link to post
Share on other sites
Kylotan    9860
Quote:
Original post by jwezorek
I guess I was wondering if there was a way of configuring SDL for a 2D game such that it uses hardware acceleration under the hood and I don't have to know anything about it. From what you're saying this isn't possible with the current release but may be coming in version 1.3 via OpenGL.

I think I've been waiting for version 1.3 for about 10 years now.

You could use SFML instead, which gives you most of the benefits of SDL plus hardware accelerated graphics. But personally I don't think it's worth using an extra library for reliability alone - just fix up your own code.

Share this post


Link to post
Share on other sites

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

Sign in to follow this