Triton’s Crystal Dream restored and preserved for posterity

As I mentioned earlier, I have fixed the Sound Blaster routines for  Crystal Dream by Triton. I have made a video capture of it playing on my 486DX2-80, with Sound Blaster Pro:

In a way it feels like restoring an old piece of art. There were some videos on YouTube already, but they were either captured with Dosbox, which has visual glitches, or on real hardware, but without a Sound Blaster, resulting in relatively poor sound quality. None of them truly did justice to the demo.

Crystal Dream might not be the most well-known demo, but I think it is historically significant. This demo was released before classic PC demos like Future Crew’s Second Reality and Triton’s own sequel, Crystal Dream II. Those demos may have put the PC on the map permanently as a demo platform, but this demo certainly showed the shape of things to come.

Unlike those demos, this one does not require a high-end 386 or 486. It will run fine on a fast 286. It is one of very few PC demos that does not require a 32-bit system. What’s more, it’s one of the first PC demos that can compete with Amiga demos in terms of visuals and sound. It has very smooth 3d, even on a low-end 286 or 386SX, and it has a mod replaying routine that works quite well (Triton also developed FastTracker and FastTracker II, still some of the best tracking programs ever made), with some great music. There have been a few demos with tracker music before, but they generally did not sound that good. Poor mixing quality and badly implemented effects.

This was one of the first, if not THE first mature PC production. And it gave us a glimpse of things to come, both from Triton (FastTracker and Crystal Dream II), and from the PC scene in general.

While I’m at it, I think The Space Pigs might be the unsung heroes of the early PC demo scene. They were among the first to release a demo on PC at all. And The Space Pigs also pioneered various demo effects on PC. They also developed their own tracker and replaying routine, and they managed to implement effects like smooth scrolling and raster bars, even on EGA hardware. The Space Pigs are also credited in the end scroller of Crystal Dream. They have apparently helped Triton with the fast EGA 3D polygon routine.

All in all, early groups like The Space Pigs and Triton showed that PC was not as bad as many sceners thought. With clever hardware trickery, a PC could do a proper demo as well. And pushing the hardware to the limits, making it do things that were thought to be impossible, that is what the demoscene is all about.

Fixing this demo, capturing a video of it and putting it on YouTube is just my way to pay homage to these early PC pioneers, and hopefully to share their work with new generations.

If you have any other demos you would like captured and/or fixed, let me know.

Advertisements
This entry was posted in Oldskool/retro programming, Software development and tagged , , , , , , , , , , , , , , , , , , , , , , . Bookmark the permalink.

