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

Well the only other game I can remember using bumpmap is tomb raider the last revelation, it was a touted feature. It's on some parts of the walls and floor. It's a Windows ce game though. When walls and floors are close to the camera the texture seems to "shift" imo. I guessing only things that are close to you are bumpmapped. You might have to brighten your screen if you want to check it out. The game is dark as hell.
 
What have I done???!!!



I had forgotten just how crisp everything looks with a VGA cable. Some games benefit greatly, others... not so much. I also found out that my VMs had been corrupted and many files lost :(. Ain't no way I'm ever trying to beat Sonic Adventure 2 again though hahahaha.
Anyway, here's Rayman 2, taken with a Xiaomi Redmi 4a by shooting directly at the CRT monitor.



I'll also provide some video footage, shitty as it may be, perhaps someone will be able to get something out of this.

https://streamable.com/42j4i

To the best of my knowledge, there is no bump mapping evident here. It really seems to be using a technique that's similar to "Detail Textures" from Unreal. I can't remember if the PC version did anything similar, but it does look pretty good all things considered.
 
impossible to understand anything from the video :p
But maybe its impossible because there is nothing there
 
Garrett Weaving said:
To the best of my knowledge, there is no bump mapping evident here. It really seems to be using a technique that's similar to "Detail Textures" from Unreal. I can't remember if the PC version did anything similar, but it does look pretty good all things considered.
Click to expand...
Nice try! Can't see much but it really is indistinguishable from a detail texture. If it was bump mapping, it was the most pointless resource-wasting implementation ever. ;)
 
Nesh said:

Interesting
Click to expand...
Oh, hey. That old thing. I'm actually working towards an interactive normal map demo that people can run on real hardware to allow people to experiment with. There will be a couple different models and shading methods to pick and you'll be able to rotate the model and light source and see what the results are.
Shifty Geezer said:
If it was bump mapping, it was the most pointless resource-wasting implementation ever. ;)
Click to expand...
With the PVR, the only real overhead to normal maps is on the CPU, transforming the light vector into texture space and converting it to polar coordinates. For a static light source, there is no difference in CPU load, GPU polygon throughput, or fillrate, as far as I can tell. This is compared to a regular detail texture; the PVR only has one TMU, so multitexturing requires multiple passes, but the same number of passes (two) are required for diffuse + detail or diffuse + normal. The only difference I can think of is that a standard detail texture would be much more texture compression friendly than a normal map.
 
Well, in Rayman's use, the advantage of normalmaps is they end up with more variety of resulting looks across the level. The same texture would look slightly differently at each angle, something you would not get with a standard RGB detail texture overlay.
 
TapamN said:
Oh, hey. That old thing. I'm actually working towards an interactive normal map demo that people can run on real hardware to allow people to experiment with. There will be a couple different models and shading methods to pick and you'll be able to rotate the model and light source and see what the results are.
With the PVR, the only real overhead to normal maps is on the CPU, transforming the light vector into texture space and converting it to polar coordinates. For a static light source, there is no difference in CPU load, GPU polygon throughput, or fillrate, as far as I can tell. This is compared to a regular detail texture; the PVR only has one TMU, so multitexturing requires multiple passes, but the same number of passes (two) are required for diffuse + detail or diffuse + normal. The only difference I can think of is that a standard detail texture would be much more texture compression friendly than a normal map.
Click to expand...

Wow really looking forward to it!
 
Nesh said:

Interesting
Click to expand...
OMG! I made that texture back in the late 90s to compare different bump map techniques**. I still have a JPG version of it.
Now I do feel old.

**Basically it was to show the "displacement" approach that one 3D card company were describing falls apart when trying to model light approaching from anything other than a subtle angle, whereas the PVR2 method worked.
 
Simon F said:
OMG! I made that texture back in the late 90s to compare different bump map techniques**.
Click to expand...
Yes, that's where it's from. I wish you uploaded a PNG instead of a JPEG of the height map, because the compression artifacts are kind of noticeable.

