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."
Fastest slashdotting *ever*
My own DirectDraw apps from 1996 work great in Windows 7. The API is deprecated in the sense that Microsoft no longer recommends using it, and who knows if they're still even shipping ddraw.h, for that matter. But as a COM component, runtime support for IDirectDraw isn't any more endangered than CreateWindow().
As its difficult to get through the Slashdotting (I can't reach the site), this would be "The Kilrathi Saga" versions of the games - almost as valuable as a WoW Vanilla Collector's Edition to WC fans - which were "upgraded" versions of the original DOS Watcom C games for Windows 95. I say "upgraded" because I was once speaking to one of the original programmers who were working on the Kilrathi Saga edition and said that they couldn't even convert WC1. He called the original source a "Goat-fuck-hack" demo which Roberts put together to get a job at Origin, so they instead tinkered with a DirectDraw-wrapped WC2 engine.
The original DOS versions of the games, alternatively, work fine through DosBox.
"The true measure of a person is how they act when they know they won't get caught." - DSRilk
The server has 'asploded so I can't read the article (note to people: don't submit your shit to /. if your server isn't ready for it) but I'm questioning the summary. Windows 7 does have DirectDraw. ddraw.dll is present in the Windows directory.
As far as I know, compatibility is maintained for ALL versions of DirectX back to the beginning. Things stop being supported, but that just means they aren't included with the new APIs. So you can't use DirectDraw from DirectX 11 APIs, but if you have an old DirectX 6 game, it'll still work fine.
As a practical matter the original Fallout runs, and it wants DirectX 3 to do its thing.
I'm not claiming that the author didn't have to do something to make these games work, but I think he may be confused about the situation.
I also wonder on his methods. Why would you use OpenGL to reimplement DirectDraw on Windows 7? DDraw's replacement is Direct2D, which is a native Windows API. OpenGL works fine on Windows, but only in the event that the company who makes the graphics card chooses to write an ICD for it. Direct2D is automatic for anything with WDDM 1.1 drivers.
Except the Bosnia war ended in 1995. so your friend could not be in combat zone.
(I know. I was there. I still am.)
Looks like this is some little personal site, perhaps run on a server in a broom closet (I run such a closet server at my house). I have no idea why the author thought it would be a good idea to submit that to Slashdot.
Were there ever anything I wanted to submit, I wouldn't stick on my closet server, I'd stick it on my Pair server and link to it there. Slashdot people are very, very clickly. Anyone who submits to here ought to know that.
The server's crashing, but coral cache managed to get the text:
http://sol.gfxile.net.nyud.net/ddhack/
In the Beginning
It all started about a month ago, when one friend of mine had decided to follow his dreams and was moving to the states, and he had to get rid of a lot of stuff. Among his discard pile was a bunch of Wing Commander games, which I bought off him, figuring they might be interesting research material, as I'm planning on a game with similar game play structure (as in story combined with game play, not a 3d space shooter).
So, I found myself in the possession of Wing Commanders 1, 2, 3 and 4, all Windows versions - the Kilrathi Saga and WC4CD to be specific. I installed the first and tried it out. My Win7 switched to 256 colors at a 640x480 resolution, but the game ran.. with completely wrong palette.
Bugged by this I played with the compatibility options, and got the game to almost work well, with the palette going wrong at some points.. so the game was sort of playable, but I hated the fact that Windows changed to 256 colors and I couldn't see my mailbox properly in the other screen, etc.
I also tried WC2 and WC3, and they had similar - or worse - problems. I even learned the steps to get WC3 to work properly:
1. Find the WC3W.EXE executable, turn on (basically) all the compatibility options.
2. Start task manager.
3. Find and kill all instances of explorer.exe. Your desktop will disappear, along with the task bar.
4. Using task manager, launch WC3W.EXE
Naturally the screen resolution and color mode will be 640x480 and 256 colors, but if you've bent backwards that much, you probably don't care all that much.
Seeing that the games use DirectDraw, I decided to roll my own.
Doing the Homework
The first step is always to look for prior art. Maybe someone had written a new ddraw.dll already, and I could just use it. As it happens, lots of people have, but nothing that's useful for me. Most of the ddraw.dll hacks are actually wrappers - that get between the game and the real ddraw.dll, change something subtle, but let the real ddraw.dll do the heavy lifting.
The point of these hacks is to fix small problems, like games that ignore surface pitch, require cleared surfaces or some such. In one case I found a forum thread claiming that deleting ddraw.dll from the game's directory fixes something, so in this case it's a hack gone wrong.
After further searching I found a project which actually released sources, with a liberal license even. It was a wrapper project (meaning, again, that they just call the real ddraw.dll), only supported DirectDraw7 and only very small parts of it, but it showed me how to get going.
I also dug up old DirectX SDK:s from my personal CD stack, as Microsoft has helpfully nuked all old DirectDraw documentation off the online MSDN. Thanks, dudes.
Wing Commander 1
Wing Commander 1 for Windows uses DirectDraw2. There's no real reason it couldn't just use DirectDraw1, considering that all it does is locking the front buffer and dumping a frame to it, along with some palette manipulation.
Or well, that's not the whole truth. If the game can set a 320x200 mode, it does what I described above. If this fails, it tries to set up 640x400, and after that fails, 640x480. In the two higher resolution modes, the game allocates a software 320x200 buffer, and uses blt() to scale it up 2x, meaning that in 640x480 mode, black bars are introduced to the top and the bottom, and the aspect ratio is wrong.
When playing WC1 it astonishes me just how much love has gone into the it when compared to later games. The later ones may be better in some ways, but the polish that can be experienced in WC1 is gone.
Anyway, I started by writing a wrapper that just dumps out log about what calls are made with what parameters, and then went on to implement a hack dll that only implements those calls.
The hack dll resizes the application's window to desktop resolution, sets up an OpenGL context, uploads
http://sol.gfxile.net.nyud.net/ddhack/
Most of the pictures got loaded into the cache
[Fuck Beta]
o0t!
Virtualization has gotten really good these days, for those that don't keep up with it. You can virtualize modern OSes at near native speed. Running servers in VMs is getting real common. At work we have a few servers that we keep as physical boxes, like our SQL server, but the majority of our servers are virtual. Not only can that save on hardware costs (we have like 30 virtual servers on 4 physical servers) but it provides some amazing flexibility.
Now when talking older OSes, it isn't as speedy. Not all of the modern tricks work as well, and there's often not client drivers to accelerate things... However there doesn't need to be. Consider that when Windows 95 was about a Pentium was as good as things got. Well when you are dealing with something that slow, you can incur a hell of a lot of overhead in your virtualization and still maintain good speed.
As another posted mentioned, DOSBox is a good example. So are various console emulators.
I AM a fan of old games, and have played around with this. For DOS games, DOSBox works great. For probably 99.9% of Windows games, they run natively on Windows 7 64-bit. The rest seem to run fine on Windows XP 32-bit which works real well in VMWare, Virtual Box, and even MS's own VM is you have professional or ultimate. I've not yet come across a game for which I'd need to get 95 or 98 and virtualize those. I have done it at work though, and 98 does function just fine.
As you said, doesn't have to be optimal.
Having been clipped in the calf muscle by an RPG while serving with IFOR in Sarajevo in 2002, I can personally tell you that even though the war ended, it was most certainly still a combat zone for many years.
Of course you can install Windows 98 in a virtual machine, and it'll run just as stably as it did on the original hardware. It amazes me that you think otherwise, and feel the need to spew all over the discussion with your insanity.
You can also create a registry key that solves the problem more permanently.
There are details here: http://go.hopx.net/2010/05/256-color-issues-with-directdraw-and.html
LHX : Attack Chopper. Lost many many hours to that one in the early 90's
Because more surface area is covered by texels that are part of one smooth surface than texels that are supposed to represent hard edges. Edges might look better with nearest-neighbor (provided the texture has no anti-aliasing) but smooth surfaces will show banding that doesn't belong there.
Justice is the sheep getting arrested while an impartial judge declares the vote void.