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

function said:
Speaking of bump mapping, the final version of DC Doom 64 is out.


Some tehnical highlights:
- 16 dynamic lights
- bump mapped environments and weapons
- geometry tessellation
- dual analogue controller support
- 60 fps (most of the time)

Obviously having a N64 game as the starting point gives a lot of headroom, but it's worth pointing out that the N64 only launched 2 years earlier. That's now monumental of a jump the DC was.

I remember years ago @Simon F saying there was no reason the DC couldn't have used BM in games - it was fast enough. I guess 60 fps fullscreen validates that, though obvioulsy there's a cost to it.

I played Doom 64 through back in the day and it's a really good game once you get used to it not looking like classic doom.
Click to expand...
It's a shame as these recent creations show that DC could have easily kept going and compete in that generation
 
Been loving reading everyone's DC vs PS2 vs Xbox vs PC graphics comparisons and opinions on GTA3, but... What if I were to tell you that the Sega #Dreamcast has another trick up its sleeve. One that didn't make it into the alpha release on time? HW capture of the internal render target resolution ramped up to 1280x480, enabling 2x horizontal fullscreen anti-aliasing with the DC's PVR GPU... aaaaand goodbye jaggies! We're so CPU-bound that this is essentially free for most scenes, (although admittedly performance does take a hit in heavy rain/fog with this enabled). so it's still a WIP!
Click to expand...

https://twitter.com/x/status/1875905175728136379
 
function said:
I've been thinking about this. Do you think it would be possible to keep track of vertex list size on the CPU side, so that if you were approaching the limit for a frame just call it a day and end rendering of that particular frame?

This would obviously risk causing noticeable visual artefacts but it might be better than risking a crash, and if you were to temporarily lower LOD for the next frame to stay inside the limit the glitching would disappear. Then as soon as your vertex list had enough free headroom in vram you could return to the player's preferred setting. Do you think the game could handle changing LOD on the fly well enough?
Click to expand...
Ughghgh. If you notice the real-time VMU profiler, where it says "VTX %," that's actually exactly what we're doing. We're querying the PVR registers for how far the TA has written into the vertex buffer. When that value gets to 100%, it's RIP PVR.


While we did add some code to start discarding meshes after we cross a particular threshold in terms of vertex buffer utilization, the solution is not without issues... Due to the order in which the renderer submits geometry, we wind up drawing from back-to-front and will be discarding major geometry in the FOREGROUND as that vertex buffer overflows, which looks like ass. We need to be discarding geoemtry in the background which is most likely not going to be noticed between being distant and/or partially fogged out.

...unfortunately PH3NOM's attempts to sort the deferred geometry to render in the opposite order to reject the background geometry upon overflow have not been fruitful either, since it takes a lot of time to sort the geometry in the opposite direction on the CPU, so there is a performance hit...

I've kind of been wondering if there's a better way that we can do broad-phase "bucketing" of geometry into discrete depth buckets that we can do O(1) insertions into and O(N) iterations over... but... then such a solution would require extra RAM to store this sparse structure, which we might not be able to afford either... lol.
 
Nesh said:
It's a shame as these recent creations show that DC could have easily kept going and compete in that generation
Click to expand...

That video doesn't even cover some of the prettier areas when the lighting looks the most visible. It's really impressive stuff, up to 16 lights and bump mapped. His port also uses those extra stages that has more geometry than what the original N64 stages had. I know there's limitations to dc version of BM but it be interesting to see it on an animated character.

screen-20250106-220102-2.gif



Nesh said:
What's re3?
Click to expand...
Re3 is the code DC is based off. Basically reversed engineered gta3 from the PC version. It also has some PS2 vu code in it.
 
Last edited:
Cloofoofoo said:
That video doesn't even cover some of the prettier areas when the lighting looks the most visible. It's really impressive stuff, up to 16 lights and bump mapped. His port also uses those extra stages that has more geometry than what the original N64 stages had. I know there's limitations to dc version of BM but it be interesting to see it on an animated character.

