Porting a game from DirectDraw to SDL

Started by
4 comments, last by Drew_Benton 19 years, 4 months ago
Hi there, As the topic suggest, I am wondering about how to port a DirectDraw game to SDL. As far as I have looked and searched so far, there are several possibilities: - Changing all calls from DirectDraw to SDL - Building an abstraction layer that supports both - #ifdef SDL, #endif... - Re-implementing those DirectDraw function calls or use Winelib And then, what is the way to get the smoothest transition? There is no way a raw Win32/DirectDraw program is going to compile on GCC without an error list that reaches to the moon! Also, there are some things that VC++ finds okay, but GCC doesn't - which implies a lot of warnings (no newline at end of file, unsafe cast, etc...). What to do about this? Surpress them? Fix them one by one? What do you think of it? What is the best way to do it? Any links? Thanks
Advertisement
How big is the DirectDraw Game? I think if its under 20,000 lines you could get your game ported to SDL using your suggestion of "Changing all calls from DirectDraw to SDL" in less than a few hours.

Have you worked with SDL before? Some of the things in DirectDraw that require 50 or so lines can be done in SDL in one line.

I wouldn't do the #ifdef ... #endif blocks unless you want Windows users to be able to use the DirectDraw version. SDL uses DirectDraw on Windows because its a .dll library, so it shouldn't make much of a difference speed-wise.
Well, the game is rather huge to me. But the good part is that there is a relatively low amount of platform-specific code.

And yes, you are probably right. Thanks.
I ported one of my earlier games from DirectDraw to SDL and found initially it was a mess. After a few days of fighting bugs and crashes I decided to just re-write the graphics portion from the ground up. Since I already knew what I wanted it to do and had a working model it only took about 5 hours to completely port. Good luck.
Steven Bradley .:Personal Journal:. .:WEBPLATES:. .:CGP Beginners Group:. "Time is our most precious resource yet it is the resource we most often waste." ~ Dr. R.M. Powell
Well, it depends on how much ddraw is embedded into your system. If you take the time to make a few generic clases that provide an extra layer of abstraction from the underlaying API it makes your code more modularized. For example, you make a generic surface class:
class CSurface{private:    SDL_Surface    *m_surface;public:    CSurface();    ~CSurface();    void Blit( CSurface *source, CRect *rect, int x, int y );};


Directdraw and SDL use different rectangle types too so it couldn't hurt to abstract that into a class of your own as well. This way if you decide to change the underlting API, then the calls to these interfaces all over your game don't have to change, just the underlying code behind the interfaces.

I hope that makes sense.
Evillive2
Quote:Original post by Sijmen
Also, there are some things that VC++ finds okay, but GCC doesn't - which implies a lot of warnings (no newline at end of file, unsafe cast, etc...). What to do about this? Surpress them? Fix them one by one?


Too bad there is no VC++ for linux [headshake]. Anyways I think you should ask yourself this: "Why are you prting a game from DD to SDL?" If there is a reason such as it's a job, or whatever reason other than "for fun", I think you should just take the time and fix anything that GCC complains about. I think the #ifdef SDL, #endif... is a great idea, but bad design, because if you miss one sction, it could kill you. The reason being you can always see what was there in DD when you make the SDL port. When you finish the port, you can then jsut delete any #ifdef DD, so the SDL code is left and it looks nice.

This topic is closed to new replies.

Advertisement