Support NeoGAF

[Geometric-Crusher]

Can anyone extract assets from fight night 2? (PS2 or GC)

 

[ShadyAcshuns]

It totally was. My friends use to come over and I'd show them some of the cut scenes and they'd be in awe.

 

[Esppiral]

Can anyone extract assets from fight night 2? (PS2 or GC)

From the GameCube version should be fairly easy, why are you asking?

Edit
By the looks of it that late gen game has massive polycount for the characters

 

[Fat Frog]

Cool SFX.

 

[Team Andromeda]

I still say that Virtual ON 2 was the best looking DC game. I find it silly that people need to bring in the GameCube or even the Xbox here. What never helped the DC other than the lack of SEGAs money was in 1998/9 not many developers outside the Arcade divisions of SEGA or Namco had a tool pipeline of handling development with more than a million polygon meshes. It took many developers way into 2000's to get up to speed

Even now so many DC games look clean and vibrant with beautiful textures and most running in 480P, unlike many low Res PS2 games with horrible jaggies

 

[Esppiral]

Edit; wrong quote.

 

[drganon]

I thought its graphics were pretty damn impressive at the time.

 

[Esppiral]

Can anyone extract assets from fight night 2? (PS2 or GC)

Maybe they are not that massive after all lol , they look higher poly than they acually are, that is what I call good topology.

 

[Geometric-Crusher]

Maybe they are not that massive after all lol , they look higher poly than they acually are, that is what I call good topology.

thank you I honestly thought it would have more polygons

 

[skeebs]

I think it was, that's why I bought one. I played Ferrari 355 Challenge in HMV and just knew......I HAD to have one.

I remember store demos. So many led me to buying systems. Particularly the SNES and Xbox 360 and even the PS2

 

[Fat Frog]

Maybe they are not that massive after all lol , they look higher poly than they acually are, that is what I call good topology.

The magic of modern tools ?

We want the same magic for the Dreamcast

 

[Fat Frog]

thank you I honestly thought it would have more polygons

 

[PaintTinJr]

Maybe they are not that massive after all lol , they look higher poly than they acually are, that is what I call good topology.

It is more likely the bump mapping ( a per pixel lighting technique) - rather than per vertex lighting, and adding shadow mapping (doubling geometry per frame per character), along with the multi-texturing.

I'm not sure how many of those capabilities the Dreamcast had for DoA2, but judging by the end results I'm guessing it could only do per vertex lighting and had to blend normals between neighbouring quads to provide any illusion of smooth surface geometry, illustrating why even if comparing rendering front facing polygons it doesn't actually represent more powerful hardware rendering if the difference is vertex lighting vs per pixel/fragment lighting.

 

[Fat Frog]

Speaking of real Sony hater,
the criminal O.J. Naka would have find a way to make a decent GTA3 happen on DC. (another Sega reprogrammed miracle ? )
I mean... the guy reprogrammed alone Ghoul's n' Ghost on the Genesis, he also helped tiers to make impossible ports by creating algorithms to compress datas.
Angry Naka litteraly wanted to kill Sony Playstation (he would have sold his wife for this goal )and would have squeezed every corner of the Dreamcast to make impossible ports (the DC had CriWare middleware for streaming audio which could also have been used for data according to indie dev, for instance and i guess there are many other tricks to push the limits of the system)

 

[Fat Frog]

Old tools (2001/99 enhanced engine)

1,3 million polygons/s

More advanced tools (2005)

1,07 million polygons/s

Comparison from 3Dbeyond...

How would you improve Shenmue on Dreamcast with 2005 tools? (Under Defeat is a 2005 game and it clearly has much more advanced SFX than 99% of Dreamcast old library...)

 

[Geometric-Crusher]

Old tools (2001/99 enhanced engine)
1,3 million polygons/s

More advanced tools (2005)

1,07 million polygons/s

Comparison from 3Dbeyond...

How would you improve Shenmue on Dreamcast with 2005 tools? (Under Defeat is a 2005 game and it clearly has much more advanced SFX than 99% of Dreamcast old library...)

Shenmue numbers is not possible because this entire map has 61,057 tris Pier - wharehouses -.