Since you're here, can I ask a quick question about texture compression on the PVR? (If you remember after all this time) IIRC, you've mentioned before on the dcdev Yahoo group that 8 and 4 bit textures can be compressed, but homebrewers have discovered that apparently compression works on even rectangular and bump/normal textures, which surprises me. Games like Shenmue use uncompressed rectangular textures and compressed square textures but always take care to always avoid using compressed rectangular textures. It seems odd that games would consistently avoid them if they work.

Do you remember if there a hardware reason that official games avoid them, like, they don't work on certain revisions of the hardware or they might not work if the chip is too warm? Same question with compressed normal maps, I would have expected that the dot product hardware would make some critical path too long or something when used with compression, but they seem to work as well? (I guess if 4/8 bit textures officially work, these should be enough timing slack for normal maps to work too...)
 
TapamN said:
Yes, that's where it's from. I wish you uploaded a PNG instead of a JPEG of the height map, because the compression artifacts are kind of noticeable.
Click to expand...
I wish I had as well....but I simply didn't have the space on that host.

Since you're here, can I ask a quick question about texture compression on the PVR?
Click to expand...
I'm assuming here you mean the VQ compression on Series 2 (i.e. ARC1, Dreamcast /CLX2 & Neon250)
(If you remember after all this time) IIRC, you've mentioned before on the dcdev Yahoo group that 8 and 4 bit textures can be compressed,
Click to expand...
Not sure what you meant here. The VQ decompression hardware could target (i.e. decompress to) either the default 16bpp textures (e.g. 565, 4444, NormalMaps) or 8bpp palette textures. The former achieved ~2bpp and the latter, ~1bpp.
but homebrewers have discovered that apparently compression works on even rectangular and bump/normal textures,
Click to expand...
I don't recall that we had non-square textures on CLX2! Maybe we did...but I don't remember it<shrug> Or maybe MIP mapping didn't work with non-square. I'd have to go digging ... but I don't have the time. sorry
 
Forgot to update this topic. Sc2 on DC @ 30 fps.

sc2spec.jpg
 
Karamazov said:
even at the time, most devs did not bother much taking full advantage of the DC hardware for multiplat

Click to expand...
Exactly. I feel like that's the reason there are still people naive enough to say DC is more 5th gen than 6th, despite the likes of doa2, soul cal, shenmue, recv, Ferrari, Lemans, etc.
 
Karamazov said:
even at the time, most devs did not bother much taking full advantage of the DC hardware for multiplat

Click to expand...

I am not fully agreeing on this. This is a PS1 game ported to the Dreamcast.

If we want to make proper comparisons we should be comparing multiplatform games with the generation it belonged to. The DC was getting lots of games were the devs tried to take advantage of the hardware. Those previous to next gen ports didnt define the Dreamcast. They were bonuses.
 
of course but that's similar to a lot of complaints we've seen for the past 3 years with cross gen games, barely enhancing the last gen versions of games for the new consoles, and the assumptions that the new consoles are not much better.
Games were much simplier back then, one could have expected more effort put into the DC versions.
 
Sonicfan said:
I'm sure Namco could have optimized and got 60fps. This is amazing to see either way, though!
Click to expand...
For sure namco would have to optimize if they wanted 60 fps . Most likely cut down the geometry in the stage a bit. Even with the stage zoomed like that it's still pushing a lot of vert( higher than doa2). Could still look very good, like I mentioned before kinda like Tekken 5 ps2 to psp. I mean they could opt for 30 fps to keep the look intact as well( probably lighting would still be a burden to some degree)
 
Cloofoofoo said:
For sure namco would have to optimize if they wanted 60 fps . Most likely cut down the geometry in the stage a bit. Even with the stage zoomed like that it's still pushing a lot of vert( higher than doa2). Could still look very good, like I mentioned before kinda like Tekken 5 ps2 to psp. I mean they could opt for 30 fps to keep the look intact as well( probably lighting would still be a burden to some degree)
Click to expand...
Agreed. I think before the lose anything close, far background elements would be simplified, then certain stage elements, then maybe some lights, then maybe the characters. Then again, I don't think it would take that much sacrifice, lol. 30fps Is fine, too, but considering it's 60fps elsewhere, they'd probably want to keep that fluidity. 😉
 
You must log in or register to reply here.
Back
Top