Could Dreamcast et al handle this/that game/effect? *DC tech retrospective *spawn

[Shifty Geezer]

It's probably wrong to call any rendering 'brute force'. All hardware had its access paradigms. XB just provided the simplest access paradigm extending the well-understood PC + DirectX model of the time. All the other machines were peculiar collections of disparate processors and buses that need special attention. The best you could probably say for 'brute force' was a system with enough overhead that it could take a port from another machine and run it similarly without needing extensive hardware-specific rewrites to accommodate a change in paradigm. But that didn't really exist. Porting from PS2 to Xbox needed a complete rewrite in how everything worked, moving from multipass rendering to shaders, etc.

 

[Nesh]

It's probably wrong to call any rendering 'brute force'. All hardware had its access paradigms. XB just provided the simplest access paradigm extending the well-understood PC + DirectX model of the time. All the other machines were peculiar collections of disparate processors and buses that need special attention. The best you could probably say for 'brute force' was a system with enough overhead that it could take a port from another machine and run it similarly without needing extensive hardware-specific rewrites to accommodate a change in paradigm. But that didn't really exist. Porting from PS2 to Xbox needed a complete rewrite in how everything worked, moving from multipass rendering to shaders, etc.

If the game was a port of a PS2 game, sure, they had to recompile and rewrite to a different architecture. But still the XBOX had in most cases the overhead to replicate and run the same game at faster framerates and higher resolutions. If we take games designed for XBOX or games ported from PC, the XBOX had more room for higher res multilayered textures, higher resolution output, higher framerates and default support of effects on a hardware level compared to PS2. The PS2 suffered from more downgrades and was a bigger challenge to replicate or port games from other platforms to it.

 

[Sonicfan]

I wouldn't associate PS2 with bruteforce at all. You couldn't just dial up everything and expect it to work. PS2 was the opposite of that. The machine was designed around a premise which required developers to know how to manually squeeze it's capabilities, like using it's VU's, managing the bandwidth of tiny VRAM to stream in and out textures, etc. AA wasn't supported by the hardware by default either. It's effects weren't coming for free. They had to be manually handled and a lot of effects required smart use of geometry multipasses.

If there was one console where you could bruteforce everything was XBOX, where it had the processing power, the memory and the default hardware support to dial up everything.

I'm really talking polys and effects. I know ps2 was harder to get to have good picture quality or textures, but it was definitely easier to render out polys and effects. Lighting even. Devs said that in interviews all the time.

 

[Nesh]

I'm really talking polys and effects. I know ps2 was harder to get to have good picture quality or textures, but it was definitely easier to render out polys and effects. Lighting even. Devs said that in interviews all the time.

When they said easier of course they meant it had the capability to do it, since the PS2 was more powerful and capable in those areas. But actually implementing those effects? I am still not sure "bruteforce" is the right word considering the dev hell it was to implement. Bruteforce implies that it was just a matter of applying it, when in reality those effects weren't exactly available for implementation. They had to be manually created. Most devs were struggling. Very few talented developers at launch were capable at reaching and surpassing DC's best. Actually there was even a notion of doubting PS2's capabilities in the beginning. Only the creme of the crop came with results at launch that demonstrated what the PS2 could do.

 

[TapamN]

So, what's the homebrew scene like on DC? We've seen some incredible old-hardware stretching games like the Atari 7800 or ZX Spectrum. Is anyone making a DC pushing title just for fun? I suppose maxing an 8 bit machine is far, far less work than maxing out a complex console.

Did I post this here? A collection of some random effect tests.

https://imgur.com/a/DyaqzZD

The first image was a scene I used to test how texture format affects fillrate/render time. For that scene (it could vary greatly depending on exact camera angle, scene complexity, texturing), I got these results:

36.22 ms (16 bit VQ no mips 2x SSAA)
19.70 ms (16 bit uncompressed no mips)
19.69 ms (16 bit VQ no mips)
16.83 ms (16 bit small codebook VQ no mips)
15.92 ms (4 bit uncompressed no mips)
13.52 ms (4 bit VQ no mips)
12.78 ms (16 bit VQ with mips 2x SSAA)
11.85 ms (4 bit VQ with mips 2x SSAA)
11.24 ms (4 bit small codebook VQ no mips)
11.13 ms (Untextured 2x SSAA)
9.49 ms (16 bit uncompressed with mips)
9.20 ms (16 bit VQ with mips)
8.80 ms (8 bit VQ with mips)
8.61 ms (16 bit small codebook VQ with mips)
8.53 ms (4 bit uncompressed with mips)
8.53 ms (4 bit VQ with mips)
7.91 ms (4 bit small codebook VQ with mips)
7.81 ms (Untextured)