you know, the PS2 can show polygons instantly because of its fast bus, think of it as a 'geometry compressor'. This was explained on Beyond3d
For example, that user measured Shenmue also measured 'Triggerheart exelica' on the Dreamcast it reaches the limit of 52,000-60fps 3M poly/s, however there is a superior version of the same game on the ps2, the same scene where Dreamcast displays 52,000 on the ps2 displays 8,000, same scene.

RE4 using the PC version he measured the village scene 65,629 tris (the entire stage has 46,796 tris) per frame x 30 fps = 1.9M poly/s
on PS2 it's 17,680 tris per frame x 30 fps = 530K poly/s (it's the same geometry, the same scene but with no post-processing in the PC version)

Understand it ? If this game was ported to the Dreamcast, it wouldn't have to deal with 17,680 poly, but 65,629 poly, unless the Dreamcast was also a PS2, then it could deal with 17,680 tris per frame.

 

[PaintTinJr]

Old tools (2001/99 enhanced engine)

1,3 million polygons/s

More advanced tools (2005)

1,07 million polygons/s

Comparison from 3Dbeyond...

How would you improve Shenmue on Dreamcast with 2005 tools? (Under Defeat is a 2005 game and it clearly has much more advanced SFX than 99% of Dreamcast old library...)

IMO the two biggest possible improvements would have been using S3 video card maker's S3TC texture compression algorithm
- which is the basis of all Microsoft's Block Compress texture formats today, as it would have allowed for much bigger textures, or more textures at the existing size, providing the option for using baked lightmap lighting,

And secondly they could have moved to a deferred renderer assuming the GPU's assembly language routines could be rewritten to expose enough of an API interface for a simple deferred capability, potentially leading to more efficiency out of the limited memory and finite fillrate and T&L capability.

 

[SomeGit]

Shenmue numbers is not possible because this entire map has 61,057 tris Pier - wharehouses -.

61.057 times 30 equals 1.831.710
Remove the culled tris and add the NPCs/meshes and 1.3 million per second is not unreasonable.

 

[Geometric-Crusher]

61.057 times 30 equals 1.831.710
Remove the culled tris and add the NPCs/meshes and 1.3 million per second is not unreasonable.

Dreamcast is very dependent on its vram it cannot afford to load the entire stage's polygons all the time. Of the 8mb around 1.2MB is for the frame buffer 50k poly (huge number) would take up 2 MB, so 4.8 MB would be left for textures and other routines, 4.8 even with vq compression is not ideal, the ideal would be 25k poly 1mb, 1.2mb buffer and 5.8mb textures.

From what I observed on the Dreamcast there are some games that perform well at 30fps with 40-44k and above that the fps drops to 20fps.

Illbleed 2001 has a stage with 55,308 tris when extracted from the assets but during the game in real time, it does not display even half of these polygons, there is fog, short draw distance and the trees appear as we walk. Therefore, I refuse to accept that when Ryo is placed against a wall, so many polygons are being displayed, especially in a game with notorious pop-in. it would be the same as accepting that IllBleed does the same thing, which is not the case.

Honestly, we can't take polygonal counting seriously on the Dreamcast except for cases like doa2 where the extracted stages has 10k sometimes a little more, characters almost 10k for a total of 1.8M ~ 2.1M.

 

[Fat Frog]

Shenmue numbers is not possible because this entire map has 61,057 tris Pier - wharehouses -.

you know, the PS2 can show polygons instantly because of its fast bus, think of it as a 'geometry compressor'. This was explained on Beyond3d
For example, that user measured Shenmue also measured 'Triggerheart exelica' on the Dreamcast it reaches the limit of 52,000-60fps 3M poly/s, however there is a superior version of the same game on the ps2, the same scene where Dreamcast displays 52,000 on the ps2 displays 8,000, same scene.

RE4 using the PC version he measured the village scene 65,629 tris (the entire stage has 46,796 tris) per frame x 30 fps = 1.9M poly/s
on PS2 it's 17,680 tris per frame x 30 fps = 530K poly/s (it's the same geometry, the same scene but with no post-processing in the PC version)

Understand it ? If this game was ported to the Dreamcast, it wouldn't have to deal with 17,680 poly, but 65,629 poly, unless the Dreamcast was also a PS2, then it could deal with 17,680 tris per frame.

