Loading High-Resolution Backgrounds Efficiently

Hi folks, I'm wondering what the most time/memory efficient way of loading a big high-res image into Construct is. My game runs at 1280x720 resolution, so the backgrounds are that size per screen. However, loading giant 1280x720 textures into a backdrop object is clearly inneficient, and ends up slowing Construct down a fair bit.

I know that Construct prefers to work with power of two squared textures; would I be better off cutting up each backdrop into a sequence of power-of-two tiles, say 256x256, and importing them as seperate objects? Or, would I be better exporting the background image as one oversized power-of-two image (in this case, 1296x1296)?

Also, is any particular object best suited to loading backdrops like this? Backdrop, Tiled Backdrop, Sprite, do these add different strains on processing? Currently I've been using Tiled Backdrop for all my static backgrounds. Any help or ideas would be appreciated,

Cheers, Tom

would I be better off cutting up each backdrop into a sequence of power-of-two tiles, say 256x256, and importing them as seperate objects? Or, would I be better exporting the background image as one oversized power-of-two image (in this case, 1296x1296)?

first is preferable

besides there's no need in loading your picture slices singly. Just load them as frames of the first slice. that'll simplify your work in editor window.

PS. Don't forget to set animation speed to 0 though

Cutting up the texture would probably be best, like nowon said.

Or, would I be better exporting the background image as one oversized power-of-two image (in this case, 1296x1296)?

I dont think 1296x1296 is a power of 2. The next up would be 2048. http://en.wikipedia.org/wiki/Power_of_t ... ers_of_two

All images take up as much VRAM as the smallest power of 2 size they fit in. Each of your 1280x720 images are acting like 2048x2048 with most of that being empty space. Bad idea.

Also, what are these Backdrop objects? There's only Sprite and Tiled Background. Tiled Background is mainly made to save some time while rendering pow2 tiled images.

The most efficient way is to avoid loading big images like that. Are you sure you can't just make the background out of smaller instanced objects?

Or, would I be better exporting the background image as one oversized power-of-two image (in this case, 1296x1296)?

No, don't do this; some (most?) newer graphics cards can handle textures that aren't square. Whenever possible, try to make square power of two textures, but if you absolutely need a big rectangular image, just keep the texture as small as possible, and try to keep height and width the smallest power of two possible. Don't add blank space just for the hell of it; You lose performance for both the old and newer graphics cards that way.

would I be better off cutting up each backdrop into a sequence of power-of-two tiles, say 256x256, and importing them as seperate objects?

You save some VRAM this way, especially if your texture is a really irregular shape.

But like I said, always try to use small objects to build the background, if possible.

All images take up as much VRAM as the smallest power of 2 size they fit in. Each of your 1280x720 images are acting like 2048x2048 with most of that being empty space. Bad idea.

Wouldn't that be 2048x1024?

> All images take up as much VRAM as the smallest power of 2 size they fit in. Each of your 1280x720 images are acting like 2048x2048 with most of that being empty space. Bad idea.

>

>

Wouldn't that be 2048x1024?

That depends on the GPU, but for most computers these days, I'd say yes.

I think all graphics cards can support 1024x1024 textures, so for greater convenience you can cut textures in to chunks of that size. If you have edges to cover, you can cut them in to say 256x256 squares and they will use less VRAM than another 1024x1024 texture. Basically, the rule of thumb is to assume your texture is placed on the smallest square power-of-two size surface that can entirely fit your image (so 1024x50 size textures is probably a bad idea - it could use 1024x1024 size surface and waste VRAM - but some modern cards might be able to use rectangular power of two and place it on 1024x64).

But as Davioware said, you'll very quickly run out of VRAM this way. If you want low-end hardware to be able to play your game, you need to be thinking about 64mb cards, of which only 32mb may be available for your game to use (the rest used by OS, other apps etc). It's better to use tiling where you can, and add variations with scaled, rotated sprites for decoration. You can still get an interesting appearance that way, and with a much lower VRAM usage.

The tiled background object with a power-of-two size texture is a very efficient way to tile an image (it draws as fast as a single texture no matter how much you tile it). You lose that if it's not using a power-of-two size texture though.

The tiled background object with a power-of-two size texture is a very efficient way to tile an image (it draws as fast as a single texture no matter how much you tile it). You lose that if it's not using a power-of-two size texture though.

When using the Tiled Background's "Power-of-two Only" abilities, it counts 128x64 as pow2, but is it still getting the speed boost when doing rectangle pow2?