All with bilinear filtering and normal mipmap detail levels. "VQ" is a compressed texture with a full codebook (2048 bytes) and "small codebook VQ" is quarter size (512 bytes), which fits the PVR's texture caches better. For uncompressed textures, the PVR behaves as though it has a 512 texture cache, and for compressed textures, there seems to be a 512 byte cache for indices and 512 byte for the codebook.

So 2x SSAA with mipmapping generally renders faster than no SSAA without mipmaps. Last year, I've looked into modding Shenmue to add mipmapping and SSAA, which would have less GPU slowdown than the original game.

Shenmue's engine actually has some SSAA support built in. There's an init flag that turns on hardware AA and adjusts the 3D transforms to account for it, but 2D elements aren't adjusted, so they're squashed into the left half of the screen. There's some bug in the video driver than causes it to set the frame buffer address incorrectly when page flipping, so the screen vibrates left and right by 2 or 4 pixels each flip, and the edges of the display are corrupted. I was using VGA, it's possible NTSC might work better? When there's alpha-tested foliage, there's basically always slowdown, but otherwise it's still mostly 30 FPS when in Dobuita or indoors (I didn't try the harbor, there would probably still be slowdown there.)

Shenmue also has support for other resolutions, like 320x240 noninterlaced NTSC, although I haven't tried it. Shenmue uses the old PVR driver, which lacks support for any VGA resolution other than 640x480.

The engine also handles 24-bit and 32-bit color pretty well. I thought there would be problems with running out of video RAM, but it just loads fewer NPCs, so after it loads the static NPCs, there's only one person, maybe two, wandering around in Dobuita. Space Harrier had broken graphics when not in 16-bit color (the backgrounds are broken, but the sprites are fine). It felt strangely wrong when I played the game with dithering-free 24-bit color, and forced bilinear on 2D elements (mainly to fix the pixelated sky).

 

[Sonicfan]

When they said easier of course they meant it had the capability to do it, since the PS2 was more powerful and capable in those areas. But actually implementing those effects? I am still not sure "bruteforce" is the right word considering the dev hell it was to implement. Bruteforce implies that it was just a matter of applying it, when in reality those effects weren't exactly available for implementation. They had to be manually created. Most devs were struggling. Very few talented developers at launch were capable at reaching and surpassing DC's best. Actually there was even a notion of doubting PS2's capabilities in the beginning. Only the creme of the crop came with results at launch that demonstrated what the PS2 could do.

I guess i should say the fillrate was so high they could do that despite the difficulties. DC may have been easier, but the way it renders is more of a task to get those effects out of it, atleast with the tools they had at the time. Especially for western devs. There's also the factor of budgets, etc. Sega didn't have the time or money to go all out on games, that's why most were arcade ports, B-C teir games, and smaller games in general. Sony was coming off the absolutely incredible ps1 and the trust/success of that; Ofcourse devs were gonna put more time and effort behind it. It could have been weaker than DC and devs would have put more into it, honestly. Things like wii and switch prove that, haha.

 

[Sonicfan]

Did I post this here? A collection of some random effect tests.

https://imgur.com/a/DyaqzZD

The first image was a scene I used to test how texture format affects fillrate/render time. For that scene (it could vary greatly depending on exact camera angle, scene complexity, texturing), I got these results:

36.22 ms (16 bit VQ no mips 2x SSAA)
19.70 ms (16 bit uncompressed no mips)
19.69 ms (16 bit VQ no mips)
16.83 ms (16 bit small codebook VQ no mips)
15.92 ms (4 bit uncompressed no mips)
13.52 ms (4 bit VQ no mips)
12.78 ms (16 bit VQ with mips 2x SSAA)
11.85 ms (4 bit VQ with mips 2x SSAA)
11.24 ms (4 bit small codebook VQ no mips)
11.13 ms (Untextured 2x SSAA)
9.49 ms (16 bit uncompressed with mips)
9.20 ms (16 bit VQ with mips)
8.80 ms (8 bit VQ with mips)
8.61 ms (16 bit small codebook VQ with mips)
8.53 ms (4 bit uncompressed with mips)
8.53 ms (4 bit VQ with mips)
7.91 ms (4 bit small codebook VQ with mips)
7.81 ms (Untextured)

