Optimizing Dreamcast Microsoft Direct3D Performance

[swaaye]

I was wandering around over at the Assembler forum and stumbled on a post with a link to a very fascinating developer article on the title of this thread. It's written by a fellow from Kalisto Entertainment.
http://msdn.microsoft.com/en-us/library/ms834190.aspx

This covers how to write your Direct3D WinCE code to run well on the console. As some know, Dreamcast developers could go down the Windows CE route for their game development if they desired instead of a more to-the-metal approach. Paved the way for the future of easy game porting, I'm sure. Has some cool hardware insight and lots of other stuff too.

Retro bliss?

 

[archie4oz]

I'd prefer Kamui over DirectX thank you very much...

 

[swaaye]

Well I know that this isn't exactly the hip console news of the minute, but c'mon how bout at least some nostalgic giddy chatter?!

 

[Iron Tiger]

I remember being impressed by the fluidity of Kalisto's Powerslide on my Voodoo Rush. The game was bundled with a few PowerVR cards as a showcase title for that API/platform, but seeing how well it ran on my underpowered 3Dfx had me convinced that they were fairly competent developers. I'd like to know where all that talent is working today.

 

[Akumajou]

Well I know that this isn't exactly the hip console news of the minute, but c'mon how bout at least some nostalgic giddy chatter?!

You mean about how Saturn got its plug pulled prematurely by two years, how Japanese 3rd parties felt targetted by Bernie Stolar's RPG comments, how Tom Kalinske was unfairly made to leave SEGA, as well as Hayao Nakayama and others... oh wait I almost don't want to remember that the console lacked a DVD drive so as to have feature parity when the XBox 1 showed up. rollseyes...

But year sorry if I ranted too much but as a SEGA fan the idea of Microsoft wanting to work together to "help" make the console easier to develop for and therefore "help" erase the memory of the Saturn as well as by simplifying the console design (ie one SH4 instead of two) sure brings back memories.

 

[Simon F]

Well I know that this isn't exactly the hip console news of the minute, but c'mon how bout at least some nostalgic giddy chatter?!

It was interesting to see the VQ compression rate described more accurately than most I've seen on the net.

 

[swaaye]

oh wait I almost don't want to remember that the console lacked a DVD drive so as to have feature parity when the XBox 1 showed up. rollseyes...

In 1998, DVD drives were still very expensive. PC DVD-ROMs were around $200, if I remember correctly. Paying over $200 for a set top DVD player was also commonplace. No doubt it would've been great for the machine to have a DVD drive though. I do wonder if an SH4 @ 200 MHz has the grunt to play a DVD movie however. On PCs you needed a Pentium II 400 to really do it well.

But year sorry if I ranted too much but as a SEGA fan the idea of Microsoft wanting to work together to "help" make the console easier to develop for and therefore "help" erase the memory of the Saturn as well as by simplifying the console design (ie one SH4 instead of two) sure brings back memories.

Dreamcast fit well with WinCE. The SH3/4 chips were showing up in loads of PDAs which ran WinCE. So for Sega to say that their console was compatible with CE was probably an attempt to make it look like more than a game machine. WinCE development also made it pretty easy to port Windows games to it. Porting is all the rage today so I don't think it was a bad call back then.

I've been wondering if the VGA cable existed to allow the DC to be a sort of PC if WinCE went anywhere on it. Think of something like a Web/Email box akin to WebTV.

I'm also not sure how adding a second CPU would've necessarilly been a good call. Consider that multiprocessing for gaming is still a touch and go today. It would add a lot of complexity, cost, and maybe add nothing of value to the system. I wouldn't say that Saturn was any sort of proof of concept for it, and I think they wanted to simplify the whole console architecture. The simplification of the architecture compared to the Saturn smorgasbord mess, combined with the option for developers to use Windows development tools, makes it plainly obvious that Sega was trying to attract developers with a new easy-to-program-for image.

If any hardware changes were to be made, I think that they would've been much better off getting more clock speed from the CPU or adding more RAM. But honestly I think that Dreamcast was excellent hardware for 1998. It's efficient. It's dramatically -shockingly- better than the 2-3 year older N64. It's much less of a mess than Saturn / 32X. The goal of the design seems to have been to make it developer friendly instead of some sort of elitist programming competition.

