Could Dreamcast et al handle this/that game/effect? *DC tech retrospective *spawn
- Thread starter xaeroxcore
- Start date
-
- Tags
- sega
I believe this should have been in the other thread about polygons. This is the DC threadThe character has several layers of hair, I don't know if they are duplicates or different Lods polycout is between 130.000 and 150.000
I believe so too. The Dreamcast spat out Sonic Adventures 2 near the end of it's life cycle. It was a huge improvement over the original. It was 60fps with massive detail for it's time. I am sure the PS2 would never have been able to reproduce that game faithfully.
Both Saturn and the Dreamcast are consoles that at the end left us with a lot of curiosity. They are unopened pandora's boxes. Every console that managed to last long came with impressive surprises at the end. Sega's last two consoles never had the same luxury as the consoles that had a normal life cycle. Yet the Saturn, despite it's hardware troubles, it brought us Panzer Dragoon Saga. It is most likely the only game that came so late but wasn't rushed.
I wish we could find out what these consoles would have produced if they were profitable enough and developers had the incentive to exploit their maximum potential.
Many of the assets for Shenmue 2, including complete environments, were produced in 1997 and 1998. They are first gen fare in terms of tools and artist experience. It's particularly apparent in terms of the texturing, where bilinear filtered texture maps with no mip maps shimmer their way across the screen. The engine, however, improved significantly between Shenmue 1 and 2, with greater NPC counts and for the most part the elimination of fps dips when streaming in NPCs.
I love the Shenmue games - they are the ultimate expression of late 90's ambition - but if after Shenmue 2, AM2 had built Shenmue 3 assets with the tools and experience they now had - including normal maps and shadow volumes - they game would have looked radically different and much better.
Fighting Vipers 2 for DC was mostly developed after Sega had binned the DC. It was a port from very different hardware, with minimal time and probably a budget of $7.
Still a fun game tho...
SH4 was pretty incredible for its die area and power consumption. 200 mHz was the top end for the chip at the time (increased from 166 in pre-release) but it was intended not to need a heatsink. DCs have been overclocked to well above 250 mHz with heatsinks. DC could generate 10 million lit polygons per second, with optimal parameters and all CPU time dedicated to it.
Sega were keen to avoid multiprocessor systems after the Saturn (with its horrible Master / Slave dual CPU setup). But a dual SH4 setup could have allowed 3, 4, 5 or more times the real-world polygon processing performance given the same none transform and lighting demands. That would also have required another 3 ~ 5 MB of video ram though. And probably more main memory for the assets.
Garrett Weaving
Newcomer
Isn't the lack of mipmaps in Shenmue usually attributed to the team's arcade roots?
I think that's a factor, in that it's how their asset creation and memory usage was done then. When you're set up for Model 2 and Saturn and are rapidly ramping up asset creation, if you set requirements without considerations for mip-maps then you can't exactly undo that later. Some scenes and assets present in Shenmue 2 (released in 2000) were first revealed in 97.
Certainly AM2 didn't have anything against using mip mapping and trilinear filtering in the Xbox port of Shenmue 2. Or in any of their games after about '99. Didn't VF4 have trilinear (many years since I've seen the arcade version)? Fun fact: at least one game - Sega Bass Fishing - didn't even use bilinear filtering on some peculiar textures. Point sampling, yo!
Tools and artist experience improved massively between 97 and 2001. A Shenmue 3, with assets made from 2001 onwards, would have looked very different to 1 and 2. Something like Z-brush would have priceless for a normal map capable, but vertex limited machine.
What's so difficult about implementing mip mapping after the fact? The extra memory they take? Generating them? I can't see how either of those things is overly complicated.
Memory was what I was thinking of. You need 33% more memory, and when you've already used it all, and maybe you don't have an automated pipeline to generate arbitrary sized textures from very high res originals (because the originals are what we got - and still see in the HD re-release) it'd be a time sink you couldn't afford.
The tools Shenmue was made with were incredibly basic. No version control, no bug management - everything was managed through manually updated Excel spread sheets. All assets were signed off manually. Incredible. 97 and 98 was mid PS1 era after all. Game speed was still tied to CPU update ticks! When judged according to the time it was made, Shenmue is still the most incredible game to have been made, IMHO.
What we do know is that the year after Shenmue 2 for DC, it came to the Xbox complete with mip maps. So the very same AM2 were obviously happy to use them when they could enable them with the flick of an SDK switch. So it wasn't a stylistic thing, or trying to honour some kind of Model 2 aesthetic.
I think they made call about the best way to use the memory back in 97 - before they even had final hardware and tools - and they kind of went with it. Go for maximum texture resolution and variety, like they automatically had on their arcade hardware and like they had on the Saturn version of Shenmue. By 2001 it was pretty clear that mip maps were a good thing and worth using even if you traded off some memory.
Can anyone remember if Virtua Fighter 4 used 'em??
I don't remember that. I remember the coin things that you could view on their own, it felt like something a programmer had been exploring and then chucked in as an easter egg. They have pre-baked shadows too, which fuels my suspicion that it was a programmer mucking around with something an artist had already done.
Shenmue uses modifer volume's for Ryo's shadow during the day time. NPCs use those flat projected model shadows (like Model 2 fighters). During night, Ryo uses NPC style shadows, but he does produce shadows from up to two light sources.
Only the Xbox version of Shenmue II does shadows from buildings, the DC versions has some prebaked shadows on the ground near buildings. Both adjust lighting as the sun moves.
Shenmue II is the only game I know of to use the DC's normal/bump maps... on three coins. But the base texture on the coins have prebaked shadows and highlights.But at least they tried.
I always wondered how was this type of primitive "bump-mapping" even done on Dreamcast. Anybody knows?
Doesnt seem to respond correctly to the lighting and angle.Tomb Raider IV uses bump/normals, only no the Dreamcast versión.
this demo though if real seems to have better results
Is that full screen or split screen? Because 2P versus mode is split screen with (IIRC) no loss of detail, so the real throughput is twice that.
As a DC homebrewer, the SH4 does fine. IIRC, I've hit around 4.2 million polygons per second and became GPU limited. I think that code could reach something like 6 million polygons per second if the PVR was faster and had enough memory to store all the polygon data. In my code, I was doing transform, perspective, a single directional light, and ambient; not very advanced, but still useful.
You can actually get close to the theoretical peak FLOP rate of 1.4 GFLOPS inside a loop. FTRV, the vector transform instruction (which multiplies a 4x4 matrix with a 4D vector), can be issued every 4 cycles. With 64-bit moves, you can load and store an entire vector in that time, just barely enough to keep the FPU fed, so it's not just "1.4 GFLOPS until you use up what you have in registers."
You have to use the SH4's SIMD instructions differently than how they would be used on a traditional system since the real heavy lifter is the FTRV instruction. You can, for example, stick your light direction vectors in a matrix, load the vertex normal in a vector registers, and use FTRV and get the intensities for four lights in parallel. Clamp the results to >0, stick the light colors in a matrix, and FTRV the light intensities to get the final RGB results. Asymptotic average would be 16 cycles per vertex, or 4 cycles per light. In this case, clamping >0 would take half the run time... (8 cycles per vertex, 2 per light) Something like a clamp vector or pair instruction would have been really useful.
The SH4 can also normalize vectors pretty fast. I've managed an average of one vector every 8 cycles (a 32 cycle loop that does 4 vectors per iteration).
Speaking of Shenmue and mipmapping, in my experience of seeing how the PVR handles certain scenes, the lack of mipmapping is responsible most of the slow down that occurs. There's actually a bit more mipmapping that what has been mentioned. Xiuying's apartment has mipmapping on the floor, and in Guilin, the foliage is mipmapped. The random floors were probably just a mistake, but the trees and bushes were definitely intentional to get more fillrate out of the PVR.
I don't think Shenmue's lack of mipmaps have anything to do with AM2's arcade games. The Model 2 and 3 both used mipmapping (the Model 3 even used trilinear with detail textures), so AM2 had probably used them more than anyone else at Sega. (Most emulators don't implement mipmaps accurate to original hardware, so expect to see it by looking at emulated footage. If you go looking at recordings of real hardware, (IIRC, this is according to what I've read on the Supermodel emulator forums) the Model 3 only did mipmaps down to 8x8 with some detail bias, so there still may be some aliasing on far textures.) Maybe Shenmue's Saturn origins had an influence, but I think AM2 just preferred having extra/larger textures from the memory saved by not using mipmaps.
I don't really have time to explain how the PVRs normal maps work right now. They have some weirdness to them, but are useable.
Cool info, I'd love to hear more insider details on DCs tech when you have time.
Are there any NAOMI 1 or 2 games with bump and/or normal maps?
Brilliant!
Interesting that the examples of mip-mapping came from Shenmue 2. I think the head demos included with Shenmue 1 were some of the later sections to be made - ready for E3 in 2000. Xiuying's apartment was used in one of them. I need to check my passport disk and see if the backgrounds there are mip-mapped.
I did actually wonder about the performance impact on texture units of not using mip mapping - it'd cause a lot more cache misses as you dropped below 1:1 pixel / texel ratio, wouldn't it, and for a relatively simple pipeline that wouldn't be masked well ...?
I imagine it could potentially cause some performance issues if texture decompression workload was increased too e.g decompressing a 2x2 block only to not use75% of the data, with texture decompression becoming a bottleneck.
Some slowdown in Shenmue 1 can be attributed to characters streaming in as you walk down the street - if you wait for a character to finish streaming in the game speeds back up. Doesn't explain everything though.
Thanks. I was hazy on model 2, which is shameful!
Cloofoofoo
Regular
That was with split screen. It was much lower without . Like 3- 5000 Tris per frame single player. There might be some lod on the opponent Vr in split screen. Don't remember .
They(emu authors) say Rayman 2 had full bump mapping on the stages themselves .there is screen shots online doing comparison with and without bumpmaps.