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:
You must log in or register to reply here.
Back
Top