"Yes, but how many polygons?" An artist blog entry with interesting numbers

Here's one low-poly effort from pre-production [all of this was thrown out], greybox experiments from Uncharted 4 Scottland stages by @thegreatbluebit: [IMO this looks like a shippable art for a modern indie game :D ]

forum.beyond3d.com

Tell them.

 

[polybius80]

How would you improve Shenmue on Dreamcast with 2005 tools? (Under Defeat is a 2005 game and it clearly has much more advanced SFX than 99% of Dreamcast old library...)

under defeat is a shooter, some of the effects that kind of games use are not easily applied to other genres that is not to say nothing can be used

the more effect and lights the less polygons per second you can use, the DC has a lot of problems here, a better approach is to use them but restrict them with a very aggressive LOD systems, naturally the best way is to mimic other games and be very creative but IMO also make more emphasis in showing them to the player, for example shenmue can simulate bigger crowded areas using "impostors" that is 2d sprites in place of 3d models so in theory it can simulate something like the second scene in hitman blood money where there are hundreds of civilians instead of 3d models DC can use impostors and give the impression of a crowded city sure it wont looks as good but it is an improvement

like this but with sprites instead of 3d models


why not use that to simulate the famous japanes cities where lot of people cross the street I think is a good adition to shenmue even if it does nothing for the gameplay


in my opinion they can save some performance using a couple of blob shadows(one for each feet) instead of the simplified 3d model they use for shadows similar to link shadows in zelda ocarine of time specially in low light scenes

they can give more variety in light this is more artistic but... just look at it, why the floor is so bright? some walls are darker at the bottom because of the texture but others not even try, more care with lightmaps/vertex colors wont hurt even if they not correspond to the time of the day, why not have different sets for different hours? I am not saying they never use, there are parts where you can see some form of ilumination but almost all the game doesnt use any form of light control, other DC games care for their light like code veronica



even on PS1 there were games that simulated how the room was iluminated, I think is shenmue biggest problem





it was very uncomon to see effects that used the previous framebuffer as a texture, in the playstation era, tomb raider did very cool effects using the previous framebuffer to simulate reflection, they can use that to simulate characters reflected in water like screen space reflections

 

[Alexios]

Lol @ comparing some bright day outdoor shot with interior moody lighting and applying the former to the whole game, forgetting the day/night/weather/season cycles, time/player controlled lights, some dynamic, but sure, with even more money and time, they could have improved further

​

2D crowds wandering the streets (or even disappearing for a handful of 3D models to take their place up close?) wouldn't be an improvement and be rightfully ridiculed. They didn't simulate one far shot of the Shibuya Crossing, but a small explorable neighbourhood made even smaller in game.

Yakuza didn't do crowds until later PS3 entries even in its livelier areas, nor were Hitman 2+ crowds the norm in games (especially before DC died). Same for the shadows, just because you prefer only having feet shadows like Link doesn't mean it's objectively better to full, if simple, body shadows.

Vagrant Story and other famous examples released after Shenmue &/or were the result of dedicated learning to work around/with a specific hardware architecture for half a decade or more as the whole dang gaming industry was pouring all its developer and publisher resources into just that

But, they failed in combining all the resources and know how of every other achievement and special case the industry had until or even after that point into a single product that already pioneered its way around many other areas and was a massive undertaking made alongside those titles, booo!

 

[Clear]

For its time, Dreamcast was really strong hardware internally, it had a bunch of problems however in its overall design.

The controllers were heavy and uncomfortable in the hand for long play sessions, especially with the VMU's in (which had terrible battery-life).
It also was ridiculously easy to bypass its copy-protection, which was great for casual pirates but terrible for its business chances.

 

[Fat Frog]

Esppiral

 

[Geometric-Crusher]

Many Dreamcast fans wonder why the car windshields in Dreamcast games are black?

in fact not all, crazy taxi, v-rally 2, vanishing Point have full transparency while MSR, Test Drive Le mans have partial transparency.
this was due to the way Sega designed its hardware, again they concluded that transparency would make the project more expensive, at first no one noticed due to the superiority of the console compared to the N64 and PS1 But this weakness would be evident if the Dreamcast tried to replicate Scud Race aka Super GT a game entirely focused on transparencies, even Faster Than Speed did not overcome the problem because it is something intrinsically linked to the hardware.

 