16 Responses to Triton’s Crystal Dream restored and preserved for posterity

  1. nickysn says:

    It’s a real pity that modern PCs have so many legacy cruft for compatibility with the original 8088 PC – real mode, gate A20, ISA hardware like the keyboard controller, programmable interrupt timer, floppy controller, which supports ISA DMA; modern graphics cards are surprisingly EGA/VGA compatible, yet we don’t have ISA Sound Blaster support, so we can enjoy old DOS games and demos like this one with full sound. Yes, DOSBox works most of the time, but some games and demos don’t work. For others the CPU power is not enough, for example, I would like to run the original Fast Tracker 2 using the high quality mixer or Impulse Tracker 2 with resonant filters (which requires MMX and is not supported at all) and the CPU emulation speed is simply not there yet…

    • Scali says:

      Yea, I know what you mean…
      On the one hand, there’s too much legacy stuff that we don’t use anymore.
      On the other hand, if you DO want to run legacy software, you find that the support is not adequate to run it.
      I don’t think my Core i7 system can even boot an OS like DOS or Windows 9x anymore. For Win9x there won’t be drivers for my hardware anyway.
      And I haven’t looked at SB support in ages, but I’ll take your word for it that it has disappeared. I have used PCI systems that were still SB-compatible though. Either with an onboard chip, or with an SB Live! PCI or such. But no idea if they’d still work in a present-day computer. Detecting hardware like an SB requires reasonably accurate timing. That’s where Crystal Dream went wrong, and a lot of other software will probably fall into the same trap.

      Something like Dosbox would be a nice solution… but I guess Dosbox is written with a typical PC mentality. It ‘sorta’ works, but the emulation is far from accurate. Emulators for other systems, such as Atari ST, C64 and Amiga, are cycle-accurate, and emulate all the quirks of the hardware. Nearly all software works flawlessly.
      Making a cycle-accurate PC emulator is a problem, since the hardware is so diverse. But it wouldn’t hurt if you could at least set it to a certain ‘ballpark’ speed. I’ve tried a few other PC emulators, one of which could be set to emulate an exact CPU at an exact clockspeed. Sadly it was quite buggy, so not a lot of software ran on it.

      And yea, Dosbox should implement the entire instructionset, including MMX (and perhaps SSE), since that is still relevant for DOS/Win9x.
      They should also implement a JIT, like WinUAE does for example, so you can emulate a very fast system. Or perhaps even use the x86 virtualization features (and then have some kind of artificial speed setting, so you can still make the virtual machine emulate at the speed you want).

      • Klimax says:

        AFAIK Windows XP had SoundBlaster 16 emulation. I don’t think it survived into W7. (Maybe XP mode however has it)
        Anyway emulation sort of worked, but it was hit or miss and drivers for soundcard could also break it. (IIRC – ages since I tried it – back in Pentium 4 days)

      • Scali says:

        Yes, you’re right, there was at least some kind of SB emulation in XP’s command prompt. I’m not sure what happened to that in 32-bit Vista/Win7, but for 64-bit Vista/Win7 it’s gone. They lack the 16-bit NTVDM altogether, and as such they cannot run DOS binaries anyway.
        It should still work in XP mode, since that’s just a complete installation of XP running inside VirtualPC (and it can also run 16-bit DOS/Windows apps from a 64-bit host OS).
        There was also an alternative emulator, called VDMSound: http://sourceforge.net/projects/vdmsound/
        It should be more compatible, but it hasn’t been updated since 2007, so no idea if it even works in XP/Vista/Win7 at all. And it would require a 32-bit OS, which we don’t want to run anymore in the first place 😛
        I haven’t used a 32-bit OS as my main OS since 2006 or so.

      • Klimax says:

        (Scali, March 22, 2012 at 10:55 pm)
        VDMSound wasn’t bad. I think it worked well in Windows XP. Never got to test it on Vista or 7, since I by then managed to secure enough old parts to have three old PCs with different speeds. (Pentium 1 188MHz, P1 120MHz and 486 + recent Pentium II)

        Maybe I should try running that demo on mine 486…

      • Scali says:

        Yea, like I always say: DirectX is one of the best things that ever happened to PCs.
        At first, it was reasonably doable… You had VGA, which was (mostly) backward compatible with EGA and CGA… and you had the Sound Blaster, which was backward compatible with Adlib.

        But then there was an explosion of all sorts of SVGA cards, none of them compatible with eachother… And with soundcards as well, quite ridiculous that a monster-card such as a Gravis UltraSound wouldn’t work (or work well… there was SBOS, but it wasn’t ver good) in older games, because they only supported Adlib/SB.

        With DirectX, things just worked, regardless of the hardware you used. And you could make use of all the hardware features as well, which mostly got ignored earlier, because software only catered to the lowest common denominator.
        And hardware no longer had to be compatible with legacy devices at the hardware level.

        I have some of my own code with DirectX from the late 90s, and it still works even today, in Windows 7 x64. Quite a refreshing difference with the DOS age, where hardware support was always flaky, and you never knew what your new computer may or may not run. So I just kept my old computers 🙂 The 486 I used to record this demo is the same basic machine as the one I originally got in the early 90s, and used as a daily machine. The machine that I played Doom on, many classic PC demos, and I think I may have developed some early DirectX stuff on it. But perhaps I already had my Pentium by that time, not sure. It still has a copy of Visual Studio 6 on it anyway, and I have built some DirectX code on it recently 🙂

      • nickysn says:

        Just for fun, I tried booting MS-DOS 7.1 (the DOS from Windows 98) on Core i7 (Sandy Bridge) and it worked just fine 🙂 Only the integrated Intel video card was problematic, I couldn’t get VESA to work, at least with my code. However, I’ve tested modern NVIDIA and AMD video cards and they have perfect VESA 3.0 compatibility (both LFB and banked) and perfect EGA/VGA compatibility, so if you have a discrete NVIDIA or AMD graphics card with your i7, you should have no problems. The only problem is lack of Sound Blaster support, everything else works. 🙂
        Yes, I know there are some PCI sound cards that have Sound Blaster emulation. SB Live and, I think, Ensoniq cards had it. It’s not real hardware support, though, like the ISA sound cards had, but an emulation through a driver, that runs in protected mode (virtual 8086 mode to be more specific, which is a submode of protected mode) and virtualizes the i/o port instructions. That’s why it requires emm386.exe to run. I think this should be sufficient for Fast Tracker 2 and Impulse Tracker to run – both of them are compatible with emm386.exe. Unfortunately, I don’t have such a sound card, maybe I should buy one from eBay 🙂

        As for XP’s Sound Blaster support, I’ve tried it and honestly couldn’t find any program that works with it, it sucks so much 🙂 I don’t know what happened with it in the 32-bit versions of Windows 7, but it doesn’t matter, because they’ve crippled their DOS emulation so much that graphics modes don’t work – they’ve disabled fullscreen DOS mode, only windowed mode works, and windowed doesn’t properly support EGA/VGA graphics – they never implemented it. Previously they would just switch to fullscreen, but now…

        I’ve also tried VDMSound under Windows 2000, but I wasn’t very satisfied with the results, I don’t remember the details, however…

        Long term, I believe, for DOS compatibility, DOSBox is the way to go. It’s not perfect, but it’s IMHO the best DOS emulation available out there now and it’s a pity that its authors don’t care about anything, besides games. I’d like to see LFN support, MMX and an even faster CPU core. And yes, cycle-accurate emulation of a, say, 4.77 MHz 8088 CPU would be nice also, but I could live without that. 🙂

      • Scali says:

        VESA is a horrible standard anyway. Too little, too late. By the time VESA was finally supported reasonably well, with linear framebuffer, Win95 and DirectDraw were already commonplace anyway.
        I never used VESA much, and I’d recommend DirectDraw to anyone wanting to use truecolour/lfb modes. Such modes require a Pentium at least anyway, for anything decent, and then you should have a system that is plenty powerful for Win98SE, or even better: NT4.0.

        As for FastTracker 2… The proper way to use that is to use a GUS. Just a 486 or early Pentium is plenty powerful for it.
        I wouldn’t waste money on an SB-compatible sound card 😛 SB’s have always sucked anyway. But they were the only option in the early days (since Adlib did not have a DAC at all), which says a lot about the sorry state of the PC platform.

        Dosbox could be okay, but I wish it would be a proper DOS box. As in, running actual MS-DOS. They have their own mini-OS, which is sorta DOS-compatible, but most of the DOS utilities are missing, and I tried using the actual DOS binaries from DOS 6.22 (the last real DOS), but most of them don’t work (apparently there’s some kind of version check in them that fails).
        I would like a real emulator, one that boots any x86 OS that a normal PC would boot. MS-DOS, Windows 9x, OS/2 etc.

  2. nickysn says:

    Back then I made a wrapper around DirectDraw, VESA and X11, so I could target Windows, DOS and Linux with the same code and it worked pretty well 🙂 Sure, I agree that VESA was pretty horrible, but I was merely pointing out the fact that modern NVIDIA and AMD cards still support it excellently and many DOS games and demos would work just fine today, if it wasn’t only for the missing sound support.

    Also true that Microsoft’s backward compatibility has been excellent, however with Vista and 7 even DirectDraw compatibility has started to deteriorate – they’ve broken 256-colour modes and games like Starcraft 1, Fallout 2, etc. look horrible. Sure, there is a workaround, but it shows that Microsoft are beginning not to care about old Windows games also.

    FT2 with GUS actually works the best under DOSBox, because it then uses DOSBox mixing code, instead of mixing in software on the emulated CPU, so it’s much less CPU intensive. But it’s still not ideal, because GUS has a memory limit of 1 MB, so modules with large samples can’t be played properly. Also, sound quality is worse, because of lack of volume ramping and the sound has clicks 🙂

    For Impulse Tracker I use my old 700 MHz Pentium 3 laptop, under Windows 98, thanks to Jeffrey Lim’s ITVSOUND.VXD hack, but for FT2 there’s no such option.

    I’m not planning to waste money on a SB-compatible PCI card – I merely played with the idea 🙂 In fact, I could bring my old 486 DX4-100 which has a SB-compatible ISA sound card back from parents’ house, but I still haven’t done so, because it’d waste too much space in my apartment 🙂

    Actually, DOSBox can boot a disk image with a real OS, for example Windows 95:
    http://vogons.zetafleet.com/viewtopic.php?t=24936

    Pretty sure MS-DOS 6.22 would run too 🙂
    IIRC, the problems are they don’t support LBA, so large disks (>512MB IIRC) are unsupported and newer OSes may not run, possibly because of incomplete CPU core implementation.

    P.S. I even asked on DOSBox’ IRC channel if you could run DOSBox inside the Windows 95 running inside DOSBox and they told me they’ve tried it and it “works” 🙂

    • Scali says:

      Yea, VESA worked okay on *some* cards, *eventually*. Now only nVidia and AMD remain, and I suppose they’re reasonably okay… But back in the day nVidia didn’t even exist yet, and AMD was still ATi, low-end solutions for OEMs.
      Back then you had to contend with Cirrus Logic, Video7, Tseng Labs, WD Paradise, Trident, and Matrox, to name but a few. Most of them had broken or at least spotty VBE support. Which is where SciTech Display Doctor comes into play, with UniVBE… which still didn’t quite work 😛

      I know my Matrox Mystique had VBE, which worked, but was rather useless, as it only enumerated modes of 640×480 and above. No access to the 320x200ish 15/16/24/32-bit modes, which were the ones you REALLY wanted obviously. And no UniVBE support, so boohoo.
      But DirectDraw worked perfectly, so I never looked back.

      And yes, the palette modes are a tad flaky in Vista/Win7… But a bigger issue is that 320×200 modes are no longer supported by drivers. Things that I made with 320×200 8-bit will not work on a modern nVidia or AMD card. My mistake ofcourse, I should have put in fallbacks for other resolutions/colourdepths. But hey, back then 320×200 8-bit was THE videomode. Quite bizarre anyway that it is no longer supported, as there still is VGA support, with mode 0x13.

      As for the GUS… If you need more than 1 MB, you’re doing it wrong 🙂
      Heck, an Amiga usually had 1 MB total memory.
      Once you get close to the 1 MB barrier, the GUS can first convert samples from 16-bit to 8-bit, and then reduce sample rate.
      Which probably still sounds better than software mixing on a crappy Sound Blaster 😛
      Apart from software mixing routines generally not being very high-quality, the Sound Blasters themselves had an absolutely appalling frequency response, and a very noisy synth/amp. Nothing could possibly sound good coming out of that 😛
      A GUS was crystal-clear, true CD quality, no noise.

    • Klimax says:

      Are you suer about Starcraft? I ran it few months back on W7 with nVIdia NVS5100M (NB is Elitebook 8540p) and didn’t see significant problems with palette. I think what it boils down to is how well API was used. My guess (I didn’t use this API, I started already on DX) is improper handling of palettes. (Coders were/are known to take various shortcuts so it wouldn’t be suprising) I’ll dig out older benchmark which uses DD and can be forced to 256 color. And it has included source code. (Not such master like Scali. 😉 )

      I have more problems due to new drivers not implementing some older fixed pipeline functions and capabilities then due to backwards compatibility in Windows. (And later is much easier to fix…)

      (Games like Ranaway or Final Fantasy 7/8 – I think those are due to missing support for alpha blending 8bit texture)

      • Scali says:

        Yea, I’ve seen the palette issues as well.
        If you’ve read my oldskool blogs… The donut I mention here: https://scalibq.wordpress.com/2011/12/13/just-keeping-it-real-part-4/
        The DirectDraw version doesn’t work on my nVidia and AMD systems anymore (doesn’t have 320×200 mode as I said), but it does work on my laptop with an Intel IGP. And it has that same issue that Windows steals back some colours from the palette after a while.

        Apparently there are some compatibility settings in the registry that can fix that. It seems to be Explorer that modifies the system palette (killing Explorer should also fix the issue).

        The thing is though… I’m not even sure if this is a bug or anything. I’d have to dive into the small print of the documentation. It may well be that this behaviour is well-documented, and that your application needs to handle some palette-change message and just restore the palette periodically. But since XP and earlier versions of Windows never changed your palette in the first place, most software sets the palette only once, so it won’t recover from corruption.
        The fact that there is a compatibility option built into Windows to control this behaviour seems to indicate that it is not just a bug. It looks like Windows just does what it should be doing, and the compatibility option is there as a workaround for applications that don’t play nice.

      • Klimax says:

        Just ran on GTX 560 VideoDD with 640x480x8 and 640x640x16 and as far as I could tell there were no differencies between runs. Either it would have to run much longer (will take a look at it) or There is more to this then Windows 7 x64… Maybe specific palettes are bad for some reason. (I read somewhere that code often assumed some things, which were true by only for current OS. I think Raymond Chen wrote about it – http://blogs.msdn.com/b/oldnewthing/ and bonus chapters http://blogs.msdn.com/b/oldnewthing/archive/2007/02/06/1612200.aspx)

        Link:
        http://homepage.virgin.net/roy.longbottom/index.htm#anchorGraphics (VideoDD1.zip DirectDraw PC Benchmark)

        As for Starcraft: Played it last time for fifteen minutes and didn’t notice anything nor friend saw nor mentioned. (Netbook with AFAIK ION) So quite strange reports. I remember it crashed on me once due to bug in drivers. (After longer playing)
        Although I might have already set compatibility mode. (Currently it is moved of HDD so I could have third partition for W8 – can’t to check compatibility settings)

      • Scali says:

        Yea, exactly. Windows is incredibly backward-compatible. The problems are often caused by developers making assumptions that only work on their machines, even though the documentation indicates otherwise.
        A common problem with DirectDraw is the so-called pitch-bug: Developers mistakenly assume that the pixels in memory are packed back-to-back, so the length of a scanline in bytes is (width*(size of 1 pixel in bytes)).
        This is true on some cards/in some videomodes, but not necessarily. For more efficient addressing, there is often some padding at the end of each scanline, so the next scanline starts on some kind of aligned boundary. The length of a scanline including padding is known as the ‘pitch’. DirectDraw gives you this pitch, but many developers ignore it… it works on their hardware, and they never bothered to read the documentation to see why that pitch-value is there.

        Likewise a lot of Win9x software doesn’t work on modern Windows because the developers did not specify the correct parameters for API functions, did not return the proper return values etc. These were well-documented, but Win9x has a very lightweight implementation of the Win32API, which ignores various parameters because it does not implement the functionality.
        It’s always surprised me just how buggy people can make software. Don’t they bother to test? I’ve moved to NT4.0 at an early stage, so even my code from the mid-90s was well-tested on NT-based Windows. As a result, pretty much everything still works today (this 320×200 and palette issue is the only thing I’ve run into really, and I will fully admit that it is my fault that I assume a certain resolution to be supported, rather than enumerating the resolutions, picking the closest match, and possibly doing a conversion/upscale).

        I like to support a wide range of systems, if at all possible. With my current 3D rendering stuff I support D3D11, but I have integrated the D3D11 renderer with my older D3D9 one. As a result, the engine still supports Windows XP as well, and probably also Windows 98/ME/2k, although I’ve never tested it on those. And I have never removed the fixed function code from my D3D9 engine either, so I can still create fixed function materials, and run my code on pre-shader hardware. I have tested my code just recently, on my old laptop with a DX7-class Radeon IGP340M (integrated variation of Radeon 7000 series… the original 7000 series that is, not the new HD one obviously). It still works just fine, and the performance actually is not all that bad either, close to a DX10-class Intel IGP.

  3. nickysn says:

    @Scali: Yep, I know the horrors of VESA, I’ve suffered from several “flavours” of Trident 🙂 The latest one of them is on my P3 laptop, that I mentioned I use for running Impulse Tracker under Windows 98. It has a VESA bug that causes low res hi-color modes like 320×200, 400×300, 512×384 to appear only every second time you call some VESA function. In other words, you call the vesa init function that returns you a mode list and they are included in the list. You call it a second time and now they are not. When you call it a third time, they are listed as supported again and so on. And the same thing happens when you try to set one of these modes. Every second time it fails and returns an error 🙂 And yes, on the same card these modes work perfectly fine (i.e. every time) with DirectDraw under Windows 98.

    As for the GUS, I’ve never owned a real one, the only one I’ve tried is the one emulated by DOSBox, so I’ll take your word on the sound quality. 🙂

    @Klimax: I’m pretty sure about Starcraft and I’m not the only one having problems: http://forums.battle.net/thread.html?topicId=16904207716&sid=3000
    Here’s the workaround that worked for me:
    http://www.neowin.net/forum/topic/927140-win7-fixing-old-256-color-games-with-distorted-palettes/

    • Scali says:

      Well, the problem with the Dosbox emulated GUS is that it’s just software mixing, so it’s probably no better than letting the tracker do the mixing itself (perhaps even worse, the emulation might be buggy). A real GUS has hardware mixing. It’s pretty much custom-made for tracker music, it’s like the Amiga’s Paula chip on steroids.

      Aside from that, as I said, the quality of Sound Blasters has been appalling. Even some of the latest ISA ones such as the AWE32 were just absolutely horrible, and wouldn’t deserve the name ‘hifi’ (and to think the AWE32 was actually more expensive than a GUS). Various clones actually had better sound quality, using better quality DACs and op-amps.
      The SB Live! 5.1 PCI card I had was my first decent-sounding SB card.

      The GUS is legendary, and rightly so. There was nothing remotely like it when it arrived on the market, and there has not been anything like it since. If you want to track on a PC, you just need two things: FT2 and a GUS.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s