Question about VRAM requirements for a casual game

[Amirai]

I've read that casual games should be under 64 MB of VRAM. However, I don't really know how exact a limit that is, considering as I hear there are other things that need to use the VRAM at the same time, like the system.

I apologize for my ignorance, but is all 64 MB available to use in full-screen mode? What about windowed mode, does Windows have some sort of way of dealing with having two applications competing for VRAM at the same time?

[jpoag]

I've read that casual games should be under 64 MB of VRAM. However, I don't really know how exact a limit that is, considering as I hear there are other things that need to use the VRAM at the same time, like the system.

I apologize for my ignorance, but is all 64 MB available to use in full-screen mode? What about windowed mode, does Windows have some sort of way of dealing with having two applications competing for VRAM at the same time?

The VRAM is either the RAM on the GFX card or a section of system memory shared/dedicated to video (usually both).

Your graphics don't all have to fit in this little section of memory (in fact, they usually don't). You get better performance if all your textures fit into this small space, but it's not a show stopper if it doesn't fit.

Modern graphics APIs (DirectX, OpenGL) manage this memory for you. A very simplistic way to think about this memory is like a holding area for images being drawn to the screen (and the screen itself). It typically works like a one-way street (with a couple exceptions).

The Graphics API will hold the texture in system memory (or in the dedicated system memory) and upload a copy to the graphics card when you want to draw an image. When the memory on the GFX gets low, the API will tell the card to delete the copies to make room for a new texture. The graphics API optimizes this process as best that it can (how often is this texture drawn? How long ago was it last drawn? etc...)

This is why texture atlases are a great way to increase performance (and reduce memory usage). Packing a lot of images onto a single texture will reduce the BUS traffic.


There are certain types of images that HAVE to reside on the GFX card. Things like the front buffer, back buffer and render targets. You can lock and read images from GFX memory, but it's usually slow. It's better to think of the GFX BUS as a one-way street.

The real kicker is that the Graphics API will manage all of this for you. You simply need to check and make sure that the surface isn't lost or use a API with managed memory pools. With the exception of Render Targets, it's been 15 years since I had to worry about surfaces getting lost or trashed.

At this day and age, you shouldn't really even worry about handling graphics routines. There are a lot of casual game engines that even manage that for you. Really, you should find an engine that let's you specify a image file to draw and gives you functions to draw it.

**************
Edit: I see you're using construct which uses DX9. DX9 has memory pool management so you should NOT have to worry about it.

You don't really have to worry about other programs fighting for memory. Fullscreen apps usually run a little faster because of reduced GDI drawing, but newer versions of windows (Vista+) use hardware accelerated drawing.

[Pogacha]

When you get exclusive mode you get all the vram (more or less), You have to remove the screen size, the double buffer, the tripple buffer (if there is one), the Z-Buffer, the stencil buffer (if there), any other render target you use and the vertexs buffers ... then the rest is for textures.

Actually depending on how you use the memory you can have more textures than what actually fit in video memory. The APIs will attempt to make a copy of the textures in ram and upload and discard the copy in the vram when needed.
The problem is when for example you use 4 textures in a scene and you only have room for 3. What usually happens is that the API (OpenGL and DirectX) will attempt to remove one and upload the needed in a frame per frame basis making the frame rate drop because a bottleneck in the AGP channel.

So you can actually have many times the ammount of textures provided you will use always less than the total memory available in a same frame.

For Simplz Zoo we pointed to 32mb of ram (that was hard to acomplish given the ammount of graphics the game has) That 32 mb was given by different stats like the ones provided by Unity, Steam and the distribution of known hardware that has this limit like some iBooks.

So basically if you organize the memory addecuatelly you can get away with 32mb or even less. Of course some other applications may be using some VRAM if it is not in Exclusive Mode.

Anyway, at this point if you are starting a development to be launch it in 6 months, 64 mb is more than fine.

Edit: jpoag was faster ...

[jpoag]

Edit: jpoag was faster ...

Hey, it's better to have two concurrent answers.


Here are some more ideas:
Texture atlases are a great way to reduce memory if Construct supports them:

Images can be any size, but textures (images on the GFX card) are usually held to a couple restraints:

Typically (and this varies from card to card) they have to be in pow2 sizes. Sometimes, they even have to be square.

What this means is that if you have an image that is 40x170, that image will need to be placed on a texture that is 128x256. (pow2) If the card requires square textures, then the image will be placed on a 256x256 texture!

That's a lot of wasted space.

A texture atlas will allow you to place multiple images onto a square pow2 texture (lots of little sprites onto one plane). This way, when the image is uploaded to a texture, it is already in the required size.

That's how an atlas will save memory.

Then, you specify different source rectangles to draw from.

[jcottier]

if you have an image that is 40x170, that image will need to be placed on a texture that is 128x256.