[SomeGit]

Dreamcast is very dependent on its vram it cannot afford to load the entire stage's polygons all the time. Of the 8mb around 1.2MB is for the frame buffer 50k poly (huge number) would take up 2 MB, so 4.8 MB would be left for textures and other routines, 4.8 even with vq compression is not ideal, the ideal would be 25k poly 1mb, 1.2mb buffer and 5.8mb textures.

From what I observed on the Dreamcast there are some games that perform well at 30fps with 40-44k and above that the fps drops to 20fps.

Illbleed 2001 has a stage with 55,308 tris when extracted from the assets but during the game in real time, it does not display even half of these polygons, there is fog, short draw distance and the trees appear as we walk. Therefore, I refuse to accept that when Ryo is placed against a wall, so many polygons are being displayed, especially in a game with notorious pop-in. it would be the same as accepting that IllBleed does the same thing, which is not the case.

Honestly, we can't take polygonal counting seriously on the Dreamcast except for cases like doa2 where the extracted stages has 10k sometimes a little more, characters almost 10k for a total of 1.8M ~ 2.1M.

4.8MB is well within the texture budget for Shenmue, again, none of these number makes those number unreasonable.

Many Dreamcast fans wonder why the car windshields in Dreamcast games are black?

in fact not all, crazy taxi, v-rally 2, vanishing Point have full transparency while MSR, Test Drive Le mans have partial transparency.
this was due to the way Sega designed its hardware, again they concluded that transparency would make the project more expensive, at first no one noticed due to the superiority of the console compared to the N64 and PS1 But this weakness would be evident if the Dreamcast tried to replicate Scud Race aka Super GT a game entirely focused on transparencies, even Faster Than Speed did not overcome the problem because it is something intrinsically linked to the hardware.

This is just ridiculous, hardware OIT was one of the key features of the PowerVR chip so much so that Dreamcast to Gamecube ports had to downgrade or even remove them. SA could do 32 layers of transparency, as an example, hell, Chaos was made specifically to show off that the Dreamcast could do transparency with ease.

 

[Esppiral]

I you could add a simplified version of Soulcalibur 3 egypt stage, you would be my hero

Soon tm

 

[PaintTinJr]

This is just ridiculous, hardware OIT was one of the key features of the PowerVR chip so much so that Dreamcast to Gamecube ports had to downgrade or even remove them. SA could do 32 layers of transparency, as an example, hell, Chaos was made specifically to show off that the Dreamcast could do transparency with ease.

I assume the 32layers was because the colour framebuffer was a R5_G5_B5_A1 (16bit) buffer? And the alpha channel was used to set transparency on/off and the 5 bits sum of (1, 2, 4, 8, 16) sum to 31, meaning 0-31 permutations giving 32 layers options, yes? The 16bit framebuffer also would explain why the Gourand shader polygon throughput was decent on the console, because the shading was done at half the precision of the typical PS2, Cube and Xbox games, and at that colour precision couldn't have really gained much from S3TC texture compression.

Although the console had transparency, I would say it not being used much or fully doesn't indicate too much. The main reason why transparency only gets used in any game rendering - even today - is when it is absolutely required because it is guarantee to generate overdraw which gets worse with layer count and scene complexity, and would burden the system to sort the geometry in painters algorithm order before drawing them - well unless rendering with RT. So using transparency sparingly to efficiently use fillrate on a Dreamcast seems like a sensible approach.

 

[SomeGit]

There he goes again with the buffers, no it had nothing to do with the buffer limit 32 was the peak SA1 used. But Omikron required 64 to even render correctly , the console supported up 256 layers as per the Demul devs.

Transparencies and the reduction of overdraw (because of the tile based deferred renderer) were the key strengths of the powervr2, to this days it’s the only console to have a hardware solution for it.

 

[PaintTinJr]

There he goes again with the buffers, no it had nothing to do with the buffer limit 32 was the peak SA1 used. But Omikron required 64 to even render correctly , the console supported up 256 layers.

