Memory Capabilities

[anothrguitarist]

About a month ago, I made a custom version of Pongcast for a Christmas present. I put a few photos in the game as well as a few different style balls, which can be rotated throughout play. However, I ran into a problem that I didn't expect. With only three photos, I was pushing the limit of the hardware's memory. Admittedly, I was using an emulator to test the game when I ran into these problems, but it was discouraging. I don't exactly understand why huge games can be played -- Soul Calibur, Sonic, Shenmue -- without running into the same problems.

What is the number of images that can be loaded into memory (assume that they are full screen)? Also, what can I do to work around this problem (I tried loading the images when they were needed, instead at the beginning of the game, but this caused too much slow-down)?

A few other notes:
- I use the romdisk feature
- I use pvr for loading images and blitting

[BlueCrab]

If you're just loading stuff into PVR memory and forgetting about it, you only get about enough space for 2 1024x1024 textures in the PVR's memory. Each of those textures takes up about 2MB, and KOS uses about 4 MB of the PVR's memory for internal buffers and such.

In order to do more interesting things, you'll generally have to switch out textures on-the-fly.

[GyroVorbis]

Games like Shenmue and Soul Calibur use hardware texture compression. I believe it's either 7:1 or 8:1. I haven't used it myself, but I have spoken to plenty of people who have. I forgot the limitations on it (sheets have to be square, maybe)?

If flawless texture quality isn't a must-have, I would look into that. And yeah, you can't really use the "I'll have every texture that I ever use sitting in VRAM" approach.

edit: btw, you can calculate what your texture is using based on image_w * image_h * 2. I actually keep track of this in-game, so that I can check how much I'm using at any point during run-time.

[anothrguitarist]

Thanks for the replies. Another "capabilities" question:

How large of a texture can I "switch out on the fly" without noticing slowdown?

[BlueCrab]

That will all depend on how you implement it and what the environment it runs in is. If you can run it in the background, doing everything all at once for a frame (with non-blocking DMA), you'll probably get "unlimited" switching, at the cost of quite a bit of complexity. You may, depending on what else your program is doing, be able to get away with much less complex methods and still get no slow down.

Largely its a lot of guess and test.

[BlackAura]

One weird feature of the PVR that you have to keep in mind is the deferred rendering it uses.

The PVR has three frames of video on the go at any given time. The one in the front buffer being displayed on the screen (which chews up 600KB of video memory by itself), the one being rendered into the back buffer (another 600KB gone there), and the one that you're currently sending the geometry data for. So it's displaying frame N, drawing frame N + 1, and you're submitting the data for frame N + 2.

It needs to keep a complete copy of all the display lists for frame N + 1 while it's drawing it, and a complete copy of the display lists for frame N + 2 that you're busy rendering into. That eats up another 3MB or so. I believe it's possible to decrease the size of the display lists, and to turn off lists that you're not using, but I can't remember how to do it at the moment.

If that's not enough, you need to do one (or both) of:

• Reduce VRAM usage
• Swap textures in and out of VRAM as you need them

You can reduce the VRAM required for textures using a few techniques.

If you're using mipmaps but don't need them (say, if you're doing 2D), get rid of them. Mipmaps nearly double the size of the texture.

If you can get away with it, use VQ compression. Aside from some reduction in image quality, and the fact that you need to encode the textures offline, they work just fine, although I think the textures have to be square. The reduction in image quality tends to be more noticeable for 2D sprites, but it's fine for textures used in 3D.

If you can get away with using a shared colour palette for sprites, do it. A 16-colour texture uses one quarter as much VRAM as a full-colour 16-bit texture, and a 256-colour texture uses half.

If you're doing 3D textures, you might be able to use lower texture sizes. If the textures aren't too close to the camera, you won't notice any quality reduction.

Swapping textures is trickier, because of the deferred rendering approach. On something like the PS2, you can just copy textures over when you need them, overwrite them immediately as you're done with them, and there's plenty of bandwidth to copy lots of textures. On the Dreamcast, all the textures needed for the entire scene need to be in VRAM at once.

Not only that, but while you're drawing frame N + 2, the PVR is still rendering frame N + 1. That means it needs all the textures for the previous frame, not the one you're drawing at the moment. You have to wait until it's finished with them before you can replace them.

The simplest approach, which would limit you to 2MB of textures per frame, is to just have two separate sets of textures, and alternate between them. It'd work, and there'd be plenty of time between frames to replace all the textures. For 3D, 2MB of textures is probably not too bad, but it might not be an option for 2D sprites.

It's also possible to just make sure you keep textures in VRAM for one frame longer than you need them. That limits you to 4MB of textures between two frames, which should be fine in most cases, but you'd have the be more careful about how you allocate texture memory.

If even that's not enough, you'd have to do something tricky. Maybe queue up all the texture changes, wait until the PVR is ready for the next frame, and then DMA copy them all across in one go before it starts drawing anything. That'd be enough for 4MB of unique textures per frame, but you might not have enough time to copy all of them over without causing the framerate to drop.

Any of those approaches would require you to keep another copy of the textures in main memory. Ideally, you don't want to do that either, because there's not really a lot of that to work with either.

None of that may be necessary - if you have 8MB of textures, but each level in your game only uses 3MB of textures, just load the right textures into VRAM, and leave the rest where they are.

All that said, I think you're more likely to be running out of main memory. The romdisk has to be loaded into main memory along with the program, so any memory it uses is lost to you. Moving your files onto the CD would fix that problem, although it'd obviously take longer to load.

[anothrguitarist]

You guys are awesome. With this info, I think I might be able to tackle the memory issues. Otherwise, I would have been SOL.