I want to say that Sega should have brought Dreamcast out later. Maybe after PS2 and with superior hardware. PS2 was just such a phenomenon that crushed Dreamcast. It's really tough to tell. They needed more money, more hype, more excitement. Sony blew them out of the water. I think the same thing basically happened to Cube vs. the behemoths. Maybe Nintendo and Sega could've worked together on a single console effort to go up against these absolutely huge companies. Companies that can spend nearly endlessly to accomplish their goal of owning the living room.

 

[Simon F]

In 1998, DVD drives were still very expensive. PC DVD-ROMs were around $200, if I remember correctly. Paying over $200 for a set top DVD player was also commonplace. No doubt it would've been great for the machine to have a DVD drive though. I do wonder if an SH4 @ 200 MHz has the grunt to play a DVD movie however. On PCs you needed a Pentium II 400 to really do it well.

On a PC, the CPU would have been doing the colour space conversion which, on DC, would be done in CLX so it's possible that with the reduced load the SH4 might have been up to the job.

 

[swaaye]

One thing a DVD-ROM would have done is curb piracy. Make the thing only read DVDs and it would've been rather pirate safe for years. DVD burners were very expensive until like 2003 or so. The Dreamcast as it is is probably the easiest console pirate target ever thanks to it supporting that Mil-CD spec that lets it boot CD-Rs. Talk about shooting yourself in the foot, allowing it to be super easy to bypass the fancy custom GD-ROM.

But with the cost of DVD hardware in 1998, I think making it a DVD system would've been way too costly. Dreamcast launched at $200 apparently and that would never have happened if it went DVD. It would have almost been similar to the PS3+Bluray price debacle.

Of course, just what did it cost in the end to develop that special GD-ROM format? It's not like they went with plain 'ol CD-ROM instead of DVD. So there were already some extra media costs involved but it's still using basically using CD-ROM hardware. Apparently some CD-ROM drives can read the GD-ROM disks after some modifications.

 

[Scali]

On a PC, the CPU would have been doing the colour space conversion

Is that so?
I recall even on ancient Matrox Mystique/Millennium cards, you already had support for YUY2 overlays (or whatever the exact format was) with bilinear-filtered scaling, all hardware-accelerated.
I used it back in the day to play CD-Video/CD-i stuff on a Pentium 133 in 1024x768.