Transparencies and the reduction of overdraw (because of the tile based deferred renderer) were the key strengths of the powervr2, to this days it’s the only console to have a hardware solution for it.

??? depth ???

 

[SomeGit]

??? depth ???

Not depth buffers either.

 

[PaintTinJr]

Not depth buffers either.

You clearly don't understand the standardized colour buffer formats that have evolved over the last two to three decades of HW Accelerated GPUs if you don't understand what I am saying. A typical format for the last 3 gens would be RGBA_8888, with the alpha colour channel giving 256 levels of transparency (2^8). So 32 levels is non-standard relative to the PS2, Cube, Xbox and all the consoles that have followed.

 

[SomeGit]

You clearly don't understand the standardized colour buffer formats that have evolved over the last two to three decades of HW Accelerated GPUs if you don't understand what I am saying. A typical format for the last 3 gens would be RGBA_8888, with the alpha colour channel giving 256 levels of transparency (2^8). So 32 levels is non-standard relative to the PS2, Cube, Xbox and all the consoles that have followed.

The 32 limit had nothing to do with any buffer limit, it was the peak for layers SA1 got to.

I don’t know how much simpler I have to tell you this, it had nothing to do with any buffer limit

I don’t know why you are so eager to paint me as ignorant when you clearly have no clue about the actual specs of PowerVR2. Hell but you don’t even know anything about SMBD, did stop you from making 2 pages worth of ignorant assumptions.

 

[PaintTinJr]

The 32 limit had nothing to do with any buffer limit, it was the peak for layers SA1 got to.

I don’t know how much simpler I have to tell you this, it had nothing to do with any buffer limit

I don’t know why you are so eager to paint me as ignorant when you clearly have no clue about the actual specs of PowerVR2. Hell but you don’t even know anything about SMBD, did stop you from making 2 pages worth of ignorant assumptions.

How on earth do you think transparency works in rasterization computer graphics if it isn't directly related to the GPUs colour render buffer formats ? 32 is derived somewhere in the dreamcast hardware from a 5bit storage in a register that aligns to an 8bit boundary for efficient use of RAM and performance in a binary digital system.

On 16bit systems they align on 16bits, and on 32bit systems they align on 32bits, etc. alpha channels are for transparency and are typical a fractional part of those registers, with the remainder being used for colour, hence the R5_G5_B5_A1 aligning to 32levels.

If like for hidden surface removal the Dreamcast GPU did something completely non-standard for transparency too, then feel free to point me to the technical documentation, if you have access to it.

The overriding thread question is surely a technical one in your opinion, no? So if my inference of R5_G5_B5_A1 as a limit is correct, then along with the vertex lighting, rather than per pixel shader lighting, it all illustrates a technical gulf between the Dreamcast and its would be peers, no?

 

[SomeGit]

How on earth do you think transparency works in rasterization computer graphics if it isn't directly related to the GPUs colour render buffer formats ? 32 is derived somewhere in the dreamcast hardware from a 5bit storage in a register that aligns to an 8bit boundary for efficient use of RAM and performance in a binary digital system.

On 16bit systems they align on 16bits, and on 32bit systems they align on 32bits, etc. alpha channels are for transparency and are typical a fractional part of those registers, with the remainder being used for colour, hence the R5_G5_B5_A1 aligning to 32levels.

If like for hidden surface removal the Dreamcast GPU did something completely non-standard for transparency too, then feel free to point me to the technical documentation, if you have access to it.

The overriding thread question is surely a technical one in your opinion, no? So if my inference of R5_G5_B5_A1 as a limit is correct, then along with the vertex lighting, rather than per pixel shader lighting, it all illustrates a technical gulf between the Dreamcast and its would be peers, no?

I'm talking about transparency layers and ordering, why do you keep trying to talking about color? You have no clue what you are talking about.
Again, 32 is just for Sonic Adventure 1, the limit for ODT on the PowerVR chip is 256.

 

[Unknown?]

DC was the last system to advertise bits to convey power. I remember all the hype for 128 bits!

 

[PaintTinJr]

I'm talking about transparent layers and polygon ordering, why do you keep trying to talking about color? You have no clue what you are talking about.
Again, 32 is just for Sonic Adventure 1, the limit for ODT on the PowerVR chip is 256.