All with bilinear filtering and normal mipmap detail levels. "VQ" is a compressed texture with a full codebook (2048 bytes) and "small codebook VQ" is quarter size (512 bytes), which fits the PVR's texture caches better. For uncompressed textures, the PVR behaves as though it has a 512 texture cache, and for compressed textures, there seems to be a 512 byte cache for indices and 512 byte for the codebook.

So 2x SSAA with mipmapping generally renders faster than no SSAA without mipmaps. Last year, I've looked into modding Shenmue to add mipmapping and SSAA, which would have less GPU slowdown than the original game.

Shenmue's engine actually has some SSAA support built in. There's an init flag that turns on hardware AA and adjusts the 3D transforms to account for it, but 2D elements aren't adjusted, so they're squashed into the left half of the screen. There's some bug in the video driver than causes it to set the frame buffer address incorrectly when page flipping, so the screen vibrates left and right by 2 or 4 pixels each flip, and the edges of the display are corrupted. I was using VGA, it's possible NTSC might work better? When there's alpha-tested foliage, there's basically always slowdown, but otherwise it's still mostly 30 FPS when in Dobuita or indoors (I didn't try the harbor, there would probably still be slowdown there.)

Shenmue also has support for other resolutions, like 320x240 noninterlaced NTSC, although I haven't tried it. Shenmue uses the old PVR driver, which lacks support for any VGA resolution other than 640x480.

The engine also handles 24-bit and 32-bit color pretty well. I thought there would be problems with running out of video RAM, but it just loads fewer NPCs, so after it loads the static NPCs, there's only one person, maybe two, wandering around in Dobuita. Space Harrier had broken graphics when not in 16-bit color (the backgrounds are broken, but the sprites are fine). It felt strangely wrong when I played the game with dithering-free 24-bit color, and forced bilinear on 2D elements (mainly to fix the pixelated sky).

That's interesting. I wonder if am2 considered using mipmaps and things like lod in order to have more npcs on screen . I'd say go so far as to start with sprites in the far distance then build from there. Maybe if Shenmue 3 had come, they would have tried that.

 

[Sonicfan]

This is very eye opening to DC's potential!

 

[EsppiraK]

Did I post this here? A collection of some random effect tests.

https://imgur.com/a/DyaqzZD

The first image was a scene I used to test how texture format affects fillrate/render time. For that scene (it could vary greatly depending on exact camera angle, scene complexity, texturing), I got these results:

36.22 ms (16 bit VQ no mips 2x SSAA)
19.70 ms (16 bit uncompressed no mips)
19.69 ms (16 bit VQ no mips)
16.83 ms (16 bit small codebook VQ no mips)
15.92 ms (4 bit uncompressed no mips)
13.52 ms (4 bit VQ no mips)
12.78 ms (16 bit VQ with mips 2x SSAA)
11.85 ms (4 bit VQ with mips 2x SSAA)
11.24 ms (4 bit small codebook VQ no mips)
11.13 ms (Untextured 2x SSAA)
9.49 ms (16 bit uncompressed with mips)
9.20 ms (16 bit VQ with mips)
8.80 ms (8 bit VQ with mips)
8.61 ms (16 bit small codebook VQ with mips)
8.53 ms (4 bit uncompressed with mips)
8.53 ms (4 bit VQ with mips)
7.91 ms (4 bit small codebook VQ with mips)
7.81 ms (Untextured)

All with bilinear filtering and normal mipmap detail levels. "VQ" is a compressed texture with a full codebook (2048 bytes) and "small codebook VQ" is quarter size (512 bytes), which fits the PVR's texture caches better. For uncompressed textures, the PVR behaves as though it has a 512 texture cache, and for compressed textures, there seems to be a 512 byte cache for indices and 512 byte for the codebook.

So 2x SSAA with mipmapping generally renders faster than no SSAA without mipmaps. Last year, I've looked into modding Shenmue to add mipmapping and SSAA, which would have less GPU slowdown than the original game.

Shenmue's engine actually has some SSAA support built in. There's an init flag that turns on hardware AA and adjusts the 3D transforms to account for it, but 2D elements aren't adjusted, so they're squashed into the left half of the screen. There's some bug in the video driver than causes it to set the frame buffer address incorrectly when page flipping, so the screen vibrates left and right by 2 or 4 pixels each flip, and the edges of the display are corrupted. I was using VGA, it's possible NTSC might work better? When there's alpha-tested foliage, there's basically always slowdown, but otherwise it's still mostly 30 FPS when in Dobuita or indoors (I didn't try the harbor, there would probably still be slowdown there.)

