Is it a bad idea to have many-layered backgrounds?

SOLVED. New question, though: How do I go about making those clouds scroll infinitely? I found two solutions by searching, but it doesn't look like they can apply to what I'm trying to do.

I'm using backgrounds like this:

<img src="http://oi51.tinypic.com/2ijgmro.jpg">

for my Mario & Sonic platformer. In the original Mario World, that background is a single layer that scrolls slower than the foreground, which looks fine, but many of Sonic's backgrounds are multilayered and look much better. So I was thinking of splitting up Mario's backgrounds into layers, but would that add an unnecessary amount to the VRAM?

That background, for example, would logically split into five layers, for each set of mountains and clouds. Is that too much? Most other backgrounds look like they'd work with three or less layers, by the way, so they wouldn't all be this much.

EDIT: And another related question -- what would be an acceptable maximum VRAM each level should have, for those of you who know how large the average Mario level is? Right now it's hovering a bit below 13 mb, and the level, well... barely exists yet. It's only a handful of enemies and some obstacles, only 2500 pixels wide and 1000 tall so far.

If you use single sprites as your mountain pillars instead of a composed background you can in fact use far LESS vram and create a layered background. Steam hardware survey gives one viewpoint to what your total vram usage should probably be at worst. I prefer to leave half of the available vram to the OS and give the other half to the game. I have 128mb vram myself and my projects typically fall somewhere between 50 and 60mb of vram. A lot of people use integrated gpu solutions too which can reduce the available vram to almost ridiculously small amounts.

Figuring out the powers of two helps you reduce the memory load a lot. Shaders tend to eat vram too so it might be a clever idea to avoid too excessive use. Using a lot of layers doesn't necessarily mean that you're using a lot of resources, they just help you organize the render wall better. Using multiple layer effects will quickly turn it into a resource hog though.

Edit: fixed a typo

^ This.

It looks like there would be 5 layers used here, but you can probably get away with just using 2. Just be conscious of each object's z order. If you make the clouds auto scroll, just move the larger ones quicker and the smaller ones slower. No need to make a ton of layers just for that!

Just wanted to mention that layers themselves don't add to vram use. It's the sprites or effects on the layer that use it. You could have a hundred layers, and without anything on them, they won't increase the vram use one bit.

How exactly does the powers of two deal work? From my understanding, a 32x34 sprite uses up the same memory as 64x64, so it's better to try to squeeze it down to 32x32 to be more efficient. But if a sprite is already in-between, at, say, 64x40, and it can't be brought down to 32x32, is there any reason to expand it to 64x64? Is that any more efficient?

The power of two doesn't have to be squared. On most, if not all gfx cards a 32x34 texture will pad to 32x64.

It never gives any advantage to expand a texture up to the next power of two. But it may give you a decrease in memory usage when splitting such a texture into parts that are power of two based.

Here are two posts, one with example cap, going into detail:

http://www.scirra.com/forum/viewtopic.php?f=3&t=7578&p=58897#p58897

http://www.scirra.com/forum/viewtopic.php?f=8&t=7786#p60406

/if a sprite is already in-between, at, say, 64x40 ... is there any reason to expand it to 64x64? Is that any more efficient?

No, there's no point doing that - both ways occupy a 64x64 surface in graphics card memory and they draw at the same speed.

BTW Arima's post is really important for the OP: layers themselves don't use VRAM, only Sprites, and all instances of one object type share the same texture, so you can create more instances of an object without using VRAM either. So to answer the original question, no, many-layered backgrounds are fine, you can easily have loads and have no VRAM overhead.

Construct does create some of its own textures at runtime for processing effects and such, but there's a limit - I think a maximum of about five, so it's fixed. Nothing like one per layer.

yeah, in my demo thingy embryo, I believe I had over 70 layers of parallax grass:(you can see it runs very smoothly)

http://www.metacafe.com/watch/4994274/e ... ame_alpha/

the slight fps hiccups there were caused by fraps recording

Alrighty, thanks for all the answers. I have one last question that I saw answered once before but I can't find it again: if you have a 128x128 sprite, would changing its height/width to 256x256 in Construct use the same VRAM as if it was a 256x256 sprite to begin with? (Assuming there's no difference in quality since these are 16-bit sprites)

EDIT: Actually... another kinda unrelated question that I don't feel deserves its own topic if this one's still here. How do I go about making those clouds scroll infinitely? I found two solutions by searching, but it doesn't look like they can apply to what I'm trying to do.

If you mean, stretching the size with events/by properties, then it doesn't affect VRAM-usage, because it doen't change the original texture. If you change the canvas size in the image editor, then you are resizing the texture directly and therefore affect VRAM-usage.

Bump, just in case people didn't see my new question.

(Thanks again for the answers!)

There's a number of ways to have the clouds infinitely scroll.

1. You can make them tiled background objects, and use image offset (could take up a good bit of VRAM though)

2. Use ScrollXleft or ScrollxRight and reposition the clouds when they go off-screen. If the cloud's hotspot is in the middle, then something like this:

+Cloud.x < ScrollXLeft-(cloud.width/2)

-Set Cloud position to: ScrollXRight+random(n), 0+random(windowheight)

3. Use the wrap behavior (that might only work well with single-screen levels or small layouts)

Incredibly bored, so I whipped this up. Hope it helps!

http://download959.mediafire.com/tt59zd ... bjects.cap

edit: might want to change (displayheight) to (scrollybottom)

Wow, looks great! But would that work in a Mario level where the camera's following you as you move?

It should! That's what scrollxleft and such are for

edit: hm. Scrolling to the left kinda messes it up :T I dunno man, maybe someone else can chime in on this.