Could Dreamcast et al handle this/that game/effect? *DC tech retrospective *spawn
- Thread starter xaeroxcore
- Start date
-
- Tags
- sega
I'm sick right now, so I'm not really feeling like answering the VF4 questions right now, but on GTA3DC...
All those 32-pixel wide horizontal lines stuck to models are because they're using degenerates to stitch together strips. Ideally, you wouldn't use degenerates, because on the PVR they take about the same processing time as visible polygons with the same bounding box, but as a bandaid, you can enable small triangle culling. IIRC, you also need to make sure the small culling size register (on KallistiOS, it's the #define "PVR_OBJECT_CLIP") is greater than zero. It's a floating point value, so 0.5f or 1.0f would work. You can't use PVR_SET to set it because the macro casts it to an int, so PVR_SET(PVR_OBJECT_CLIP, 1.0f) would set it incorrectly to 0x0000001 instead of 0x3f800000. Small culling is enabled on all culling modes besides completely disabled, so it still works for CW or CCW if you set the register.
I will address this quick:
All those 32-pixel wide horizontal lines stuck to models are because they're using degenerates to stitch together strips. Ideally, you wouldn't use degenerates, because on the PVR they take about the same processing time as visible polygons with the same bounding box, but as a bandaid, you can enable small triangle culling. IIRC, you also need to make sure the small culling size register (on KallistiOS, it's the #define "PVR_OBJECT_CLIP") is greater than zero. It's a floating point value, so 0.5f or 1.0f would work. You can't use PVR_SET to set it because the macro casts it to an int, so PVR_SET(PVR_OBJECT_CLIP, 1.0f) would set it incorrectly to 0x0000001 instead of 0x3f800000. Small culling is enabled on all culling modes besides completely disabled, so it still works for CW or CCW if you set the register.
I will address this quick:
Textures won't have any noticeable effect on main RAM usage. The PVR does not support swapping textures in and out of video RAM while rendering a scene. Everything has to be loaded into video at the start of rendering, and you can't touch them until rendering completes. So there's no reason for textures to be using main RAM. The only time it would make sense is for a 2D game where you load additional frames on the fly.
What do you mean? That all the textures of the whole GTA3 world will have to be loaded into the RAM at once? Also what about the rest aspects of the game?
No, you don't have to have everything loaded at once. Look at Shenmue, Jet * Radio, or Soul Reaver. I'm saying textures don't add to main RAM pressure on the DC, because there's little reason to store them there.
PS2 does this to get around its tiny amount of video RAM:
Begin frame
Copy texture from main RAM to video RAM
Draw polygons using texture
Copy another texture from main RAM to video RAM
Draw polygons using other texture
Copy yet another texture from main RAM to video RAM
Draw polygons using other other texture
End frame
On the DC, you can't load in textures midframe like this. You have to have every texture used by a frame loaded into video RAM before you render the frame. There's no point in keeping a copy of your textures in main RAM long term, because the PVR can't use it. You can still unload textures from video RAM that aren't being used, and load new ones as you travel around just fine. On the PS2, textures are counted as using up main RAM, because that's where they live long term, and are only in video RAM for a short period as they're being used.
I guess point I'm really trying to get at is that you can't compare 16MB of main RAM on the DC to 32MB on the PS2, because the PS2 has to burn a lot of it's main RAM storing textures. The DC pretty much has to store it's textures in video RAM, plus it has more compact textures with it's texture compression, so it effectively has more main RAM than the numbers suggest.
davis.anthony
Veteran
That's not some cheat that developers come up over the years, that's how PS2 was designed to work, so it's not really a 'work around'
But, looking at GTA3 I don't think PS2 is using that much main RAM for textures. If at all.
I seem to remember that allocating 1MB of PS2s EDRAM to textures was quite popular.
So how much main RAM would you need to use to cache that? 4MB?
If anything, having to keep more in VRAM on DC is wasteful.
There's more to graphics than just textures, DC has a very limited amount of RAM and a slow streaming speed, so keeping things in main RAM as a buffer to make up for lack of streaming speed would likely need to take place.
Do you have a source for that? Any actual numbers?
Last edited:
That's just a turn of phrase. Everyone here appreciates PS2 was designed different and operates differently.
sheathx013
Newcomer
Maybe I'm doing the math wrong, but I do not misremember optimal Dreamcast load times being 4-8seconds MAX for an entire level load. Unoptimized obviously took longer (looking at you Soldier of Fortune and Half Life). But the assumed worst case scenario of 1MegaByte per second transfer speed from the GD-ROM, divided by 30 frames per second is 34.13 KiloBytes per Frame or 34949.12 bytes per Frame. Last I checked a standard texture mapped polygon weighs 40bytes each. So 34949.12 / 40 equals 873.73 polygons per frame. That's 26,211 polys per second that can stream from the unoptimal GD-ROM.
Is it being asserted that the PS2, which has typical load times of over 12 seconds, can and has effectively streamed over 130,000 texture mapped polygons per second from it's DVD/CD-rom Drive (25k * 5)? Is it also being claimed that without this amount of data being streamed, consistently every frame, that GTAIII cannot run at the level of the PS2 game?
davis.anthony
Veteran
We have one of the developers stating that streaming was one of the hardest problems they faced technically.
And if they struggled with PS2's drive that can transfer just over 5MB/s, then it's pretty easy to conclude they would really struggle with Dreamcast's streaming speeds.
And with Dreamcast having half the system RAM it would arguably be more dependent on streaming than PS2 is.
Thanks, I think I must have been confused with some of the old stuff I read about PVRTC by SimonF (maybe something like 20 years ago?), which had both two and four bpp modes but was actually different to VQ on the DC.
I'd got it into my head that VQ didn't work with alpha, like some forms of S3TC, so thanks for correcting me on that.
Regarding VQ compressed8bpp and 4bpp, are these palletised / CLUT textures you're talking about? If so, that would seem a potential win if it had ever been available for use in 2D fighting games. A single large texture (or a few larger textures) containing all the animation frames from a character, might work pretty well with block compression as amongst all the frames in the texture there would have been a lot of repeated / flipped / mirrored blocks.
Was anything like this ever tried to your knowledge?
sheathx013
Newcomer
Unless somebody ripped the city models from GTA III and posted a count somewhere and I missed it, I think it is generally assumed that GTA III is not exactly on the higher detail level polygon wise. The Dreamcast's conservative peak of 3.5 million polygons per second at 30 frames per second is 116,000 polygons per frame. At 40 bytes per polygon 116k polys is 4.45 Megabytes of Video RAM, or a little over half of the 8MB attached to the PoverVR 2 DC. I'm failing to see how GTA III is going to need more than that.
With two full height 32bpp 512 x 448 buffers and 24 bit z + 8 bit stencil, PS2 would have ~ 2.65 MB of it's vram used, leaving about 1.35MB for textures to be used for whatever you're streaming in from to be drawing at the moment.
But on PS2, as you're often changing the textures in vram as your draw different things, you're frequently DMAing (or however they do it) new texture data in. If this isn't in memory in time it causes VU1 to stall and the GS to idle.
Texture related stalls were listed by Sony in a 2003 developer presentation as being one of the biggest causes of lost rendering performance. They recommended double buffering texture memory in VRAM, but this means you're halving the already small amount of texture memory you can use for the currently rendered geometry.
On top of this, if you want to keep a previous frame around for blending in the case of something like motion blur, that's going to leave you with only a few hundred KB, so you're probably going to have to compromise somewhere.
It appears to have been a lot of work to properly manage textures on PS2, and even then you'd probably tend towards lower resolution and/or very low colour textures. On the plus side, PS2's small amount of vram was very fast, and good for drawing lots of polygons and doing a ton of transparency. This kind of performance is what Sony were targetting though.
The DC is designed to keep all the textures it needs for a frame in vram, just as PS2 is designed to keep all the textures it needs for a frame in main ram.
On DC, the vram bus and the main ram bus are the same speed so it's not like you're using up higher bandwidth ram.
On the plus side, as textures are already in GPU addressable memory you'll never stall waiting for a transfer mid frame, you wouldn't be double buffering texture memory, and you won't be moving texture data you might not need from main ram to vram on the off chance it's needed.
Keeping textures in GPU addressable ram is, and was, even back in the late 90's, the normal way of doing things. Still is, in consoles, high end devices and also power sensitive mobile devices like the iphone. By PS3 Sony were storing textures in vram just like the DC did.
Streaming in a game like GTA3 is not just geometry, it also includes textures, sound, animation, and maybe some NPC scripting stuff. On top of that, a lot of time is potentially lost to the optical drive head moving locations, making access time very important. Access time of the drives is probably as or more important than optimal read speeds.
And on top of that, in terms of streaming geometry it could maybe be compressed, and you could build some stuff like vertex normals after you've loaded the data off disk, so there's no single "polygons per second" streaming speed for the consoles.
If I had to take a guess, I'd say most of the time GTA3 on PS2 probably streaming in the hundreds of KB a second when moving round, with driving very fast being most demanding. But it's access patterns that are likely to be one of if not the biggest factor.
On DC, VQ textures would help as even if further uncompressed they're likely to be smaller than even lossless compressed 4bpp CLUTs (although some clever methods for doing VQ like compression on PS2 did emerge as being at least possible later on in its life).
It'd be cool if PCSX2 had some logging to look at what the virtual PS2 is doing. then we could just fire up GTA3 and see exactly what it's doing.
sheathx013
Newcomer
Well, next best thing I have is OPL with the Network Adapter from my HTPC. GTA III loads way faster than from the DVD drive, but the speeds are 10-13MegaBITs per second during the load screens, and 0.8-2MegaBITs per second in game with occasional spikes at around 5-5.5Mbits per second. That's 100-700 Kilobytes per second streaming over the network, according to Task Manager (see attached).
It's weird how the PS2 works. Basically they keep 1.3 MB to 1.5 MB CACHE open in vram for textures that will be used for the frame. These are being sent from main ram. PS2 has 3 paths to send these textures of I remember right. To some extent they have to be synchronized or something will stall( geometry /texture). Looking at some charts a few years ago they claimed the ps2 actually has better bandwidth throughput in submitting 16 bit/24bit color textures than its usual 4 bit/8bit color it used( it's a big difference). Problem is vram is too small regardless to take advantage so they stick to 8bit/4bit textures. That's a lot of times they broke bigger textures into smaller textures/tiles.
I don't pretend to know how much they dedicated in main ram for textures but if 1.5mb is reserved in vram to hold just what's visible it's probably more than we think for the rest of the scene.
For gta3 (dc)if anything they are trying to get rid of those in-between buffers and make textures native so they can just shove it in the vram as they are loaded along with the models/ animation ( which go to the main ram).
Last edited:
davis.anthony
Veteran
Yep, and that's why it's so interesting.
Yep.
I can't remember if PS2 can DMA straight to EDRAM from it's DVD drive but I'm sure it could via path 3.
Correct, there was a lot of fuss made about path 3 back in the day.
Managing all the paths was essential to getting good performance from PS2.
It didn't actually 'stall', only a single path can run at a time, or otherwise data from different paths would be interleaved and could/would cock up the rendering. So when a path requests access when another path is already running, the GIF remembers the pending request and will activate the path when the current one has finished transferring data.
The paths are ordered by priority, with path 1 being the highest and path 3 being the lowest.
Yep, this was in Sony's presentation about their performance analyser.
If you search back to the early 2000's on this forum you'll see various developers saying that PS2 was never really VRAM limited, it was limited by VU1 and that adding more VRAM wouldn't have really done much - This was backed up by Sony's performance analyser data iirc.
That's more to do with the small memory in VU1 rather than the actual VRAM amount, developers were forced to break the textures (and everything else that VU1 handled like models) down in to smaller chunks so they fit in to VU1's 16 KB memory - (Which is only enough for a single 32-bit 64x64 texture)
It's how much would they need to keep GS fed with rendering data, if they worked on a 4x buffer, that would give 6MB of system RAM used purely as a texture buffer, leaving 26MB of main RAM for everything else (I pulled these numbers out my arse)
I would love to see streaming stats for PS2 and wish there was a way to get that data.
On a random note, imagine being a young developer, or a PC developer looking to work on PS2 and Sony flash this slide up!
I would love to have been there to have seen their faces and reaction, I imagine some people turned pale
sheathx013
Newcomer
Thinking further about the network adapter streaming speeds and the PC version, I confirmed only Audio (and tiny data files) is on the PC Disk 2. I know of no way to tell what hard drive activity is happening in game on the PC version, and I have no way to tell what is streaming from the PS2 DVD ISO through OPL and the Network Adapter, aside from the fact that the transfer speed is less than 1/10th that of the actual load screens.
So, any other data streaming would have to be on the Hard Drive for the PC version, which had an install size of only 522MB. There is also a Kalisto version of the PS2 game that can fit on a 700MB CDR, by eliminating half of the radio stations.
The PS2 DVD's largest files are in its Audio folder, but also these .IMG files in its Models folder. Surely somebody has done an analysis on what is in these files. But I would not be surprised if there is redundant data in each .IMG, probably meant to speed up streaming from the DVD ROM.
So, any other data streaming would have to be on the Hard Drive for the PC version, which had an install size of only 522MB. There is also a Kalisto version of the PS2 game that can fit on a 700MB CDR, by eliminating half of the radio stations.
The PS2 DVD's largest files are in its Audio folder, but also these .IMG files in its Models folder. Surely somebody has done an analysis on what is in these files. But I would not be surprised if there is redundant data in each .IMG, probably meant to speed up streaming from the DVD ROM.