On another note, I still have my DreamCast somewhere... I thought it was actually a pretty good console at the time. Soul Calibur had great graphics, and very smooth framerates. I really liked the PowerVR chip, and also bought a PowerVR card for my PC (which turned out to suck because it didn't work well with D3D and OpenGL, and the native API was underused).

 

[Simon F]

Is that so?
I recall even on ancient Matrox Mystique/Millennium cards, you already had support for YUY2 overlays (or whatever the exact format was) with bilinear-filtered scaling, all hardware-accelerated.
I used it back in the day to play CD-Video/CD-i stuff on a Pentium 133 in 1024x768.

I would think those would have been close to "top of the line" graphics cards and I doubt all would have provided that sort of of support...but this is just what I recall so take with the usual NaCl.

 

[Scali]

I would think those would have been close to "top of the line" graphics cards and I doubt all would have provided that sort of of support...but this is just what I recall so take with the usual NaCl.

The Matrox Mystique was a relatively cheap card, one of the first Matrox cards aimed at the mainstream/gamer market, introduced in 1996 (so it predates DVD).
I know its acceleration made my videos look much better (bilinear filtering during upscaling was just not possible with a Pentium-class CPU in those days, so scaled videos were always blocky) than software solutions, AND they ran faster (as in, I could use high resolutions without a problem, rather than being stuck at 640x480). Matrox supplied a program called SoftPEG on the driver CD, which made use of the hardware acceleration features when playing MPEG and related formats.

I know ATi had similar features at around the same time, and I also know that ATi was one of the first to add some iDCT acceleration features to their hardware at a very early age (Rage 128 chip).
So as far as I recall, various parts of DVD decoding could be decoded on consumer cards at a very early stage on PCs (around 1996/1997).

 

[Mat3]

Under the Improving performance section, it talks about three tests to cull the triangles backfacing, off the screen, and hidden by other objects. These tests are post transform, no? Why would the game engine have to do them? Didn't the Powervr chip automatically deal with them? I would assume backfacing and off-the-screen triangles wouldn't even be stored in the display list, and overdraw of course wouldn't be a concern...

 

[swaaye]

Back in even '97, you could find PC vid cards with considerable DVD hardware assist in the form of motion compensation hardware. ATI Rage Pro was the first chip that did it, I believe. Almost everything from ATI after that did at least that level of processing. Hardware mocomp is only partial hardware acceleration of MPEG2 though. The other GPU companies followed suit shortly after ATI. Later they all added idct computation hardware too.

Hardware overlay w/ color space conversion and video scaling support showed up around '95, I think it was... I remember I had a S3 Vision 968-based VLB board that did it. Virge and some of the Trio64 line could do it too, I believe. This was before DVDs were practical so MPEG2 was really rare yet. Those were the MPEG1 and VCD years.

Earlier, when I said that you needed a Pentium II 400 to do DVD decoding, I meant with a video card that did basically nothing to assist. I am having a tough time remembering exactly how well slower processors managed. I do know that a hardware decoder card was the way to go for slower systems if you wanted to be sure of no frame skipping.

 

[swaaye]

Under the Improving performance section, it talks about three tests to cull the triangles backfacing, off the screen, and hidden by other objects. These tests are post transform, no? Why would the game engine have to do them? Didn't the Powervr chip automatically deal with them? I would assume backfacing and off-the-screen triangles wouldn't even be stored in the display list, and overdraw of course wouldn't be a concern...

One thing I've been wondering is whether fog/smoke effects have a larger impact on this architecture than regular rasterizers.

I recently bought myself a Dreamcast so have been checking out many of the games. I noticed that in SFRush 2049 the poofs of smoke from the car tires noticeably impact framerate. Normally the game runs very smooth, but the smoke hits it hard. And then in Tomb Raider Last Revelation, I noticed that fog could seriously drag the system down. Of course, this could be down to inefficient coding or some such too. The Tomb Raider games are WinCE titles so they could just be sloppy ports.

 

[Simon F]

The Matrox Mystique was a relatively cheap card, one of the first Matrox cards aimed at the mainstream/gamer market, introduced in 1996 (so it predates DVD).
I know its acceleration made my videos look much better (bilinear filtering during upscaling was just not possible with a Pentium-class CPU in those days, so scaled videos were always blocky) .

AND

Back in even '97, you could find PC vid cards with considerable DVD hardware assist in the form of motion compensation hardware. ATI Rage Pro was the first chip that did it, I believe. Almost everything from ATI after that did at least that level of processing. Hardware mocomp is only partial hardware acceleration of MPEG2 though. The other GPU companies followed suit shortly after ATI. Later they all added idct computation hardware too.

Hardware overlay w/ color space conversion and video scaling support showed up around '95, I think it was... I remember I had a S3 Vision 968-based VLB board that did it. Virge and some of the Trio64 line could do it too, I believe. This was before DVDs were practical so MPEG2 was really rare yet. Those were the MPEG1 and VCD years.

Earlier, when I said that you needed a Pentium II 400 to do DVD decoding, I meant with a video card that did basically nothing to assist. I am having a tough time remembering exactly how well slower processors managed. I do know that a hardware decoder card was the way to go for slower systems if you wanted to be sure of no frame skipping.

I should have checked the dates rather than rely on my increasingly dodgy memory.

Under the Improving performance section, it talks about three tests to cull the triangles backfacing, off the screen, and hidden by other objects. These tests are post transform, no? Why would the game engine have to do them? Didn't the Powervr chip automatically deal with them? I would assume backfacing and off-the-screen triangles wouldn't even be stored in the display list, and overdraw of course wouldn't be a concern...

CLX2 certainly did backface culling and offscreen rejection of triangles and, as you said, that would be post-transform.
Because the SH4 has to do the T&L, maybe the author is alluding to doing *some* of that on groups of triangles or whole objects to save CPU cycles as well.

One thing I've been wondering is whether fog/smoke effects have a larger impact on this architecture than regular rasterizers.

It should actually be less - transparency effects etc were always handled last (there were separate lists for different classes of polygons) so any obscured areas should be cheap and, being a tile based renderer, it would save a lot of bandwidth by avoiding numerous read-modify-writes.

And then in Tomb Raider Last Revelation, I noticed that fog could seriously drag the system down.

So they were using transparent polys for the fog? I've not seen the game so can only go on images on the net. I didn't search too long but if this

is the sort of fog, I don't understand why it could not be done with one of the "free" fog methods <shrug>

[EDIT] Ahh. I guess it's these sort of effects: http://image.com.com/gamespot/images/screenshots/8/199048/tomb4_screen012.jpg

 

[Scali]

I should have checked the dates rather than rely on my increasingly dodgy memory.

No problem... I guess the Matrox and its video playback abilities just made a lasting impact on me
You are right though... *if* the videocard can't handle colourspace conversion and scaling, things will get very bandwidth/compute-heavy on the CPU.

CLX2 certainly did backface culling and offscreen rejection of triangles and, as you said, that would be post-transform.
Because the SH4 has to do the T&L, maybe the author is alluding to doing *some* of that on groups of triangles or whole objects to save CPU cycles as well.

Yea, from what I understood, he was talking about having a planar strip or fan of triangles, and culling the whole group with just a single test. I suppose the aim is to keep the actual number of triangles processed by the D3D driver as low as possible.

It should actually be less - transparency effects etc were always handled last (there were separate lists for different classes of polygons) so any obscured areas should be cheap and, being a tile based renderer, it would save a lot of bandwidth by avoiding numerous read-modify-writes.

Wasn't the advantage also that the read-modify-write could be done within the local cache of a tile? I recall that PowerVR chips had great alphablending performance because the fillrate in tile cache was so high. Also, they did 32-bit alphablending at virtually no extra cost, giving better image quality.

Then again, it's tough to put such an early 3d accelerator in the proper perspective. I recall that fog/smoke effects were always quite troublesome on any chip, because fillrate was just way lower than what we are used to today.

 

[grandmaster]

Fog/smoke effects still give today's consoles a lot of problems!

 

[swaaye]

So they were using transparent polys for the fog? I've not seen the game so can only go on images on the net. I didn't search too long but if this is the sort of fog, I don't understand why it could not be done with one of the "free" fog methods <shrug>

I've been thinking more about it and I actually think it may not be fog related after all. There's an open area early in the game that stutters badly. It actually reminds me of HDD swapping in PC games. I wonder if they were doing something dumb that was causing some sort of nasty internal memory swapping issue? I don't think it's CD swapping.. There happens to be fog in the area, but it occurred to me that there are more areas with fog and they don't stutter.

If I happen to load that prime-example-of-poor-controls-and-camera-in-a-game back up, I'll pay more attention. If there's one thing that I am reminded of when I play late '90s 3D games it's that we've come a LONG way with regards to 3rd person cameras.

 

[Endymion]

I think this is an incredibly interesting topic!

One thing a DVD-ROM would have done is curb piracy. The Dreamcast as it is is probably the easiest console pirate target ever thanks to it supporting that Mil-CD spec that lets it boot CD-Rs. Talk about shooting yourself in the foot, allowing it to be super easy to bypass the fancy custom GD-ROM.

Just fyi, but Mil-CD allows the Dreamcast to boot exactly that--Mil-CDs. There isn't anything about this that allowed the system to boot CD-Rs. The Mil-CD compatibility was removed from the late manufactured line, and those Dreamcasts can no longer boot Mil-CD format, but it just so happened this was how a lot of pirates had assembled their rips! The result here was not that the newer Dreamcasts could not boot CD-R, they could, they just could not boot the image in the way that it was made, and all-or-most of the guys who did the rips in the past did not want to redo their work. (Because damn those serial cables are slow.) So any Dreamcast can definitely boot CD-R, they just have to be made properly.

But back to the article/OP--I wasn't aware that Windows CE allowed programming closer to the metal! I haven't digested the link yet, but in fact, almost everything I ever read about WinCE on the Dreamcast had tell of terrible performance, which resulted in many developers not using it? Was this not the case? I've got a couple hundred Dreamcasts and while I do know several are WinCE titles, it is fairly uncommon, the one place I see it consistently is on the front of the Dreamcast.