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."
Wine? (Score:5, Interesting)
I haven't read TFA yet
but wouldn't this have been a prime use-case for Wine on Windows?
Re:Wine? (Score:2, Interesting)
Re:Wine? (Score:4, Interesting)
"Funny you should mention that..." I blew this morning trying to get some old PS2 hacking apps running on Wine. In the end I just installed w98 on a spare box. Wine is classic YMMV. It's a good, worthy project, but man, you just can't _count_ that's it's going to deal with even small old VB6 apps ahead of time. Use restraint for recommending it unless you've done exactly what's being discussed.
Re:Or you could (Score:4, Interesting)
See for example DOSBox: it lets you run old games with near-perfect results, and running them in DOSBox is much, much, much easier than getting them to work on a real DOS machine was, back in the days.
Re:I wonder about this (Score:5, Interesting)
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 [hulver.com] 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.
Funny that (eggy post follows) (Score:2, Interesting)
Minecraft is the most fun I've had in a computer game for years, and practically everyone I have shown it to has downloaded it and become obsessed - yet the graphics are kind of shit - but even then, it requires a reasonably modern computer to run quickly (drawing millions of cubes is quite time consuming, I guess - does anyone know how he draws everything so efficiently? Does MC only render blocks that are unoccluded? If so, how does it figure that out? I'm really intrigued by the tech behind MC). I wonder if the game would be more fun if it had better graphics? I kinda think it would.
Re:I wonder about this (Score:1, Interesting)
Re:heads up for combat soldiers' family and friend (Score:3, Interesting)
Heads up for combat soldiers family and friends, get a grip. Stress is one thing, wigging out is another and helps no one.
Plenty of combat soldiers/Marines/airmen game in-theater! Deployments have loooooong, boring stretches and gaming is a popular distraction.
Re:I wonder about this (Score:3, Interesting)
5 slaves, each rendering 1920x4800. Each machine is a single E5530; 2xFX1800; 4GB memory. Luckily, I have a totally excellent colleague who helps me with the networking/file server config (when he can find the time).
We find it much better to compress the data prior to network transmission and perform a parallel decompress on arrival to the clients. Not exactly rocket science.
Thanks man.
Re:Who says DirectDraw is going away? (Score:5, Interesting)
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.
Re:I wonder about this (Score:3, Interesting)
I kludged up some code a while back to create a shim dll [hulver.com] that can be used as the basis for selectively replacing functions in dlls...
A slightly more sophisticated solution would've been Detours [microsoft.com].
Or, if you didn't feel like coding, WinAPIOverride32 [potier.free.fr].
Re:Or you could (Score:3, Interesting)
For what it's worth, I have Q3 Arena running on XP in a VirtualBox VM, under 64-bit Fedora. It's all running on an Acer 5536 laptop with 4Gb ram and an ATI 3200 video chipset. It's not state of the art, not high-end, and it still runs fast and smoothly - far more so than the original hardware which introduced me to this game. I appreciate the merit of your comment, but draw your attention to Moore's Law.
Re:Oh stop (Score:4, Interesting)
Also I don't like this elitist "purist" thing that people pretend to of "Oh I don't even like the graphics, I just want good gameplay." Guess what? The graphics and sound can well be a part of that. When games are visually appealing it can add to the immersivness. It is easier to lose yourself in a convincing world.
I agree with this completely. I've recently been playing a fair amount of STALKER -Shadow of Chernobyl, and -Clear Sky lately.
The realism of the gameplay is partly due to realism in graphics and sound. Although at the same time, the world you are in is so open, and you are free to explore as you want/need to.
You are, after all, in a real place that actually exists. If you've seen pictures of the area around Chernobyl since the accident, then you'll recognize a lot of places as you play through the game. You'll be walking around, stop to chat to someone, hear a dog bark in the distance, a crack of thunder and it will start raining...then a radioactive mutant will be trying to rip your head off.
Many FPS games guide - or force - you to the next objective, so you don't have the opportunity to look around, find interesting places, and interact with many different characters in the game world.
This game is completely different. You can spend days walking, exploring, collecting goodies, not do a single mission, and it doesn't leave you thinking "I've not progressed any in this game."
I guess what I'm getting at is, good graphics and sound can certainly enhance a good game. But at the same time, no matter how good the graphics are, a crappy game is still going to be crappy.
Re:heads up for combat soldiers' family and friend (Score:1, Interesting)
... yet for some, it still continues today. You never get over seeing that much tea, man.
I know, I was there and it haunts me every day.
Re:Wine? (Score:4, Interesting)
For a lot of API calls, you could probably build some automated tool that analyses running programs on windows, recording calls in/out of programs/apps, their arguments, results, and what ideal results would be/are. From that, testing against wine builds would be fairly straight forward.
Re:Wine? (Score:3, Interesting)
When I switched to linux in 2000, I kept win 95 around so I could play wingcommander. By the time it was 2006, it became increasingly more difficult to run them on the latest windows version. A rerelease of the old games luckily allowed playing on Win XP. However, that meant I had to download a hacked version with a virus, no, I don't intend to rebuy things I bought before (my windows version was probably also illegal, I did not connect to the net so I did not care).
Finally, by 2008, all ran great in wine.
People who like old games run emulators all the time, so it is normal to use dosbox for wingcommander 1/2, and a win 95 reimplementation for wingcommander 3/4. To suggest otherwise means _you_ are the idiot.
Re:Funny that (eggy post follows) (Score:3, Interesting)
i'm not familiar with the ac's mentioned game, minecraft - but to expand on what you say, yes, for starters back-face culling [wikipedia.org] is really cheap/quick for testing whether to send polys to the render pipeline - it's done after the final transform, and involves no additional maths beyond a compare of polygon vertex index numbers (ie, you use clockwise indexed polys for front-facing, if when you come to render a poly, vert[0] has an index number higher than vert[1], you skip sending the poly to the render pipe)
like i say, i don't know minecraft, but if it's cube-based then you'll be can culling quads instead of tris which saves half the work again. you can probably take that a step further if they're always cubes, because you know that only 3 faces of a cube can be visible at any time.
furthermore, if the game is based around a 2d or 3d matrix/grid of cubes, then it is only a small amount of maths to project the view frustrum [wikipedia.org] over that space, because you're not really dealing with polygon-soup per se, as with more graphically complex games, you're merely dealing with a low-res coarse array of cells (which will eventually be rendered as your simple cube meshes) -- and if the cubes are 'fixed' in orientation to the grid then you can skip the transform for the model rotation, because it's simply not needed if all the cubes are guaranteed to be at angle (0,0,0) in relation to the world.
also, if you're dealing with a strictly grid-based scene, with regular / fixed size cube models, then model/scenery occlusion is also a bit easier to deal with - because it's a regular grid of cubes you can make assumptions about visibility and take shortcuts that you can't do so simply when dealing with a scene that has arbitrary mesh shapes/sizes. (although i'm not sure whether occlusion of this kind is where the biggest work savings would be made in the pipeline? it might be feasible to just skip object occlusion after you've made the above performance tricks, depending on various factors - polys are often cheap to render (with a gpu), whereas the occlusion calculations might take extra time for no real gain - it depends where the bottleneck is in the pipeline after the above optimisations)
strictly speaking, if it's a big 3d array of cubes it's basically a big voxel [wikipedia.org]-based system, so all of those techniques are applicable - although, traditionally, voxel-based renderers use fuzzy-pixel-blobs (or apply a smoothing filter or somesuch, either at render time or to the resultant mesh before render time, depending on the effect required), whereas it sounds like minecraft could be treating the world as a more crisply rendered voxel mesh of cubes.
like i say, i've not seen minecraft (and perhaps i should really have a quick google ^^) so i don't know if it's using voxels or polys and points, or something in between / a combination of both (perhaps a world-grid handled as a giant voxel, with the other meshes then thrown into the resultant scene)... and/but maybe i couldn't tell by looking anyhow :) -- but... if i were going to implement something like the ac describes / hints at: that's how i'd go about it! :)
back in the day a lot of the great games on under-powered hardware (2d or 3d) relied on tricks like this (and/or other tricks depending on the game-engine style) to get that more-going-on-than-there-really-is kind of illusion - it still goes on now with newer games-engine tech, but it was much easier to understand when things were that simple. awesome stuff! :)