Slashdot Mirror
Breathing New Life Into Old DirectDraw Games
An anonymous reader writes "I bought a bunch of old Wing Commander games for Windows, but they use DirectDraw, which Microsoft has deprecated. They don't work too well under Windows 7, so I ended up reimplementing ddraw.dll using OpenGL to output the games' graphics. I wrote an article describing the process and all the fun workarounds I had to come up with, and released all related source code for others to hack on."
I haven't read TFA yet
but wouldn't this have been a prime use-case for Wine on Windows?
Funny you should mention DX3. Microsoft actually removed some surface caps flags in the transition from DX3 to DX5, and silently flipped the orientation that .BMP files were loaded (i.e. loaded them 'right way up' rather than 'upside down' as they're stored in the file). I know that was like three ice ages ago in Dev Years, but it still hurts when I think about it.
I realise that TheFineSummary talks about Windows 7, but there's still a fair number of XP boxen out there, for which Direct2D isn't an option. That said, I'd guess (as the article is down) that it's more of an ideological position, or - given that it's clearly a hobby project - just what the author is familiar with, or enjoys using. Given that we're talking about playing games here, I'd go with the latter explanation.
I do intend to RTFA when it recovers, since I find replacing/subverting dlls quite fun. I kludged up some code a while back to create a shim dll that can be used as the basis for selectively replacing functions in dlls, while calling through to the 'real' one for the other functions, so you can easily hack some functionality without having to re-implement the whole thing.
If you were blocking sigs, you wouldn't have to read this.
Indeed, in fact, this was precisely one of the problems DirectX was always designed to solve from the start, it was designed to provide a multimedia API that could both move with the times and retain backwards compatibility.
Issues with older games tend to come down to hardware specific optimisations, obsolete libraries such as Glide, or OS specific code.
For the most part, stuff written with Microsoft's officially provided Windows APIs even back to Windows 95 (and sometimes even further back than that) tends to still run. It's the stuff that doesn't use those APIs that often causes the problems.
For better or worse, backwards compatbility is one thing that Microsoft certainly does tend to get right most the time. It's just that companies often ignore backwards compatibility when building new apps and just build for the now. Sometimes this is excused, i.e. game companies doing low level optimisations to improve performance, other times it's some MBA falling hook line and sinker for the sales pitch of some fly by night company providing an obscure set of code libraries and mandating all his developers use it.
I still have apps I wrote in C using the raw Win32 API back in 1995/1996 that work absolutely fine to this day.
Chances are if a game doesn't run, DirectX version is the least of it's troubles.