Shenmue also has support for other resolutions, like 320x240 noninterlaced NTSC, although I haven't tried it. Shenmue uses the old PVR driver, which lacks support for any VGA resolution other than 640x480.

The engine also handles 24-bit and 32-bit color pretty well. I thought there would be problems with running out of video RAM, but it just loads fewer NPCs, so after it loads the static NPCs, there's only one person, maybe two, wandering around in Dobuita. Space Harrier had broken graphics when not in 16-bit color (the backgrounds are broken, but the sprites are fine). It felt strangely wrong when I played the game with dithering-free 24-bit color, and forced bilinear on 2D elements (mainly to fix the pixelated sky).

Wow are those demos available anywhere?

 

[xaeroxcore]

So, what's the homebrew scene like on DC? We've seen some incredible old-hardware stretching games like the Atari 7800 or ZX Spectrum. Is anyone making a DC pushing title just for fun? I suppose maxing an 8 bit machine is far, far less work than maxing out a complex console.

You can find some examples on this very thread:

Probably what Frogbull is doing with the Simulant Engine wih Star Wars and MGS 2 on DC

What @EsppiraK is doing with DOA 2

But probably the top tier homebrew DC game that actually was released to retail is this from 2013, if i´m not wrong:

Also, another great homebrew milestone was the release of this PSP Minis port to DC

It's probably wrong to call any rendering 'brute force'. All hardware had its access paradigms. XB just provided the simplest access paradigm extending the well-understood PC + DirectX model of the time. All the other machines were peculiar collections of disparate processors and buses that need special attention. The best you could probably say for 'brute force' was a system with enough overhead that it could take a port from another machine and run it similarly without needing extensive hardware-specific rewrites to accommodate a change in paradigm. But that didn't really exist. Porting from PS2 to Xbox needed a complete rewrite in how everything worked, moving from multipass rendering to shaders, etc.

Xbox of course can brute force stuff....Like PC Quake 3 Arena (and Quake 2 and AVP)

 

[xaeroxcore]

This is very eye opening to DC's potential!

Forget about that!!

Take a look on this!

This could finally sorts of proof that DC can actually run GTA 3!!

@sheathx013 i´m the one who asked you yesterday on the YouTube comments the same, by the way

 

[EsppiraK]

Those videos are cool, but, the major bottleneck for performance on the Dreamcast is the CPU and a PIII @800mhz just destroys the SH4. Not sure if this is representative.

 

[Sonicfan]

Those videos are cool, but, the major bottleneck for performance on the Dreamcast is the CPU and a PIII @800mhz just destroys the SH4. Not sure if this is representative.

```Neon 250
The Dreamcast's PowerVR CLX2 GPU was the basis for the PowerVR PMX1, a PC GPU released with the Neon 250 graphics card in 1999. However, the Neon 250 lacks many of the tiled rendering features of the CLX2: the tile size is halved (halving the fillrate), it lacks the CLX2's internal Z-buffering and alpha test capability with hardware front-to-back translucency sorting (further reducing the fillrate and performance, as well as requiring the Neon 250 to render a Z-buffer externally), and the tiling is partially handled by software (the CLX2 handles the tiling entirely in hardware). The Neon 250 also lacks the CLX2's latency buffering and palettized texture support while VQ texture compression performance is halved, and it has bus contention due to having a single data bus (whereas the CLX2 has two data buses).

The PowerVR2 was also optimized for the Hitachi SH-4's geometry processing capabilities (rather than for a Pentium II or III), while PC drivers and software were not optimized for the Neon 250's tiled rendering architecture (compared to Dreamcast games which were optimized for the CLX2's tiled rendering architecture). The Neon 250 thus had only a fraction of the Dreamcast CLX2's fillrate and rendering performance. The reduction in performance from the Dreamacst's CLX2 to the Neon 250 was comparable to the reduction in performance from the Sega Model 3's Real3D Pro-1000 to the Intel740.``````The Neon 250 thus had only a fraction of the Dreamcast CLX2's fillrate and rendering performance.```

That's what I've been reading everywhere. The Hitachi may have been clocked lower, but was more optimized from my understanding. I'm inclined to believe that since games like Doa2/ shenmue 2 exist on DC and those are earlier titles.

 

