Loading High-Resolution Backgrounds Efficiently

from my experience you can pretty much use all your card ram.

as a fast guess around 112(128), 56(64) or something like that.

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.

This is the technique I've used before (but not yet with Construct) so I am interested to hear if non-global objects are dumped from memory or not. I would imagine they are.

> 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.

>

This is the technique I've used before (but not yet with Construct) so I am interested to hear if non-global objects are dumped from memory or not. I would imagine they are.

Under Application/Runtime Properties you specify wether to load textures per layout or on application start. This option ("Load Textures") is explained with: "Specify when object textures are loaded in to VRAM".

Unless this option lacks functionality one would assume that it does exactly what you are asking, when set to "per layout". It would not make much sense, if they are loaded per layout but kept there when loading another layout. And tests I made show that VRAM is cleaned when switching between layouts. At least with the .62 version I'm still using.

You can define whether to load textures on application startup or on layout load globally in the application properties and also change it individually for each layout in their properties. You can also load and unload layout textures to memory via events. In other words, controlling the texture load should be quite easily doable.

OK, could I, in order to transition between layouts smoothly without having to load textures each time, load the textures for the NEXT layout while the player is playing the first layout? So technically, the textures for two layouts would always be loaded at any time. Would loading the textures for the next layout while one layout is running cause a performance hit?

I'm going to test this out sometime soon, could be a promising method of doing things.

What if you broke up your super large background into say 4 layouts ( if it were a big square). Then jump to the next one when you hit the border.

I am saying this with out testing and guessing that Textures only use VRam only on the current one\. er.. Right?

Well each background is one layout, basically, at 1280x720 resolution. There's no scrolling or anything (well actually there is, but only in special scenes and I'll load the textures for these manually thus avoiding the problem). I can load each layout fine, it's just loading LOTS of layouts at once that makes the VRAM huge. Without loading multiple layouts in one go, there is a huge pause as you transition between layouts and the program loads the texture.

I've tried making it load the textures for the next layout while the player is still on a previous one, but loading the textures at any point causes a pause; there no way to slowly or 'subtly' load in layout textures in the background.

By cutting up brackgrounds and minimising wasted forground space, I should be able to load each screen in at around 10mb of VRAM. This means I should safely be able to load up to six layouts at a time, and have them transition smoothly, without overstepping the ~60mb VRAM usage required for working with rubbish graphics cards. I'll design the game's environment around this limit; I'll add doors or some such that the player has to move through, then slyly load/dump the neccessary textures as the screen changes, eliminating the noticable pause for loading.

I havn't tested this fully yet; I need to try loading 6 full backgrounds and layout object in one go and see if the VRAM stays at a reasonable level. If not, I'll have to drop the load to 5, and so on 'til it work. It's a pain, and a compromise, but I think I can make it work.

You could also make them 1/4 the size (1/2 the width + 1/2 the height = 1/4 the size) and upscale them. That happens all the time in games.

You could also make them 1/4 the size (1/2 the width + 1/2 the height = 1/4 the size) and upscale them. That happens all the time in games.

Wut?

Like what games, care to name them?

Im sorry but you cant scale a high rez image up and expect decent results. Regardless of interpolation type, there is data loss.

http://en.wikipedia.org/wiki/Image_scaling

Rule of thumb is you can scale an image down, and still have good results, but not up.

Good point. A lot of game special effects (in 3D games especially) use lower resolution images then scale up, but it probably wouldn't work well for static images. He could still try it though and see.

I selectively scale my graphics to fit within the ram I am aiming for. I will never reduce something to 50%, because that's just too low and results in ugly visuals.

However, reducing by 10% or so here and there, is much more difficult to notice and adds up.

[quote:1jonkr52]Like what games, care to name them?

Virtually every 3D game on consoles and PC reduce and then stretch their textures constantly. Level of detail, fitting into lower specs and other reasons. It's required to fit a wide range of specs, as well as fitting withing the lower ram the consoles have vs. PC.

Well that's 3d tho. So his only options are to slice one image up, or to piecemeal several objects together, IE tree here, rock there, cloud up there, etc.

That may actually be better in some cases, given you can use things like a gradient, or tiled background for larger portions that don't have a lot of detail.

For instance if you wanted a starfield you would quickly run out of ram if you loaded a huge image, or cut up equivalent, but you could reduce that to a fraction if you just make the background a dark color and placed stars etc. as sprites. And that is essentially what 3d does.

Well really there is a lot of 2D games that use it as well. Resizing a rock for example, to add variety instead of having them all the same size, without having to draw another one.