screen-20250106-220102-2.gif
Click to expand...
Oh, I soooo agree with you. Please check out this comparison video I made between jnmartin's Dreamcast version (actual HW capture) and the Steam version. It's not even the same game anymore. Pretty ridiculous: https://drive.google.com/file/d/1XwwQYipmNtHIAnZey3WbimU2Thja1AlL/view?usp=drive_link

I was convinced bump mapping was under-utilized on the DC for quite awhile, but had no direct proof, as I hadn't really messed around with it myself either outside of playing with isolated tech demos from the homebrew scene... Before jnmartin, we had no idea what the real cost of doing this in an actual full-game setting really was. We had no idea how many surfaces you could even get away with bump mapping realistically or even whether it looked particularly good or not. Did it murder the PVR's fill-rate? Was it worth the additional VRAM resources and light direction computations?

All we had were a very very few, isolated uses of bump mapping in commercial games such as Rayman 2 and Tomb Raider--both of which I think do a totally piss-poor job of utilizing it with neither having a real dynamic light source hitting the geometry that was being bump mapped... but could you really blame them? Around 1999-2000, who the *hell* was really bump mapping, and especially on a console game? What tools were there even out there to generate bump maps from? What artist even knew how the hell to work with them? Then even if they did have some knowledge/experience, the chances of them ever having worked with the PVR's "2-channel polar coordinate-like" bump maps would've been next to nothing. Sure wouldn't have seemed worth the effort to me, if they were complex to use, there was little-to-know literature on them, they require extra VRAM for the bump texture, an extra pass for the bump map, then finally some extra calculations for converting the light vector into polar form...

...combine that with the DC being a platform mostly for half-assed 5th gen ports where a lot of AAA studios were afraid to invest heavily into it, had more limited budgets, had less financial incentives to invest into DC-specific technology, etc.

I can tell you right now Simon has told me that even the tools they used at Imagination were only able to generate PVR bump maps from 1D *height map* textures, which is fundamentally shittier in quality than doing it from a standard 3-channel *normal map* texture... believe me, we verified this in the first days of jnmartin implementing bump mappping in Doom64. Using a heightmap looks like crap in comparison... You have to remember that even though it was always called "bump mapping" on Dreamcast, its bump maps are encoding THREE dimensional directional information per-texel, within its two polar coordinate channels... it REALLY is "normal mapping," imho, if you want to be more accurate.

Also, apparently Matt Godbolt has also stated that Red Dog for DC has bump mapping code within the engine, as they were experimenting with it, but it never made it into the final game, because they couldn't figure it out... Which is crazy, given how high-quality that codebase seems to be in terms of utilizing the DC... but hey, what resources were there for this kind of stuff back then?

Anyway, the moral of the rant? jnmartin has single-handedly answered lingering questions about the Dreamcast's bumpmapping potential and has shown that not only can the Dreamcast bump map some surfaces and look pretty good, but it can bump map the CRAP out of a whole scene with at least 5th gen-level polygon counts, do it with up to 16 simultaneous dynamic lights impacting them, and do it all at 60fps... So... yeah, it's settled. Simon was right. The Dreamcast was fully capable of doing this kind of stuff the entire time... Just, once again, too much too soon on a console that was doomed to fail before it even hit the market... lol.
 
Davros said:
What type of bumpmapping?
Click to expand...

Normal mapping. Not standard though. Some weird hemispherical coordinate system that uses 2 channels( red , green) for the normal map texture. To make matters more peculiar the way it shades the normal map on the surface is different, basically the results are per the entire face of polygon( so akin to flat shading, no interpolation one face to another). Since it has no multi texture hardware you either blend on top of the base texture or the base texture is the normal map and you blend the diffuse texture on top. Results are very good under certain conditions.

bump03.gif
 
Last edited:
DavidGraham said:
Click to expand...
Great, but he didn't mention the more than double render resolution, or that CD's have less than half the read rate, worse access times and 30+ percent less storage than bog standard GD-Roms.

Otherwise a great peice, but given how monumental an achievement this software is, I do think these basic points should be pointed out.
 
This guy wants to give out a few more review copies, then if it gets into public hands and rockstar come after him he can just say "must have been leaked by a reviewer"
 
You must log in or register to reply here.
Back
Top