[xaeroxcore]

Those videos are cool, but, the major bottleneck for performance on the Dreamcast is the CPU and a PIII @800mhz just destroys the SH4. Not sure if this is representative.

```Neon 250
The Dreamcast's PowerVR CLX2 GPU was the basis for the PowerVR PMX1, a PC GPU released with the Neon 250 graphics card in 1999. However, the Neon 250 lacks many of the tiled rendering features of the CLX2: the tile size is halved (halving the fillrate), it lacks the CLX2's internal Z-buffering and alpha test capability with hardware front-to-back translucency sorting (further reducing the fillrate and performance, as well as requiring the Neon 250 to render a Z-buffer externally), and the tiling is partially handled by software (the CLX2 handles the tiling entirely in hardware). The Neon 250 also lacks the CLX2's latency buffering and palettized texture support while VQ texture compression performance is halved, and it has bus contention due to having a single data bus (whereas the CLX2 has two data buses).

The PowerVR2 was also optimized for the Hitachi SH-4's geometry processing capabilities (rather than for a Pentium II or III), while PC drivers and software were not optimized for the Neon 250's tiled rendering architecture (compared to Dreamcast games which were optimized for the CLX2's tiled rendering architecture). The Neon 250 thus had only a fraction of the Dreamcast CLX2's fillrate and rendering performance. The reduction in performance from the Dreamacst's CLX2 to the Neon 250 was comparable to the reduction in performance from the Sega Model 3's Real3D Pro-1000 to the Intel740.``````The Neon 250 thus had only a fraction of the Dreamcast CLX2's fillrate and rendering performance.```

That's what I've been reading everywhere. The Hitachi may have been clocked lower, but was more optimized from my understanding. I'm inclined to believe that since games like Doa2/ shenmue 2 exist on DC and those are earlier titles.

With Ninja 2 or Naomilib this could have been possible! Now those tools are on community´s hands...so....

 

[davis.anthony]

The issue with the 3D GTA is memory and the lack of it on DC.

I'm not sure you could even strip GTA3 it back enough to even get it to fit in the 16MB.

 

[Sonicfan]

The issue with the 3D GTA is memory and the lack of it on DC.

I'm not sure you could even strip GTA3 it back enough to even get it to fit in the 16MB.

According to the likes of Ian Michael, DC had a faster drive abd could strameam assets in and out very well, so that 16mb wouldn't be a problem.

 

[Shifty Geezer]

Plus better texture compression?

 

[davis.anthony]

According to the likes of Ian Michael, DC had a faster drive abd could strameam assets in and out very well, so that 16mb wouldn't be a problem.

Of course it would.

You're still talking half the RAM and more than half the streaming speed of PS2 (Seen DC's GD-ROM listed as 1.8MB/s compared to 5.4MB/s for PS2's DVD drive)

Forget about the actual processing requirements, GTA3 wouldn't work just from a basic streaming point of view.

 

[Sonicfan]

Of course it would.

You're still talking half the RAM and more than half the streaming speed of PS2 (Seen DC's GD-ROM listed as 1.8MB/s compared to 5.4MB/s for PS2's DVD drive)

Forget about the actual processing requirements, GTA3 wouldn't work just from a basic streaming point of view.

Idk why that would be a problem. You act as if DC didn't have open world games like crazy taxi at 60fps streaming in assets. Granted, it was as interactive perse, but dropping the fps down to 30 or so would free up a ton. Plus simply optimizing and the newer tools wiuld help lots. Even the devs said gta3 wouldn't be a problem on DC in a recent interview. I'd ve inclined to believe them.

 

[davis.anthony]

Idk why that would be a problem. You act as if DC didn't have open world games like crazy taxi at 60fps streaming in assets.

Crazy Taxi has a piss poor draw distance (much lower than GTA3's) and flat environments so hardly a case to prove GTA3 is possible on DC from a streaming point of view, if anything it proves the opposite.

The draw distance in Crazy Taxi is so bad and the environments wouldn't look out of place on PSOne, games colorful looks flatter it to be honest.

Granted, it was as interactive perse, but dropping the fps down to 30 or so would free up a ton. Plus simply optimizing and the newer tools wiuld help lots. Even the devs said gta3 wouldn't be a problem on DC in a recent interview. I'd ve inclined to believe them.

From what I've read in DC forums, the devs have claimed they had the game in first person running on DC, but wanted 3rd person which it didn't have the memory for.