Breathing New Life Into Old DirectDraw Games 274
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."
WoW!! (Score:1, Informative)
Fastest slashdotting *ever*
Who says DirectDraw is going away? (Score:5, Informative)
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().
Re:WoW!! (Score:3, Informative)
Fastest slashdotting *ever*
Ever since they started giving subscribers early peeks, the weakest sites have been slashdotted before the story hit the front page. Oh well...
The Kilrathi Saga (Score:3, Informative)
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.
I wonder about this (Score:4, Informative)
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.
Re:heads up for combat soldiers' family and friend (Score:3, Informative)
Except the Bosnia war ended in 1995. so your friend could not be in combat zone.
(I know. I was there. I still am.)
Ya well (Score:3, Informative)
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.
Re:I wonder about this (Score:3, Informative)
Windows 7 does NOT support full backwards compatibility for older versions of directX. You can, however, install directX 9 (which then sits alongside directx11) and that fixes up many games. (Finding the correct install package that doesn't just say "Oh, you've got 11, I'll stop" is a chore, though.
This situation isn't going to improve. Running through a virtual machine does work fairly well though.
Coral Cache link (Score:2, Informative)
The server's crashing, but coral cache managed to get the text:
http://sol.gfxile.net.nyud.net/ddhack/ [nyud.net]
Text, I think (Score:5, Informative)
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
Re:Who says DirectDraw is going away? (Score:5, Informative)
Re:Ya well (Score:2, Informative)
FYI: The hostname sol.gfxile.net resolves to 79.98.31.24, which belongs to a Lithuanian hosting company. Technically that doesn't rule out that the server is in a broom closet and talks to the internet via a home DSL line, but it's kinda unlikely.
99% of all Slashdottings are due to overly complex or badly configured content management systems. I.e., the bottleneck is not the uplink but the server. A static web site (which is delivered statically, not through a CMS) with moderately sized files (1-2MB per page) is almost impossible to overload by accident, even in a shared hosting scenario.
Re:Ya well (Score:1, Informative)
or you could submit the link to a caching service instead directly the one of your closet server
Re:I wonder about this (Score:5, Informative)
Not 100% accurate. Windows 7 includes direct-x 9 itself (there's not much to it), but not all the different d3dX9_??.dll extension files. Those are what you have to install.
The DX web setup [microsoft.com] will bring you up to date with all direct-x 9 onwards extension files, regardless of whether you're running XP or 7, x86 or x64, Home or Ultimate (just look at the comprehensive supported OSs list!).
Any older versions of DX are supported, you shouldn't need to install anything for them.
Re:Wine? (Score:3, Informative)
http://sol.gfxile.net.nyud.net/ddhack/ [nyud.net]
Most of the pictures got loaded into the cache
Re:WoW!! (Score:5, Informative)
Here's a coral cache link that works just fine [nyud.net]
Ya no kidding (Score:4, Informative)
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.
Re:heads up for combat soldiers' family and friend (Score:1, Informative)
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.
Re:Wine? (Score:4, Informative)
Re:Who says DirectDraw is going away? (Score:3, Informative)
DirectX isn't as backwards compatible as advertised. A lot of old games don't run well with newer versions of DirectX, in most cases it's just small things that are an annoying and don't result in a real application crash. I've seen games create issues when a new DirectX version came out since the introduction of DirectX 7, a lot of games using 6.4 suddenly had missing sounds, in some cases certain parts of the input handling was broken. And on a rare occasional there were noticeable render artifacts. In quite some cases this could easily be solved by putting the dsound.dll or dinput.dll that came with the DirectX of the game in the directory of the game itself.
Re:Who says DirectDraw is going away? (Score:5, Informative)
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.
DirectX was designed to solve precisely one problem: that game developers wrote games for DOS and didn't regard Windows as a sufficiently capable platform for gaming. In its early iterations, it was a very low-level API. It basically gave you a way of bypassing Windows and talking almost directly to the graphics and sound cards.
Remember that, at the time, graphics cards were very simple devices. A lot were just frame buffers - a blob of memory connected to a DAC that scanned its contents and generated an analogue signal for a monitor. Some supported double buffering (i.e. two frame buffers and a flag to tell the DAC which one to read). They quite often had a BitBlt operation, which would copy a rectangle onto the frame buffer from RAM (across the bus) or from a bit of reserved VRAM, typically with a mask. A very few of them could also do line drawing and scaling of images during the blits.
DirectDraw provided functions that were very thin wrappers around the graphics card's capabilities. It was designed from the start to make porting DOS games to Windows easy. Most DOS game developers had a small library of functions that implemented a few primitive graphics routines like bitblt in software and would use accelerator functions if they were available. You might remember games like SimCity 2000 requiring you to select which graphics card you had. It would use accelerated line drawing and blits if they were available.
DirectDraw just replaced these libraries, providing very thin wrappers around the hardware facilities and emulated versions when they were not present (e.g. using memcpy() for BitBlt). It wasn't designed as a high-level API, and directly exposed things like the palette modes in the hardware. The problem that old games are starting to experience comes from this fact. Modern GPUs don't support palette modes at all, but a lot of old games used them because they took less VRAM and let you do some animation effects. At the time, all cards supported palettes and a few also supported true colour - designing for a card that didn't support palettes seemed pointless.
At the DirectDraw layer, all of this stuff is passed straight down to the driver and on slightly older cards they were then passed directly to the hardware. Companies like nVidia don't always bother properly implementing emulation paths in the driver for old software, so the games stop working.
Re:WoW!! (Score:3, Informative)
Re:Similar problems with Starcraft... (Score:3, Informative)
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 [hopx.net]
You forgot this one... (Score:2, Informative)
Re:There were some damn fine games in that era... (Score:2, Informative)
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.