VRAM & Pow 2 Textures

So I've been reading that instead of importing giant images for a level, you should cut them into small pow 2 size pieces and put them together - to save VRAM.

Well I used Construct's "Import Tiles" to cut up a giant image into small 256x256 frames, then copy/pasted it and used the "Start Frame" feature to select which pieces to use.

I thought this would save me a ton of VRAM, but it's exactly the same as importing the whole image as one piece.

Have I misinterpreted this technique?

Yeah thats more if you you have a texture size that's like 32x64. Some graphics cards will pad the texture to make it 64x64. Using two 32x32 textures would save VRAM.

Ah so it's only to prevent padding..Well damn, I guess I'll have to stick to ROJOhound's VRAM memory management technique. I fear my finished map will easily be over 100mb

If you have a huge graphic, for instance for a background, cutting it up into smaller pieces and piecing it together again in Construct won't save you VRam, because you're basically using the same large image, albeit in smaller pieces.

The idea is to look at your large image, and work out if you can make it up out of smaller, repetitive graphics.

For instance, you could use a tiled background to give yourself your base colour, and then place several smaller graphics over that to make up the image that you want.

Could you post a picture of the large graphic that you want to display?

Krush.

I'm having the same problem with my game, I'm using blocks of 800x800 px to load my levels (I thought that would save vram too... :/ also it's easier to paint). There is something else I can do to increase the game's performance? Maybe there is some way to only load the images that are close to the camera...

It's more useful to chop a big image into smaller chunks when there are big spaces with nothing relevant, for example cloud-less sky between tall towers/mountains, following this example you chop the towers and put them back together on the editor, and the sky color is made by setting it on the scene parameters, or adding a gradient object.

There's more than saving vram. Graphic cards support textures only up to a specific size. Modern cards may support 8192x8192, older may only support 512x512 or even only 256x256.

So, when you have a huge image, let's say 8192x4096, you should cut it into smaller pieces, if you want to support players with older gfx cards.

Also, when using pixel shaders in your game, you could get in trouble, too. Only ps3 (and up) is guaranteed to work on 4k textures. (This could be misleading, let me say it this way: If a card supports ps3, it also has to support 4k textures)

But you could also still save some vram. Let's take the example 800x800. It's just a matter of how you split the image. See the graphic below:

Just a small question. Does enlarging an image in Construct increase VRAM usage? Or does it use the same VRAM as it uses when it is in its normal size?

I'd like to STRESS that 2D games in general are NOT made out of a single huge picture, as 3D games are not a single hulking 3D model.

Please. Research.

[quote:22f5mwcb]Just a small question. Does enlarging an image in Construct increase VRAM usage? Or does it use the same VRAM as it uses when it is in its normal size?

VRAM usage will be the same.

I see. thanks. That small question had me puzzled why my game was sometimes slow.

I'd like to STRESS that 2D games in general are NOT made out of a single huge picture, as 3D games are not a single hulking 3D model.

Please. Research.

Er. Yeah, but when you've got 200+ tiles, a massive interconnecting world, and a drag and drop level editor, you tend to use other programs to build your areas - then import them as images

Tulamide - thanks for the image! Demonstrates the problem very well.

Just to clarify, some textures can be split up to save VRAM in rare circumstances - if you have a 32x4096 image, for example, some graphics cards might place that on a 4096x4096 surface in memory, wasting a large amount of VRAM. In that case, splitting it up in to smaller chunks might save VRAM (it depends on the design of the graphics card though, I think). However Tulamide's example shows how it is easy to split up a texture and not save any VRAM at all.

It's also a good point that games are not typically designed with large, pre-rendered images. If you have 100mb of textures for a large level this may not even fit in the memory of a 128mb graphics card (due to operating system/other stuff stored there) and instantly you have a huge requirement to have a 256mb card to play the game! Even most commercial 3D games don't use that much memory - they use the principle of a smaller set of textures which are tiled and repeated as well, but with a lot of processing on top. So you should definitely prefer building your levels out of tiled backgrounds and sprite elements rather than pre-rendering - graphics cards aren't designed for huge prerendered images.

What you should probably do is make your own level editor to make the process easier, then have the level editor export an array with tile's locations that can be loaded by the game.

As a bonus, you can release the level editor with the game and people can make their own levels!

If you are aiming to make a high qaulity 2D game, I don't think you should be scared of 100mb of VRAM. Steam's survey [>] is probably an okay way to see what a lot of PC gamers are using, only about 7% have 128mb or less VRAM. So unless you're making one of those mythical games that everyone can run (or a game for non-gamers), I think you'll be fine using 100mb or so of VRAM.