Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Classic Games (Games) Graphics Software Windows Games

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."
This discussion has been archived. No new comments can be posted.

Breathing New Life Into Old DirectDraw Games

Comments Filter:
  • by Dexter Herbivore ( 1322345 ) on Tuesday September 07, 2010 @02:29AM (#33495436) Journal
    and we didn't need gimmicks like motion controllers, photo-realistic graphics and high framerates to enjoy them.
    • by reverendbeer ( 1496637 ) on Tuesday September 07, 2010 @03:15AM (#33495670)

      and we didn't need gimmicks like motion controllers, photo-realistic graphics and high framerates to enjoy them.

      ...consarn it!

    • by Anonymous Coward

      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

      • backside culling. (anything the camera cant see at that moment, does not get drawn) a very basic principle in rendering complex objects (or lots of objects) quickly.
        • Re: (Score:3, Interesting)

          by Frogg ( 27033 )

          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)

          li

    • by LazLong ( 757 ) on Tuesday September 07, 2010 @05:24AM (#33496202)

      and we didn't need gimmicks like motion controllers, photo-realistic graphics and high framerates to enjoy them.

      In my day we didn't have fancy-schmancy graphics. We didn't have graphics all. All we had were alphanumeric characters to manipulate for our games. And that's how it was, and you liked it! Sound? You were lucky if you could get a single-toned beep from your computer. And don't get me started on those fancy motion controllers! All we had was the keyboard. We stabbed ADWS until our fingers bled. And games? We had great games like Lemonade Stand, Tic-Tac-Toe, SpaceWar!, Star Trek, Super Star Trek. And that's how it was, and you liked it! You loved it!

    • by drewhk ( 1744562 )

      Yeah, I just discovered Dwarf Fortress and almost missed a deadline :) That game is insane, still, it is just a bunch of ASCII on your sceen.

    • Oh stop (Score:5, Insightful)

      by Sycraft-fu ( 314770 ) on Tuesday September 07, 2010 @08:37AM (#33496948)

      The "Back in the day things were so much better," stuff gets annoying no matter what it is about and games are no exception. Were there good games back in the day? Sure were. Guess what? There were also bad ones, you just don't remember them as well. This is in part because our memory tends to deliberately filter out bad experience, but mainly because good games you played a ton, bad games got set aside.

      Know what else? There are good games now. The modern graphics and so on have not stopped people form being able to make good games.

      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.

      So stop getting all "Get off my lawn," about games. There are great old games and you can still enjoy them with the help of emulators. However don't hate on new games just because they look better. That is not a bad thing, it is a good thing.

      • Re:Oh stop (Score:4, Interesting)

        by cbiltcliffe ( 186293 ) on Tuesday September 07, 2010 @09:08AM (#33497152) Homepage Journal

        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:Oh SNAP! (Score:3, Insightful)

          You are in with the old crowd here. S.T.A.L.K.E.R. is a few years old, except for Pripyat, and even then the graphics are the most dated part of the game.

          And, yes, gameplay is what really matters. I still break out M.U.L.E. occasionally, and, guess who joins? My hardcore gaming kids, aged 8, 12, and 14.

          Read that again: Game play IS the top priority in a game's longevity.

          M.U.L.E.
          Age of Empires
          Age of Mythology
          DOOM/DOOM2
          Freelancer
          Serious Sam
          Oblivion
          Rainbow Six 3: Raven Shield
          Counter Strike (Half-Life1 AND

    • by cgenman ( 325138 )

      But man did we want them...

    • Re: (Score:3, Insightful)

      ...and we didn't need gimmicks like motion controllers, photo-realistic graphics and high framerates to enjoy them.

      Oh please. Wing Commander was that game you played when you had just dumped a large sum of money into a new computer system and wanted to show it off. VGA graphics, expanded memory, Sound Blaster, megabytes of graphics, multi-media CD-ROM, FMV, etc. That was the one game you always had an optimized boot floppy around for. "Didn't need gimmicks*" my ass, I bet you bought the speech pack for it!

      The games were fun, but let's be realistic, none of the Wing Commander games were intended for modest machines.

  • I've been waiting for this, though not expecting to see it. In my understanding, this'll allow future generations to play at least MechWarrior 2 and Battlezone, which have sadly been destroyed by DirectX patching.
  • Wine? (Score:5, Interesting)

    by Ynot_82 ( 1023749 ) on Tuesday September 07, 2010 @02:30AM (#33495454)

    I haven't read TFA yet
    but wouldn't this have been a prime use-case for Wine on Windows?

    • Re: (Score:2, Interesting)

      by Zixaphir ( 845917 )
      I was going to place a statement in a similar vein. I hope he didn't have to replicate any work that Wine has already been successful in implementing [winehq.org].
    • Re:Wine? (Score:4, Interesting)

      by Anonymous Coward on Tuesday September 07, 2010 @03:10AM (#33495652)

      "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:Wine? (Score:5, Insightful)

        by advocate_one ( 662832 ) on Tuesday September 07, 2010 @03:30AM (#33495736)

        "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.

        what seriously pisses me off with WINE is that something works with one version of it, but breaks in the next... the database is almost useless with regards to being kept up to date and I'm too old for all this hassle now... and there's TOO much emphasis on having the very latest game running on it to the detriment of making sure other games don't become broken by changes made to support the latest and greatest...

        • Re: (Score:2, Insightful)

          by Anonymous Coward

          there's TOO much emphasis on having the very latest game running on it to the detriment of making sure other games don't become broken by changes made to support the latest and greatest...

          You aren't really proposing an alternative though... Automated testing is practically impossible and manual testing is a huge, huge job if it means play testing thousands of games before every release. just saying "don't make mistakes" is not useful.

          • Re:Wine? (Score:5, Insightful)

            by mr_mischief ( 456295 ) on Tuesday September 07, 2010 @05:21AM (#33496188) Journal

            Automated testing of all the applications is pretty much a nonstarter. However, automated regression testing to make sure function calls with the same arguments in the same context don't give different results just because you debugged a different set of arguments or in a different environment are easy to do with a proper test harness. The hard part is mapping the applications to test cases, but that's not impossible, just time consuming and somewhat difficult.

            • Re:Wine? (Score:4, Interesting)

              by CarpetShark ( 865376 ) on Tuesday September 07, 2010 @09:42AM (#33497444)

              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: (Score:3, Insightful)

            by gmthor ( 1150907 )
            The Problem with Wine is, that from the user point of view, it is extremely unstable. It tried it out a couple time with games that had Gold or Silver status. None of them worked with the version I tried.
            I think I would be really worth it, to stop developing more features for a while and add as many regression tests as possible to the project. So that the project gains stability. Since in the end, the real success is always determined by the end user.
          • I don't know....a couple of weeks of programming, followed by six months of game playing sounds like a great job, if you ask me....

            "It's compatibility testing, boss. Honest!"

      • by orasio ( 188021 )

        Use restraint for recommending it unless you've done exactly what's being discussed.

        This is about some guy who put a lot of work into an improved DLL for Wing Commander.
        Even if Wine didn't support his software out of the box, it could have been a better starting point, and the patches he shares would be more useful.

    • Re:Wine? (Score:5, Insightful)

      by bmcage ( 785177 ) on Tuesday September 07, 2010 @04:30AM (#33495988)
      Wingcommander ran great in wine last time I played it in 2008. I suppose windows developers don't follow linux development?
      • Re: (Score:3, Insightful)

        by Urza9814 ( 883915 )

        Have you ever tried to use Wine in Windows? Last time I attempted was a couple years ago, but I remember spending hours trying to get the damn thing to work, only to eventually just give up. Wine is great on Linux, but the processes to get it installed and to use it for Windows could be greatly improved.

    • Re: (Score:3, Informative)

      by TubeSteak ( 669689 )

      http://sol.gfxile.net.nyud.net/ddhack/ [nyud.net]
      Most of the pictures got loaded into the cache

    • That was my first thought, but then I remembered what early DirectDraw actually did. It's basically little more than a bitblt operation, with some very primitive line drawing and image scaling support. Implementing it from scratch would probably take less time than factoring out WINE's DirectDraw DLL. I'm also not sure if WINE actually uses any acceleration for this kind of drawing. It's probably not worth it - it was done entirely on the CPU, back when the CPU was a 486, so doing it in software, even v

      • The real question is why didn't he use DOSBox? He ran Wing Commander 1-4. The first three predate Windows 95, and so use DOS.

        Apparently he had some weird collector's edition which was made up of later Windows ports - it may not have included the original DOS versions.

  • Or you could (Score:3, Insightful)

    by Rosco P. Coltrane ( 209368 ) on Tuesday September 07, 2010 @02:31AM (#33495462)

    use an older version of Windows in a virtual machine.

    • Re: (Score:3, Insightful)

      NOT INSIGHTFUL. virtual machines are NEVER the optimal solution. ddraw.dll has been reimplemented at the lowest level... given that, why would anyone choose to rather use a virtual machine?

      the only appeal of using a virtual machine was to a lazy developer WHO DIDN'T WANT TO DO IT RIGHT.

      thanks story submitter... glad someone out there still understands, and has some pride left.

      • Re:Or you could (Score:5, Insightful)

        by dintech ( 998802 ) on Tuesday September 07, 2010 @03:25AM (#33495716)

        But to run Wing Commander on modern hardware, it doesn't need to be optimal. 80/20 rule dude.

        • You misunderstand the word optimal. It doesn't just mean processing performance capability. Yeah, sure, even if not running most efficiently, a modern processor can easily run Wing Commander. However, running a Virtual Machine in order to accomplish this will entail many more things, WAY more hard drive space being use for one.
          • A virtual machine for old games would only require a tiny fraction of a modern hard drive.

            If you just want to run old games, then a VM is the way to go. If you want a pet programming project then do something like this.

            • Re: (Score:3, Insightful)

              Comment removed based on user account deletion
              • Re: (Score:3, Funny)

                by Anonymous Coward

                Multiple spare boxes are a huge mess. Don't fall to this trap. You may end up on one of those hoarding shows. :(

              • Re: (Score:3, Insightful)

                by CarpetShark ( 865376 )

                older computers are as cheap and plentiful as dirt

                You're kidding me. The effort to get an old computer, set it up, install the crappy old OS from slow floppies/CDs, mess around with limited memory and IRQs and realising at the last minute that you can't just transfer over wireless or USB... it'd be cheap if your time is worth nothing. Otherwise, running a VM (or just about any other method) is probably faster. I'd love another physical amiga, but I know I'd never use it, next to having a copy of UAE.

        • Ya no kidding (Score:4, Informative)

          by Sycraft-fu ( 314770 ) on Tuesday September 07, 2010 @05:00AM (#33496136)

          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.

          • ST: Armada is one that won't run properly in XP.

            1- you have to disable Sound acceleration (otherwise it's all skippy)
            2- Mouse acceleration is somewhat broken (really really slow mouse)
            3- It *WILL* crash to the desktop.

          • There are quite a few games from the 1996-98 (some as late as 2000) period that simply don't work on modern versions of Windows. Quite a few of them are DirectDraw (many are software rendered 3D) or early Direct3D games developed for DirectX 3 or 5 runtimes. Heck, even old 3DFX GLide games don't run right anymore... even with GLide wrappers.

            Ironically, 32 bit Windows versions have remained more compatible with 16 bit Windows games (due to Win16 API and WoW subsystem development freezing) then native Win32.

        • Yes, that will work, but then you still need to install virtual machine software, have a Windows 98 disc (and technically license), and then you'll have to support and possibly troubleshoot a whole other environment.

          Imagine 100 years from now. Someone wants to play Wing Commander in order to experience an early example of the art form we know as "video games". They'll still need to dig up a Windows 98 install disk? That's kind of shitty.

        • by CarpetShark ( 865376 ) on Tuesday September 07, 2010 @09:48AM (#33497494)

          But to run Wing Commander on modern hardware, it doesn't need to be optimal. 80/20 rule dude.

          But does the 80% go to the rear shields, or the front?

      • Re:Or you could (Score:4, Interesting)

        by peppepz ( 1311345 ) on Tuesday September 07, 2010 @03:54AM (#33495840)
        I think it's not a good idea to run software which was not designed to run on the version of the OS you're using. Besides using ddraw.dll, those games might also display funny behaviour which was not uncommon in those pre-NT, pre-UAC days, such as installing VxD device drivers, scribbling the registry and tossing DLLs all over the filesystem. A VM could spare you those worries.

        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.

      • NOT INSIGHTFUL. virtual machines are NEVER the optimal solution.

        What a ridiculous thing to say. If I have spare memory, disk bandwidth, and CPU time, then it costs me nothing to virtualize (well, unless I'm paying for licenses, but that's not the case when I own all the windows licenses I need and everything else I run is at least free if not Free) but it requires effort to develop software. The virtual machines continue to improve and computers continue to become more powerful so the cost indeed decreases over time. Many games work fine in a VM, at full speed, because

      • Re: (Score:3, Interesting)

        by VoidCrow ( 836595 )

        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.

        • I think ioQuake3 [ioquake3.org] might be for you. By all means, keep the VM for other stuff, but there's literally no reason you shouldn't be running ioQ3 natively on your modern system.
      • by bwcbwc ( 601780 )

        Based on the developer blog, he didn't implement ddraw.dll. Just enough calls to get his WC collection working, along with some crazy hacks because he didn't want to do it right. But at least he documents his kludges.

    • I tried that some time ago. Unfortunately it seems that some old games don't test the capabilities of the virtualized graphics "hardware" so much as compare it to some internal list of supported hardware, and thus refuse to run

    • Re:Or you could (Score:5, Insightful)

      by kinema ( 630983 ) on Tuesday September 07, 2010 @03:38AM (#33495784)
      What is learned by simply booting up a VM and loading a game? In the story submission he specifically mentioned "all the fun workarounds" that he had to come up with get everything to work on a modern system. Don't you think doing a cleanroom reimplementing a subsystem like DirectDraw presents a great learning experience?

      No, I wouldn't have done this if you had payed me; I have my own interests and passions. I'm not at all interested in graphics programming or for that matter video games, though, apparently someone is and I think it's great that he saw a problem and decided to attempt to find a solution for it.

      This is what being a geek is all about. Bravo.
  • by Man On Pink Corner ( 1089867 ) on Tuesday September 07, 2010 @02:36AM (#33495498)

    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().

    • by Suiggy ( 1544213 ) on Tuesday September 07, 2010 @03:35AM (#33495766)
      Yes, DirectDraw still exists on Windows 7, ddraw.dll is still there, and the headers are still a part of the Windows SDK and DirectX SDK. The problem is that graphics card vendors no longer care to test that their drivers work properly with DirectDraw, so it's really hit or miss if you get support.
    • by peppepz ( 1311345 ) on Tuesday September 07, 2010 @03:41AM (#33495796)
      But removing IDirectDraw would only break some games from the 90s, while removing CreateWindow (Ex) would kill every single Windows application ever coded.
    • by Xest ( 935314 ) on Tuesday September 07, 2010 @05:11AM (#33496156)

      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: (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 qu

      • by TheRaven64 ( 641858 ) on Tuesday September 07, 2010 @07:10AM (#33496592) Journal

        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.

        • 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.

          By the time I got Simcity 2000 it was a normal Windows game and it didn't ask you anything of the sort. Further, most of the time they only asked this because they were too incompetent to guess, not because guessing wasn't possible. Indeed, Simcity peaked around 3000, although I do play 4, it is crashy on all platforms. Luckily it works on Wine if you tell it there is only one CPU. You need a pretty fast system to not have this compromise performance, though. Simcity 4 is crap at using multiple cores anywa

          • By the time I got Simcity 2000 it was a normal Windows game and it didn't ask you anything of the sort.

            That was released 2 years later, and called "SimCity 2000: Special Edition".

          • by Sigma 7 ( 266129 )

            Further, most of the time they only asked this because they were too incompetent to guess, not because guessing wasn't possible.

            Simcity 2000 could guess that I was using a Trident SVGA card, but couldn't be sure if I was. If I said that it wasn't, it gave a list of other possible video cards. If you then said it was none of these or that you didn't know, it would default to the VESA SVGA standard even if that standard wasn't supported by your video card.

            Also, detecting video cards was probably as difficult as detecting audio cards, especially during a time where there was no "plug and play" standard that made them easily identifia

  • The Kilrathi Saga (Score:3, Informative)

    by black3d ( 1648913 ) on Tuesday September 07, 2010 @02:47AM (#33495552)

    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.

    • this would be "The Kilrathi Saga" versions of the games - almost as valuable as a WoW Vanilla Collector's Edition to WC fans

      Sorry, does that mean they're highly in demand, or completely worthless? The data point you offer in comparison doesn't really mean anything to me.

  • I wonder about this (Score:4, Informative)

    by Sycraft-fu ( 314770 ) on Tuesday September 07, 2010 @02:54AM (#33495582)

    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: (Score:3, Informative)

      by Anonymous Coward

      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.

      • Mod parent up. Installing DX9 is required to make Civilization 4 (and several other games) work on Windows 7. This is apparently due to missing DLLs which are not included with DX11 but are included with DX9. The whole concept of backward compatibility is a joke with DX.

      • by Suiggy ( 1544213 )
        Wrong, the DLLs for the older versions of DirectX are still there on Windows 7, and the headers and libraries are still available in in the Windows SDK. The problem is that graphics card vendors don't test that their drivers work with the older versions of DirectDraw and Direct3D anymore because they just don't care. So you never know if you'll get support or not.
      • by TheThiefMaster ( 992038 ) on Tuesday September 07, 2010 @04:32AM (#33495998)

        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.

    • I can't answer your questions, nor can I read the article yet, but I can say that on Linux I'm doing a very similar thing.

      I'm programming (when I find the time) for a 9600x4800 pixel display and found that 3D graphics on that sort of size is absolute shite using current methods. I am using OpenGL to get the drawing contexts and find that using a glDrawPixel to get around a 100fps. But that is all it is good for. I am reimplementing the 3D point, line drawing myself on the cpu (my interactive datasets are

      • Re: (Score:3, Insightful)

        My bottlenecks are network supply (10Gbps to five clients with dual network ports and jumbo frames not sufficient).

        Well, yes, I'm not entirely surprised your system has trouble pushing tens of gigabits of data whilst reading from a ten TB dataset and live-rendering 3D on a bank of 3 x 3 3200x1600 screens. All this on a side project "when you find the time", too, impressive. To the best of my calculations you'd have what, 7 PCI-E slots?

        • Re: (Score:3, Interesting)

          by kramulous ( 977841 )

          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.

    • by Rogerborg ( 306625 ) on Tuesday September 07, 2010 @04:01AM (#33495884) Homepage

      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.

      • Re: (Score:3, Interesting)

        by xded ( 1046894 )

        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].

    • by Tomun ( 144651 )

      Coral cache link to article http://sol.gfxile.net.nyud.net/ddhack/ [nyud.net]

  • Coral Cache link (Score:2, Informative)

    by Rufus211 ( 221883 )

    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)

    by Anonymous Coward on Tuesday September 07, 2010 @03:34AM (#33495754)

    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

  • While people can say that the old ddraw works fine in Win7, that's all nice and everything. But sometimes we want more then just the old school graphics and gameplay. In this case we can hack the ddraw layer to add extra features like a higher resolution, AA or HQ2x or something like that.

    I tried to do this with Direct3D7 for TheTypingOfTheDead, to run it at higher resolutions, but I failed. Maybe if I use this code as base I have a better shot at it.

  • Were damn fine games I'd love to play again.
    • by PhilHibbs ( 4537 )

      MC1 runs fine under DosBox, I think I needed to install a Glide wrapper. I found all I needed through google, was really easy.

  • I've seen similar problems with Starcraft ('wrong screen color settings' regardless of which is tried) and notice that Starcraft is listed on the site "with sluggishness".

    This is interesting, because I found a work-around purely by happenstance in Windows 7, at least for SC. Leave your video settings as they are and just open the Display Properties dialog. THen start the game: it'll play flawlessly.

    You have to wonder if, indeed, the incompatibility is intentional. I can see no other reason why SC would work

"When the going gets tough, the tough get empirical." -- Jon Carroll

Working...