Loading High-Resolution Backgrounds Efficiently

For questions about using Classic.

Post » Wed Mar 24, 2010 7:50 pm

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.
B
2
S
1
G
5
Posts: 50
Reputation: 1,500

Post » Wed Mar 24, 2010 10:00 pm

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.
B
4
S
1
G
4
Posts: 36
Reputation: 1,649

Post » Wed Mar 24, 2010 10:02 pm

Note: Most people don't have mid range graphics cards, they have integrated low end stuff.
B
2
S
2
G
2
Posts: 372
Reputation: 1,794

Post » Wed Mar 24, 2010 11:11 pm

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.
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,600

Post » Thu Mar 25, 2010 2:29 am

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.
B
2
S
1
G
5
Posts: 50
Reputation: 1,500

Post » Thu Mar 25, 2010 9:37 am

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.
B
4
S
1
G
4
Posts: 36
Reputation: 1,649

Post » Thu Mar 25, 2010 9:51 am

[quote="chaosmaster":2904vvvx]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.[/quote:2904vvvx]

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.
B
2
S
2
G
4
Posts: 156
Reputation: 1,762

Post » Thu Mar 25, 2010 10:14 am

[quote="6Fix":3fp9kt2j][quote="chaosmaster":3fp9kt2j]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.[/quote:3fp9kt2j]

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.[/quote:3fp9kt2j]
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.
Image
B
23
S
8
G
10
Posts: 1,820
Reputation: 8,242

Post » Thu Mar 25, 2010 10:53 am

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.
B
16
S
8
G
4
Posts: 136
Reputation: 3,144

Post » Thu Mar 25, 2010 5:09 pm

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.
B
2
S
1
G
5
Posts: 50
Reputation: 1,500

PreviousNext

Return to Help & Support using Construct Classic

Who is online

Users browsing this forum: No registered users and 2 guests