So do you have access to the Dreamcast PowerVR technical documentation, yes or no? If yes we'll clear this discussion up quickly.

 

[SomeGit]

So do you have access to the Dreamcast PowerVR technical documentation, yes or no? If yes we'll clear this discussion up quickly.

You can find it online, google it. I don't even know what you are trying to say at this point. If you are asking if it supports RGB888 it does.

 

[butane bob]

Honestly? Seeing Soul Calibur on the DC was probably the last time i was truly blown away at graphics in a video game.

 

[PaintTinJr]

You can find it online, google it. I don't even know what you are trying to say at this point. If you are asking if it supports RGB888 it does.

Texture Formats - dreamcast.wiki

dreamcast.wiki

RGB888 can be request as paletted but can't be bilinear filtered at speed because it is using arrays of 16bit values in colour index mode - like the N64 indexed textures from how it reads below.

True colour format ARGB_1555 is listed, but doesn't seem to lineup with the 32 layers in the description and seems it more likely it was the ARGB_4444 format, and it was probably two passes(2x16) of 4bit transparency in SA1 if it was 32layers and it does seem without trickery the system was intended for RGB_565 colour rather than RGB_888.

Even the programming examples such as this

KallistiOS/examples/dreamcast/video/palmenu/palmenu.c at master · KallistiOS/KallistiOS

A homebrew SDK/pseudo-operating system for the Sega Dreamcast. This repository is a mirror of the official SourceForge repository for KOS. - KallistiOS/KallistiOS

github.com

initialise the video mode with a 640x480 resolution with a RGB_565 setup at line 32-33

Color formats​

Truecolor​

This table describes the color information that can be stored in textures.

ARGB1555	each color channel has 5 bits, transparency is on or off
ARGB4444	each channel has 4 bits, use if you need a transparent gradient
BUMP	bumpmap format (stores angles for vertex displacement effects in lighting calculations), similar to a normal map
YUV422	mostly used for video decoding, uncommonly used

Paletted​

There are also paletted texture formats which can be combined with the above color formats as well as ARGB8888.

4BPP_PAL (or 8BPP_PAL)

1. Define an array of 2^4 = 16 (or 2^8 = 256) color values.
2. Copy the array to the graphics chip, then send textures that use 4-bit (or 8-bit) indices into that array instead of 16 bit argb as pixel values.

ARGB8888 is slow when used with filtering.

You can set multiple palettes on the graphics chip at the same time (1024 bytes total), so they're not per-texture at all, but global.

Paletted textures are always twiddled and never strided.

 

[SomeGit]

Just check video.h:

typedef enum vid_pixel_mode {
PM_RGB555 = 0, /**< \brief RGB555 pixel mode (15-bit) */
PM_RGB565 = 1, /**< \brief RGB565 pixel mode (16-bit) */
PM_RGB888P = 2, /**< \brief RBG888 packed pixel mode (24-bit) */
PM_RGB0888 = 3, /**< \brief RGB0888 pixel mode (32-bit) */
PM_RGB888 = 3 /**< \brief Backwards compatibility support */
} vid_pixel_mode_t;

KalistOS has to pick one so it defaults to 16-bit.

I don't even have to point this out, the 32 layers are for sorting not color, yet because you don't understand the difference between the 2 because you have absolutely no clue about what you are talking about. The color format has nothing to do with Sonic Adventure 1 peak of 32 transperency layers, they have no relation to each other, if you've know anything about tile rendering, you'd know that sorting happens before any texture information comes into play and the TSP always blends at RGBA8888 anyway.

This discussion is doubly funny, because the mighty PS2 had to resort to 8 bit paletted texture, I'd the say the vast vast majority of it's titles. Who cares if ARGB888 textures where slow on the Dreamcast, the other consoles of that gen seldom used them.

Look up how Tile Based rendering works on the DC and look what information the Tile Accelerator on the PowerVR2 does, and stop posting about color buffers and texture formats since it's clear you haven't gotten a single clue about them. Specially on the Dreamcast, at least by now you should know that the Dreamcast doesn't use a W-buffer, like you were parroting for pages.

 

