Comparison of 6th generation game console hardware

Quote:

---

Originally Posted by TmEE

interrupt overhead is massive and the timers are generally used elsewhere like to time video. VBL can only be polled on most setups, it is not wired to an IRQ.

---

The method detailed above uses timers 0 and 2, with the realtime clock being stopped during use of timer 0. (or with the clock driver replaced with one compensating for the new timer rate) Timer 0 is used for the sample rate (for setting each sample), and timer 2 is used to control pulse duration of the PC speaker output. (timer 2 is typically used for PC speaker control in general)

With that method, it does indeed seem like only 1 CPU interrupt is needed per sample, so overhead shouldn't be too much different from CPU playback through a parallel port DAC.

I think there's some later PC speaker sound drivers employing pulse density modulation techinques to allow much better quality output, but at the expense of much greater CPU overhead . . . and only practical on relatively modern CPUs. (like late 90s era stuff at least)
Like this: https://www.youtube.com/watch?v=dV1EMcH316s (seems to have an affinity for Matt Furniss's MD music too ;))

Back to my last question, the following is copied from what I just posted in the Dreamcast Appreciation thread. I would like to develop this table into as accurate an apples to apples comparison of the 6th Generation's hardware GPU capabilities as is possible to document.

GRAPHICS SUBSYSTEM
System LSI	PowerVR2DC "CLX"	Custom ATI/Nintendo "Flipper"	Custom nVidia graphics chip "X Chip", NV2A
Clock Frequency	100Mhz	162MHz	233MHz
Embedded Frame Buffer	8MB 100Mhz SDRAM	Approx. 2MB Sustainable Latency : 6.2ns (1T-SRAM)	64MB UMA
Embedded Texture Cache	8MB (up to 5X Hardware Texture Compression)	Approx. 1MB Sustainable Latency : 6.2ns (1T-SRAM)	64MB UMA
Texture Read Bandwidth	0.8GB/Second	10.4GB/second (Peak)	6.4GB/sec peak
Pixel Depth	32-Bit color and Z-Buffer	24-bit color and Z-Buffer	32-bit color and Z-buffer
Number of Pixel Pipes	1	4*	4
Number of Texturing Units	1	4*	8
Image Processing Functions	3D Engine: Per pixel loadable table fog, Image super-sampling/scene anti-aliasing, Tile based reduced bandwidth rendering engine, Modifier Volumes (Shadows, etc), Specular highlights with offset colors Alpha + Multipass Blending, Color key and alpha blended textures, D3D and OpenGL blend modes, Texture Mapping Support: Multi-texturing, Bump-mapping, Environment mapping, Bi-linear, Tri-linear, and Anisotropic Filtering, 5X Texture Decompression, Bus mastered parameter fetch, Translucency sorting 2D Engine: Full ROP, text and line primitives, Full VGA compatibility, YUV to RGB color space conversion, MPEG2 decode assist (motion compensation acceleration), Integrated 250Mhz DAC (1920x1440 x 16bpp @ 65Hz / 1600x1200 x32bpp @85Hz), Color key overlay, Multiple video windows	Fog, Subpixel Anti-aliasing, 8 Hardware Lights, Alpha Blending, Virtual Texture Design, Multi-texturing, Bump Mapping, Environment Mapping, MIP Mapping, Bilinear Filtering, Trilinear Filtering, Anisotropic Filtering, Real-time Hardware Texture Decompression (S3TC), Real-time Decompression of Display List, HW 3-line Deflickering filter	Programmable vertex and pixel shaders, fog, Subpixel Anti-aliasing, 8 Hardware Lights, Alpha Blending, Multi-texturing, Bump Mapping, Environment Mapping, MIP Mapping, Bilinear Filtering, Trilinear Filtering, Anisotropic Filtering, Real-time Hardware Texture Decompression (S3TC)
Real-world polygon rates	5 Million Polygons Per Second (32x32 pixel tiles, front facing visible only) *3.5M in DOA2, 5 Million in full effect scenes in Le Mans	6 million to 12 million polygons/second (Peak) (Assuming actual game conditions with complex models, fully textured, fully lit, etc.) * 3 Million in RE4	116.5 million (using strips), so 116.5 vertices/sec *Theoretical
Pixel Fill Rate	100MPixels/s (200-500MPixels/s effective, Tile Based Renderer, dependent on scene complexity)	648Mpixels/sec (assuming four pixel pipes)*	932Mpixels/sec
Texel Fill Rate	100Mtexels/sec (200 - 500 Mtexels/sec effective)	648Mtexels/sec (assuming one texturing unit per pixel pipe, four pixel pipes)*	1.82Gtexels/sec