I think that's dependent on whether your graphics card supports rectangular power-of-two textures - it might not work on someone else's video card that doesn't support it.

Ok, thanks folks, it would seem that with my current backgrounds my best bet would be to chop em up into 1024 x 1024 to save time and VRAM. I understand that tiling a backdrop and adding objects to it would be the most efficient way of doing things, but that wouldn't really work with the art style we're using - we're using high-definition, hand-drawn backdrops and sprites.

I'd already pretty much ruled out this running on really low-end hardware (~64mb cards), but would like it to perform comfortably on mid-range cards. I'd prefer it if people didn't require Crysis-eating rigs to run our game. What I could do is chop the foreground up into individual objects - saves memory rendering empty space - and then chop the background up into the most efficient power-of-two segments possible.

I'm going to try out a few different methods with my current backgrounds and see what the most efficient method it. I'll also have a word with our artist about making the actual background a tileable power-of-two texture wherever possible. Am I right in thinking that tiling a 1024 x 1024 image is considerably more efficient that cutting up a larger image into 1024 x 1024 pieces? I'll try a few techniques out, anyway, and try to avoid rectangular textures wherever possible.

made some comparison and came to the conclusion that the difference between one

tiledbackground to levelsize or using different pictures of the same size is mostly vram, not fps.

i would cut your old bgs into 1024x1024, make a fast testlevel plus foreground and sprites to see

if it fits into your mid-range specs.

when testing textures above 1024� i got small slowdowns or loading with current mid-range hardware.

Note: Most people don't have mid range graphics cards, they have integrated low end stuff.

Your game could end up using more VRAM than Crysis, and that's not a joke. 3D games are very efficient with textures - they can recycle the same textures over and over and over, and due to 3D models, lighting, shaders etc. they can keep it looking interesting. One tilable wood texture could be used on a log cabin, a forest of trees, a floor somewhere, a handle, tables, chairs, and so on.

Contrast that to a game composed entirely out of unique 1024x1024 textures, where there's no texture re-use. Your game is effectively a single, gigantic texture, which graphics cards don't tend to have enough memory for. On a card with 64mb VRAM, which you should support for integrated or older graphics hardware, you can fit sixteen 1024x1024 textures in memory (one is 4mb). And that's assuming it was empty to begin with, and it's not.

I'm not sure Crysis supports such low-end cards, but in theory a 3D game could just switch to ultra-low-res-crappy mode, using 256x256 textures for the 3D models. Then they can fit in 256 textures, which is probably enough for a small level. Note you can fit thousands of vertices of a 3D model in 1mb, enough for a lot of world or several models, so 3D stuff gets away with that much easier. Will you have a low-resolution version? Graphics cards don't have much memory since 3D games don't need it, so designing your game with such a lot of texturing is probably a bad idea.

It's certainly an interesting conundrum. Is this maybe one reason why we see so few high-res 2D games on modern hardware? I always thought this was down to 2D simply being out of fashion, but it seems as though video hardware has a natural dislike for large 2D images, as opposed to complex 3D models, which they seem to handle fairly easily.

I've been playing around, and loading the textures, one for forground and one for background, straight in as one object takes up 16mb VRAM. Chopping these up into 512x512 tiles and tiling them drops the count to 12mb. Cutting them up further into 256x256 tiles and minimising empty space drops it to 11.25mb, but the difference seems negligable at this point.

For this project I've always intended to allow different graphics settings so most people can at least play the game, however, this VRAM issue is quite a large one. I intended for low graphics settings to disable certain visual effects to improve performance; however, Construct seems to be able to render plenty of effect with little performance drain. Disabling these effects will compensate for cards with old pixel shader versions, but won't affect VRAM usage much at all.

With 3D games, as you say, they can just whack the resolution and texture-quality right down to allow them to run on older machines. However, they aren't designed with this setting in mind; the games are designed in high-resolution, then simply scaled down if needed. They are effectively designed with mid-high range graphics in mind. I can't do this with a 2D game; artwork is artwork, it'll take up the same space regardless of how crappy it looks, and scaling it down to fit lower resolutions won't work. Thus, I have to design the game with low-range graphics in mind, and then scale it UP if someone has a decent rig.

Taking into account low-range cards at around 64mb, what's the largest amount of VRAM I can afford to use? About 32mb? Does VRAM refresh for individual layouts? If so, with backgrounds using ~12mb per screen, I could get away with using high-res textures providing I use individual layouts for every screen of the game. Doing so would be a logisitcal pain in the ass, but should keep the VRAM of each layout down to a usable amount.