[Geometric-Crusher]

PS2 had to resort to 8 bit paletted texture, I'd the say the vast vast majority of it's titles.

not most, all. this is how the console works.

you are repeating a silly myth, a palletized texture is the same texture present in some game, only stored in the ps2's vram at a low color depth, it after being applied to the game's wire, filters are applied, restoring the quality again. There are dozens of examples where the PS2's 8-bit texture surpasses that of the Dreamcast even GC, GC uses s3tc this means there is no game on the gamecube that doesn't use s3tc. The architecture of each console is made to work as it should.

 

[SomeGit]

not most, all. this is how the console works.

you are repeating a silly myth, a palletized texture is the same texture present in some game, only stored in the ps2's vram at a low color depth, it after being applied to the game's wire, filters are applied, restoring the quality again. There are dozens of examples where the PS2's 8-bit texture surpasses that of the Dreamcast even GC, GC uses s3tc this means there is no game on the gamecube that doesn't use s3tc. The architecture of each console is made to work as it should.

That's not true, there are other texture modes:

0	PSMCT32	RGBA32, uses 32-bit per pixel.
1	PSMCT24	RGB24, uses 24-bit per pixel with the upper 8 bit unused.
2	PSMCT16	RGBA16 unsigned, pack two pixels in 32-bit in little endian order.
10	PSMCT16S	RGBA16 signed, pack two pixels in 32-bit in little endian order.

They are seldomly used though. I don't know about the GC though. There are also dozen of examples of the opposite depends on the texture, I'm not saying that 8-bit PT is inherently inferior, just that this:

So if my inference of R5_G5_B5_A1 as a limit is correct ... it all illustrates a technical gulf between the Dreamcast and its would be peers, no?

It's not exactly true.

 

[Team Andromeda]

I remember AM2 saying issues over transparent effects were the hardest part of Shenmue 2 port to the Xbox.

 

[Esppiral]

I remember AM2 saying issues over transparent effects were the hardest part of Shenmue 2 port to the Xbox.

The Xbox version of ShenmueII removed quite a lot of transparencies for glass and shops signs.

 

[TNT Sheep]

Speaking of transparencies. The Dark Falz battle in Phantasy Star Online is a lot less atmospheric without the floating ghosts present only in the Dreamcast version.

 

[Fat Frog]

I remember AM2 saying issues over transparent effects were the hardest part of Shenmue 2 port to the Xbox.

I remember it as well (because it was surprising)

Another subject:

How would you improve water effects on Dreamcast, what can be done ?
(This ripple effect on sport Jam is pretty nice but i would have liked to see it ingame)

 

[Team Andromeda]

I remember it as well (because it was surprising)

Another subject:

How would you improve water effects on Dreamcast, what can be done ?
(This ripple effect on sport Jam is pretty nice but i would have liked to see it ingame)

Yeah it was in the Next Level interview and I never would have thought the Xbox would have major issues with DC transparency effects.

Didnt see many great weather effects on the DC other than in D2 and the amazing (for the time ) heat haze effect in Maken X wheb the jet plane takes off

 

[Team Andromeda]

The Xbox version of ShenmueII removed quite a lot of transparencies for glass and shops signs.

Like I said I was amazed to read that was the major Issue AM2 with the Xbox port of Shenmue 2.

I have to say the graphics in Sakura Wars IV on the DC were some of it's best . Such a shame it was never brought to the west on the DC

 

[cireza]

I remember AM2 saying issues over transparent effects were the hardest part of Shenmue 2 port to the Xbox.

Maybe because of this feature :

Dreamcast Architecture | A Practical Analysis

An in-depth analysis that explains how this console works internally

www.copetti.org

• Alpha blending: Combines colours of overlapping layers to achieve transparency effects.
  • The process used for applying transparency in this system is called order-independent transparency. The algorithm automatically sorts the primitives before blending their colours, and while this slows down the rendering process, it avoids relying on the game itself to do all the sorting manually. For this reason, Dreamcast games excelled in displaying transparent objects.
  • Combined with the tile-based system, order-independent transparency completely addresses previous mishaps.

Depending on Xbox works (and I don't know) they probably had to handle the correct order themselves in engine.