Sources:
http://forum.beyond3d.com/showthread.php?t=14660
http://en.wikipedia.org/wiki/PowerVR
http://people.csail.mit.edu/ericchan...13-lalonde.pdf
http://www.extremetech.com/computing...art-deux?print

-edit-

Also, I wanted to see what the group thought of another method for "counting" polygons per frame that might be useful. I thought about just overlaying a grid of triangles or quads that was proportionate to the known screen resolution in order to estimate how many polygons were on screen. With the Dreamcast this would obviously be a 32x32 pixel grid since that is all that goes to the display. Is there some kind of comparable triangle size that I could use for other 6th generation consoles assuming 640x480 resolution?

Quote:

---

Originally Posted by sheath

Back to my last question, the following is copied from what I just posted in the Dreamcast Appreciation thread. I would like to develop this table into as accurate an apples to apples comparison of the 6th Generation's hardware GPU capabilities as is possible to document.

---

Since the Game Cube shared main memory for graphics data as well, you should make note of the 24 MB of 1-T SRAM (honestly, same for the DC's 16 MB main RAM as I'm sure a ton of games stored added textures in main . . . though the DC is more of a PC-like set-up where you'd DMA copy from main to VRAM rather than directly reading from it as in the Xbox/PS2/GC).

Also, it's 3 MB of EDRAM in flipper, not 2. (configured as 1 MB texture buffer 2 MB framebuffer) Flipper can also do 32-bit color (8-8-8-8 RGBA) like contemporary ATI cards (actually all ATI 3D cards going back to the Rage II had 32-bit color 3D -unlike Voodoo or Riva, but like ViRGE). Albeit, you can't double buffer 640x480x32bpp in 2 MB, so I'm not entirely sure how that's actually used. (might be the reason a handful of GC games are clipped to less than 480p . . . running natively in 480i could also be a possibility, that or single buffering but then you'll get tearing unless you never drop below 50/60 FPS)

You should also note that the 10.4 GB/s is peak texture bandwidth in the EDRAM buffer, so you'd also want to note the bandwidth for fetching textures from the 24 MB shared RAM (2.7 GB/s). Of course, both that 10.4 and 2.7 figure would be peak, and realistic bandwidth would be with contention of CPU access to main RAM and framebuffer scanning overhead to EDRAM (and added latency hits on top of that). Granted, with the DC you've also got main RAM access overhead to consider (but less often given the 8 MB VRAM size) and some bandwidth eaten up by framebuffer scanning as well (proportionally much more VRAM time spend on the framebuffer given the slower RAM and all systems running at similar color depths/resolutions -640x480x32bpp uses ~73.7 MB/s).

With the Xbox, you share the same RAM for everything, so that bandwidth is contended for by the CPU (which can only use a fraction of it on its 133 MHz single-channel bus connection -533 MB/s). Albeit for both the DC and Xbox you've got additional on-die GPU caches that aren't being accounted for.

Then there's the issue of tile deferred rendering making much more efficient use of bandwidth on the Dreamcast as well, at least for properly optimized games. (hence why it was far more powerful than contemporary 100 MHz 1:0:1:1 GPU cores, and arguably more than the Voodoo 2/3's 1:0:2:1 config -at similar clock rate- though the next gen of 2:0:2:2 cores -TNT, G200/400, Rage 128- are another story)

There's also the issue of the hardware transform, lighting, and vertex shaders of the Radeon and Geforce derived GPUs. (the old PowerVR GPU being a more traditional "let the CPU handle the 3D math" configuration) That's going to be more of an apples to oranges comparison too, since it brings CPU performance into play on the DC's end (including the vector coprocessor). It's really going to be more of an overall system limitation than just a graphics bottleneck, since it depends on how CPU bottlenecked other parts of the game are.

Quote:

---

Also, I wanted to see what the group thought of another method for "counting" polygons per frame that might be useful. I thought about just overlaying a grid of triangles or quads that was proportionate to the known screen resolution in order to estimate how many polygons were on screen. With the Dreamcast this would obviously be a 32x32 pixel grid since that is all that goes to the display. Is there some kind of comparable triangle size that I could use for other 6th generation consoles assuming 640x480 resolution?

---

Polygons per frame really isn't a useful metric anyway. It's polygons per second that really matters, and you'll only get that in motion.

Plus, screen-counting polygons is pretty flawed anyway . . . with PCs, you've got actual benchmarks to compare things (game based or 3Dmark style stuff), but not so much for consoles. Or rather, no such demos or benchmarks that users could run. I'm sure many developers (1st and 3rd party) did testing on those grounds. (making that info publicly available is another matter entirely)

Quote:

---

Originally Posted by kool kitty89

Since the Game Cube shared main memory for graphics data as well, you should make note of the 24 MB of 1-T SRAM (honestly, same for the DC's 16 MB main RAM as I'm sure a ton of games stored added textures in main . . . though the DC is more of a PC-like set-up where you'd DMA copy from main to VRAM rather than directly reading from it as in the Xbox/PS2/GC).

---

Yeah, I was having a hard enough time finding bandwidth and other specs for just the VRAM of these systems. I would love to add the speed to Main RAM or each system as well, but for the Dreamcast in particular I don't know how much that would have been used. The Xbox side looks lopsided because of the unified RAM, the Dreamcast side looks lopsided because of the tile based renderer not showing up in some of the specs as much as it actually does in rendering.

Quote:

---

Originally Posted by kool kitty89

Also, it's 3 MB of EDRAM in flipper, not 2. (configured as 1 MB texture buffer 2 MB framebuffer) Flipper can also do 32-bit color (8-8-8-8 RGBA) like contemporary ATI cards (actually all ATI 3D cards going back to the Rage II had 32-bit color 3D -unlike Voodoo or Riva, but like ViRGE). Albeit, you can't double buffer 640x480x32bpp in 2 MB, so I'm not entirely sure how that's actually used. (might be the reason a handful of GC games are clipped to less than 480p . . . running natively in 480i could also be a possibility, that or single buffering but then you'll get tearing unless you never drop below 50/60 FPS)

---

I think that is how the extremetech.com chart listed Flipper's VRAM. I don't think any console of that generation did higher than 16-bit color textures, but I guess the full screen would be higher than that. I'd love to nail that figure down too.

Quote:

---

Originally Posted by kool kitty89

You should also note that the 10.4 GB/s is peak texture bandwidth in the EDRAM buffer, so you'd also want to note the bandwidth for fetching textures from the 24 MB shared RAM (2.7 GB/s). Of course, both that 10.4 and 2.7 figure would be peak, and realistic bandwidth would be with contention of CPU access to main RAM and framebuffer scanning overhead to EDRAM (and added latency hits on top of that). Granted, with the DC you've also got main RAM access overhead to consider (but less often given the 8 MB VRAM size) and some bandwidth eaten up by framebuffer scanning as well (proportionally much more VRAM time spend on the framebuffer given the slower RAM and all systems running at similar color depths/resolutions -640x480x32bpp uses ~73.7 MB/s).

---

I thought those specs said peak next to them. Also, I find the PVR2DC's SDRAM speed really low but I don't know any other way to measure it. I have the Dreamcast's main RAM at 800MB/s too though, so it must be correct.

Quote:

---

Originally Posted by kool kitty89

With the Xbox, you share the same RAM for everything, so that bandwidth is contended for by the CPU (which can only use a fraction of it on its 133 MHz single-channel bus connection -533 MB/s). Albeit for both the DC and Xbox you've got additional on-die GPU caches that aren't being accounted for.

---

GPU Caches? Have I mentioned that I find the online documentation for these systems extremely poor?

Quote:

---

Originally Posted by kool kitty89

Then there's the issue of tile deferred rendering making much more efficient use of bandwidth on the Dreamcast as well, at least for properly optimized games. (hence why it was far more powerful than contemporary 100 MHz 1:0:1:1 GPU cores, and arguably more than the Voodoo 2/3's 1:0:2:1 config -at similar clock rate- though the next gen of 2:0:2:2 cores -TNT, G200/400, Rage 128- are another story)

There's also the issue of the hardware transform, lighting, and vertex shaders of the Radeon and Geforce derived GPUs. (the old PowerVR GPU being a more traditional "let the CPU handle the 3D math" configuration) That's going to be more of an apples to oranges comparison too, since it brings CPU performance into play on the DC's end (including the vector coprocessor). It's really going to be more of an overall system limitation than just a graphics bottleneck, since it depends on how CPU bottlenecked other parts of the game are.

---

Yeah, I don't think that the tile based renderer was going to completely supplant the three year newer GPUs in the Xbox and Gamecube. What I was trying to do is document their respective GPU capabilities as simply and apples to apples as possible. There is a small contest as to whether the SH4+FPU was more than enough to handle the PIII+Hardware T&L GPU in the Xbox in this very thread though.

Quote:

---

Originally Posted by kool kitty89

Polygons per frame really isn't a useful metric anyway. It's polygons per second that really matters, and you'll only get that in motion.

Plus, screen-counting polygons is pretty flawed anyway . . . with PCs, you've got actual benchmarks to compare things (game based or 3Dmark style stuff), but not so much for consoles. Or rather, no such demos or benchmarks that users could run. I'm sure many developers (1st and 3rd party) did testing on those grounds. (making that info publicly available is another matter entirely)

---

Eh, I'm not even sure how that would work anyway. The Dreamcast's PVR2 only displays in 32x32 tiles and so can reach 5 million polygons per second, yet 32x32 pixels only goes into 640x480 three hundred times. So, Blargh.

Quote:

---

Originally Posted by sheath

I think that is how the extremetech.com chart listed Flipper's VRAM. I don't think any console of that generation did higher than 16-bit color textures, but I guess the full screen would be higher than that. I'd love to nail that figure down too.

---

Color depth is for the framebuffer, not textures. (textures might be in any number of formats, but with these 3 it would typically be compressed with PowerVR compression or DXTC -licensed derivatives of S3TC -iirc the PS2 typically relied on conventional 4-bit and 8-bit paletted textures for its compression, that's in terms of realtime compressed textures read directly by the GPU, not further compression of textures in main RAM which could be software decompressed and buffered as needed; not sure if RLE compressed textures were supported, though that was an interesting feature of the 3DO, that and support for 1, 2, and 6-bit textures)

Anyway, 24-bit and 32-bit framebuffers should have been typical for everything but the PS2 (which sometimes used 16-bit color). Both 24-bit RGB and 32-bit RGBA will look similar, but 32-bit RGBA allows for more complex alpha blending effects (24-bit has no alpha channel on the framebuffer).

Quote:

---

I thought those specs said peak next to them. Also, I find the PVR2DC's SDRAM speed really low but I don't know any other way to measure it. I have the Dreamcast's main RAM at 800MB/s too though, so it must be correct.

---

The bandwidth if pretty low, it's a significantly older GPU that was using relatively low cost mainstream RAM for the time (PC-100 SDRAM was mainstream for PCs at that point and 64-bit wide 100 MHz SDRAM would have been one of the cheaper options for a new GPU at the time too -compared to several 128-bit wide cards, faster SDRAM, and/or SGRAM)
Still, memory bandwidth is only one bottleneck for the GPU anyway, and mainly a limiting factor for fillrate . . . and only then if the GPU is actually fast enough to benefit from faster memory. (and, in this case, -on paper- the peak bandwidth 100 MHz 64-bit RAM was matched to the peak fillrate of the GPU . . . running RAM faster than the GPU fillrate wasn't uncommon either, but that was mainly useful for added framebuffer scanning bandwidth for high res stuff on PCs)

Quote:

---

GPU Caches? Have I mentioned that I find the online documentation for these systems extremely poor?

---

Most of that stuff would be confidential, just like modern GPUs . . . or pretty much anything from the late 90s onward. (and even older stuff has limited public documentation, but the details provided to developers allowed for more leaks than later stuff -the final days of low-level support for DOS and custom windows drivers and APIs)

Virtually all 3D GPUs for PCs have some form of texture caching/buffering (in addition to other on-chip buffers for framebuffer scanning and sometimes render output), and that became more and more advanced (and larger) as technology moved on. The exception to that comes with the use of EDRAM buffers and similar where those double as caches to some extent and "conventional" caches may be reduced or removed to compromise on cost. (you could keep both and have advantages in general, but there's obvious cost trade-offs there . . . then again, EDRAM local RAM vs dedicated external VRAM is a cost trade-off in itself)
You can bet the DC's and Xbox's GPUs have texture caches though, and quite possibly rendering output buffers too. (tile deferred rendering in particular could benefit from that, though I know ATi had already implemented such in the Rage 128 -called "Twin Cache Architecture" with an 8kB texture cache as well as an 8 kB pixel output buffer; for a 32x32 32bpp tile as in PowerVR you'd need a 4kB buffer)

Quote:

---

Yeah, I don't think that the tile based renderer was going to completely supplant the three year newer GPUs in the Xbox and Gamecube. What I was trying to do is document their respective GPU capabilities as simply and apples to apples as possible. There is a small contest as to whether the SH4+FPU was more than enough to handle the PIII+Hardware T&L GPU in the Xbox in this very thread though.

---

The Xbox is really in another league from the DC in hardware performance . . . they're at total opposite ends of the spectrum for that generation (wide enough apart to be from different console generations even). That said, there's still a lot of later gen games from that period that should have been able to be cut down and optimized to work reasonably well on the Dreamcast. (especially from 2001-2003 when developers should have been really familiar with the DC hardware -and perhaps even improved drivers/tools from Sega- where the newer systems still had more time going to really push the new hardware -plus the PS2 being another story too)

With the number of games that could end up CPU-bottlenecked on the DC, I don't think the GPU was going to be that huge of a problem, relatively speaking. (there's a few games that probably were relatively CPU light, but I'm pretty sure a lot of stuff would get held up by the DC's CPU too) RAM could have been a problem too, but probably less of an issue than the others. (some game engines simply wouldn't be able to be directly ported with the limited RAM . . . though had the DC remained on the market, more games could have targeted it earlier in development anyway)

And for the record, I'm pretty sure the SSE unit in a 733 MHz PIII will outstrip the 200 MHz SH4's vector unit by a pretty wide margin. (I'm not sure how the SH4's actual -non-SIMD- FPU performance compares per-clock, but I doubt that would fare any better) SSE wouldn't be used for 3D calculations of course, since that's done in hardware on the Geforce, though physics engines and audio (or streaming video) decoders could make use of it.

Quote:

---

Eh, I'm not even sure how that would work anyway. The Dreamcast's PVR2 only displays in 32x32 tiles and so can reach 5 million polygons per second, yet 32x32 pixels only goes into 640x480 three hundred times. So, Blargh.

---

Tiles can have multiple pieces of multiple polygons on them. The whole point of tile deferred rendering was to minimize overdraw (improve fillrate efficiency) and maximize bus bandwidth efficiency.

A well optimized PowerVR2 based game could probably compete with a Rage 128 running at double the nominal fillrate and similar color depths/resolutions. DirectX games would tend to run much better on the Rage though . . . and that's if you could even get them running on PowerVR (I forget which chipsets had the worst problems, but I know there were a lot of issues with Direct3D running on PowerVR in general . . . honestly, the Dreamcast's WindowsCE games manage pretty well considering the problems on PCs).

So the Dreamcast couldn't do Halo for instance?

Quote:

---

Originally Posted by evilevoix

So the Dreamcast couldn't do Halo for instance?

---

Each console of that generation could do Halo with various changes to the graphics or level design. The Dreamcast would need more frequent, but shorter, loads for the campaign at least. I'm not sure if the entire multiplayer levels could fit in RAM or not, Quake III needed significant cuts compared to the actual hardware capabilities in a "budget" development time.

Koolkitty, I'm still struggling with where to put the main RAM access for textures and whatnot. It doesn't seem like that would be needed equally across platforms.

Quote:

---

Originally Posted by sheath

Each console of that generation could do Halo with various changes to the graphics or level design. The Dreamcast would need more frequent, but shorter, loads for the campaign at least. I'm not sure if the entire multiplayer levels could fit in RAM or not, Quake III needed significant cuts compared to the actual hardware capabilities in a "budget" development time.

---

Aside from segmented loads, there's the issue of cuts in general to level complexity/size, etc. Ideally, you'd want to also take advantage of some of those cuts to better fit to GPU and CPU constraints as well.

Porting the actual Halo engine over to the DC could have been a problem, but that's where the question of a new engine (or a heavily hacked up one) comes into play. In that respect, this is rather moot since the DC probably never would have gotten Halo given MS's exclusivity. (and in the context of a DC-specific halo-like game, that would be a definite yes)

On that note, I'm going to repeat how it was a shame the DC didn't get Unreal. They even ported the Unreal engine relatively well, and having Unreal early on on the DC could have been great. (never on any other consoles and arguably the best FPS in the world at the time . . . amazing graphics, music, atmosphere, and an interesting and relatively complex story too) Not only that, but given the release date of Unreal Tournament, that also could have means Unreal could have been there by the 1999 holiday sales season.

Quote:

---

Koolkitty, I'm still struggling with where to put the main RAM access for textures and whatnot. It doesn't seem like that would be needed equally across platforms.

---

It would vary by game as well, but it would also depend on exactly what sort of graphics performance comparisons you'd want to make.

If you just want to compare raw GPU performance, that's sort of a separate topic in general, and could even exclude external VRAM in general. (comparing the GPUs themselves rather than the specific configuration used in the consoles in question)
The Dreamcast is also the only console of that generation to use dedicated external RAM for the GPU, everything else used shared RAM and/or local SRAM or DRAM on the GPU. So there's a different set of trade-offs relative to peak performance.
That's not to say that the DC would actually have real-world advantages over the GC or Xbox in any way, but just that it would be closer in certain circumstances than others.

It might just be better to list main RAM bandwith as a side-note, with the exception of the Xbox which has to use main RAM for everything, including the framebuffer.

Quote:

---

Originally Posted by kool kitty89

On that note, I'm going to repeat how it was a shame the DC didn't get Unreal. They even ported the Unreal engine relatively well, and having Unreal early on on the DC could have been great. (never on any other consoles and arguably the best FPS in the world at the time . . . amazing graphics, music, atmosphere, and an interesting and relatively complex story too) Not only that, but given the release date of Unreal Tournament, that also could have means Unreal could have been there by the 1999 holiday sales season.

---

I'm confused, what do you mean by the Dreamcast not getting Unreal?

https://www.youtube.com/watch?v=egjo7Mjy_8g

Even still, engines like Unreal didn't fully take over until the HD generation and their need to make development costs cheaper.

Quote:

---

Originally Posted by kool kitty89

If you just want to compare raw GPU performance, that's sort of a separate topic in general, and could even exclude external VRAM in general. (comparing the GPUs themselves rather than the specific configuration used in the consoles in question)
The Dreamcast is also the only console of that generation to use dedicated external RAM for the GPU, everything else used shared RAM and/or local SRAM or DRAM on the GPU. So there's a different set of trade-offs relative to peak performance.
That's not to say that the DC would actually have real-world advantages over the GC or Xbox in any way, but just that it would be closer in certain circumstances than others.

It might just be better to list main RAM bandwith as a side-note, with the exception of the Xbox which has to use main RAM for everything, including the framebuffer.

---

I agree, yes, this is simply a chart of GPU capabilities alone. We were talking about effects being better on the Xbox or Gamecube, and the assumption was similar polygon performance in games, which I think is very realistic for that generation.

Unreal is not Unreal Tournament.

Right, but as I understand it each version of Unreal Tournament debuted with a new version of the Unreal engine. I suppose Unreal Tournament on Dreamcast could be its own engine, but I don't know why they would do that. Also, as far as I know engines like Unreal and middleware weren't widely used on consoles until later in that generations. Making games on the Dreamcast was a matter of porting with WinCE or using a Sega Dev kit.

Quote:

---

Originally Posted by sheath

Right, but as I understand it each version of Unreal Tournament debuted with a new version of the Unreal engine. I suppose Unreal Tournament on Dreamcast could be its own engine, but I don't know why they would do that. Also, as far as I know engines like Unreal and middleware weren't widely used on consoles until later in that generations. Making games on the Dreamcast was a matter of porting with WinCE or using a Sega Dev kit.

---

I was talking about it being a shame that the DC didn't get Unreal, the game, not the engine. Unreal was (is) and amazing game and really awesome and engaging single player FPS to experience. It's just really awesome in so many areas, and evolution of existing FPSs up to 1998, as well as revolutionary in some aspects. (in some ways it's a stepping stone between the likes of Quake and Halo, but arguably still better than either of those in some aspects, and certainly unique in some areas -not to get into rambling details of the whole thing, but it actually has some things that Halo cut late in development, like the unique native fauna -both hostile and not- and non-aggressive native alien NPCs)

My comments on the engine used was that the DC already had a port/conversion/remake of the Unreal engine used for both the original UT and for Unreal, so Unreal could have launched around the same time as UT on the DC.

Been lurking for a while now, and figured I'd post some meager info here, since I decided to fire up the ol' DC today and play some Maken X for some reason, and then fired up the GC and Metroid Prime 2 and XBox and Halo 2. So I'm in a "comparison mood" for that gen. Don't ask why. It was a previous gen first person game day I guess (don't call Maken X or MP2 FPS games, though; I will fight you ;)).

Anyway, DC's bump mapping capability entered my thoughts today, because I think I might have seen it in use in Maken X. I've heard that only that single coin in Shenmue 2 utilized it, but I could've sworn there was a Godzilla game on DC that used it for the lizard's skin. So I searched real quick and found this, which may be of some interest to some in this topic:

http://yam.20to4.net/dreamcast/index_old.html

Seems the person behind that site might be the same yamato from Assembler (I've lurked over there as well...is that creepy, btw?), or maybe I'm wrong. Regardless, some interesting stuff on an engine for Dreamcast that person has been working on. If you go to the main section of the site, there's also info on DC's SH4 and programming tips for it.

Mentioned in there is bump mapping, and the idea that it might be there in some games, but some folks wouldn't realize it. Well, in Maken X, there's a section during the stage in the airliner, right before the first set of stairs (for those of you who've played the game) where there's two sofas. There's no directional lighting, per se, in that area (or in that stage for that matter), but the sofas have an area that looks...embossed, like it has shape on the neck rest area...but that area is flat, so it's not done with polys. Since it's flat, but looks like it isn't...could it be bump mapping? Or am I way off?

Also, before I forget: hello to koolkitty. I remember you from the AtariAge boards. And since you mentioned 3DO, which is something of a favorite failed console of mine, and the idea of "hidden caches": iirc, there's some "hidden" stuff in 3DO that wasn't in the dev docs. Or so I've read. Can't remember where, though. Something about hidden buffers that proved useful for a few devs doing certain effects, like a magnifying glass effect in one game. Oh, and I've seen some of the patents for the 3DO design: the original intention as far as the CPU went was to use the 610 (the one with the cache), not the 60. Don't know why they changed it, but I suppose it was to lower complexity/cost for the hardware manufacturers.

Yeah, hi from atariage. ;P

Interesting on the 3DO with the 610. I hadn't read that before, though in some related discussions, I actually suggested that would have made a better choice. Cost would be the obvious reason, but then again (if we're talking hypotheticals), the big cost/pricing issue was related to the overall business model the 3DO used. (if consolidated with a single manufacturing partner and sold at cost, the retail price should have much less than it was . . . that and they wouldn't have had to restrict the programming interface to only API/compiler like they did)
There's some other aspects about the hardware design where costs could have been different (like the 1 MB of dual-port VRAM rather than a GPU more optimized around using common FPM DRAM, among a few other things), but the manufacturing/business model is the really obvious thing with the 3DO. (not like all the things that were crazy surrounding the Jaguar :p )

So we were told to GTFO of the 5th generation thread.

Quote:

---

Originally Posted by sheath

As far as marketing though, Sega simply stated 3-3.5 million polygons per second and called it a day focusing on what could be displayed by actual games not just unrealistic tech demos. This can be reflected on every major website today and you will frequently see the Dreamcast's 3 million figure put up against the EE's lunar gravity figure of 75 million as a 1:1 comparison.

---

I really wish Sega could've done a Genesis-style commercial of calling BS on that.

Its like saying my Ford F-150 can do 100 km on 20 litres, while pulling a trailer with 4 horses inside of it.

While the Dodge Ram 2500 can do 100 km on 8 litres, while pulling nothing.