You mean 64x128

If the card requires square textures...

Does any computer's video cards really only support squared textures nowdays?

JC

[vjvj]

I've read that casual games should be under 64 MB of VRAM. However, I don't really know how exact a limit that is, considering as I hear there are other things that need to use the VRAM at the same time, like the system.

I apologize for my ignorance, but is all 64 MB available to use in full-screen mode? What about windowed mode, does Windows have some sort of way of dealing with having two applications competing for VRAM at the same time?

The GPU driver handles pretty much all the memory management for you.

For the most part though it doesn't really matter, since most min spec machines are using integrated graphics chips anyway, which store all textures in system memory. And any discreet GPU (with dedicated VRAM) will most likely have way more than 64MB available.

In my experience of profiling games, I don't think I've ever seen a PC game that was AGP/PCI-E bus bound. This is usually more of a problem on consoles.

There is no real exact "64MB limit" or anything; there are too many variables. Most of us just pick a particular spec or generation (like DirectX 7 or Shader Model 2.0) and roughly target the capabilities of hardware from that era

[jpoag]

You mean 64x128

Lol, I was tired. Even then, I'm pretty sure 40x170 won't exactly fit on a 64x128. ;-) It's not really what exact measurements, it's the concept.

As for square textures? I don't really know if a lot of computers still require it, probably falls in the 'once in a blue moon' category.


I second everything vjvj just said.

[Pogacha]

In my experience of profiling games, I don't think I've ever seen a PC game that was AGP/PCI-E bus bound. This is usually more of a problem on consoles.

Switch off texture compression (from main menu) on an low end graphic card in Simplz Zoo and you will see it :P



40x170 => 64 x 256!!!!!!!!!

[Amirai]

Thanks for the great replies!

[vjvj]

Switch off texture compression (from main menu) on an low end graphic card in Simplz Zoo and you will see it :P



40x170 => 64 x 256!!!!!!!!!

You bring up a good point I definitely recommend using texture compression wherever possible, especially DXT1 as almost all hardware can read DXT1 in-cache without decompression. Super fast and super small

[Jim Buck]

Sigh, now if only Sony got the memo on that for the PSP!

... almost all hardware can read DXT1 in-cache without decompression

[PoV]

Sigh, now if only Sony got the memo on that for the PSP!

!!

Noted.

[vjvj]

Sigh, now if only Sony got the memo on that for the PSP!

IIRC, PSP can texture DXT1 compressed from the cache, just not DXT3 or 5... But now you have me doubting myself, LOL. I might be remembering incorrectly.

The above is definitely the case for most PC GPUs, though.

[hippocoder]

Does any computer's video cards really only support squared textures nowdays?

Well my iPhone game doesn't use power of 2 media, but the hardware requires it. What I do is just load them onto a big square atlas texture, which makes the art path pretty easy. If you use SOIL or other game image libraries, they'll often be able to pad the texture so it is power of 2 for you at load time. Haaf's does this too if memory serves.

Modern hardware can manage non squared, but you don't have to take the risk.

[vjvj]

Well my iPhone game doesn't use power of 2 media, but the hardware requires it. What I do is just load them onto a big square atlas texture, which makes the art path pretty easy. If you use SOIL or other game image libraries, they'll often be able to pad the texture so it is power of 2 for you at load time. Haaf's does this too if memory serves.

Modern hardware can manage non squared, but you don't have to take the risk.

When James said "square" above, he meant width and height being the same dimensions, not power-of-2 "squared".

It's still recommended to use pow2 textures as much as possible, regardless, but I can't think of any hardware that requires width and height be the same.

[Applewood]

Agreed on the pow2 thing. Any 3rd party lib should deal with this and round them on on the quiet, but why risk it.

Making model textures pow2 is no hardship at all, and for all your gui buttons, icons, 2d animations etc, just put them on a larger pow2 sheet and address as rectangles anyway. It's just not a hassle, so don't increase your fail chances by not doing this.

One thing I remember of old, even on cards that don't require square, there was still sometimes an aspect ratio limit. So for example you could make a 64x256 but not a 2x512. Better to be as square as possible. Certainly don't make long/thin images just for the hell of it.

[PoV]

Yes, don't fall victim to the allure of NPOT textures (Non Power Of Two)! Several modern mobile graphics chips do support NPOT textures (PowerVR SGX, Samsung FIMG), but of all the mobile ones I've seen, they don't support NPOT mipmaps. And if you want your art to scale nicely (and inexpensively) across several resolutions, you want your mipmaps!

IIRC, PSP can texture DXT1 compressed from the cache, just not DXT3 or 5... But now you have me doubting myself, LOL. I might be remembering incorrectly.

Assuming my textures fit in the cache, I guess I'll be going with RGBA4444's then.