Best method for rendering non-tile-based areas?

[Eric Selim]

Hope I'm clear. English isn't my first language.

My sidescroller has a number of areas that aren't tile-based, but art-based. That is, the scene isn't formed by a bunch of tiles, but by a large illustration.

So I would like to know which of the following methods is superior performance wise:

1) Divide the level art into smaller squares, and load each one as a tile. That way, the game would treat it as if it was tile-based, even though each tile will be unique. The game would only draw the tiles that are within the camera view.

Or:

2) Load the whole level art into a texture, and create a rectangle texture atlas the size of the screen, that shows the area corresponding to the player's position. As the camera moves, I'll change the coordinates of the rectangle source so that the level art moves in sync with the player's movement.

Well? Which one would you recommend I went with?

If I wasn't clear enough, please say so and I'll elaborate.

[eXpl0it3r]

So what kind of "art" are we talking here? Do you have like some image?

If something isn't tile based, there's no point in forcing it into being tile based.

Just draw each piece individually. Unless you have big levels, you could even just draw everything all the time. If the levels are big you can determine the current view and calculate which pieces are inside the view and render those.

My advice is to just pick the most straight forward solution you can think of and implement that. Don't try to prematurely optimize stuff that would never be a problem anyways.
It's easier to see the advantages and disadvantages of a design once you actually implemented it.

[Eric Selim]

Thanks for the reply. I'm not sure what you mean by drawing each piece individually, though. Each stage has a single large picture that depicts the whole scene, it's not divided in pieces. That is, an area's whole level art is contained in a single image. That's why I was wondering if I should divide it into smaller parts or tiles.

If the levels are big you can determine the current view and calculate which pieces are inside the view and render those.

That sounds like what I proposed in the first method, unless I'm misreading?

My advice is to just pick the most straight forward solution you can think of and implement that. Don't try to prematurely optimize stuff that would never be a problem anyways.
It's easier to see the advantages and disadvantages of a design once you actually implemented it.

The second method sounds more straightforward to me, but I'm not sure how costly it would be for the program to have huge images loaded at once and drawing just small rectangle sections (the texture atlas) of it.

A thing to keep in mind is that currently, there's only one level image per stage, but I may add more depending on whether or not I end up using parallax scrolling.

[eXpl0it3r]

So what size are we talking about for one image? Don't forget that there's a limit on how large a single texture can be and for older GPUs the limit can be relatively low.

[Elias Daler]

You can find out the texture size limit by calling sf::Texture::getMaximumSize and then subdividing your huge texture by that size and drawing it as huge tiles.

Though you should take a look at how levels can be made out of sprites without having a huge illustration.

[Eric Selim]

So what size are we talking about for one image?

It varies per level, one of them is around 20000x2000.

Don't forget that there's a limit on how large a single texture can be and for older GPUs the limit can be relatively low.

In that case, what's the recommended texture size I should divide it into so that my game can run on old GPUs? How would one go about deciding the pieces' resolution?

You can find out the texture size limit by calling sf::Texture::getMaximumSize and then subdividing your huge texture by that size and drawing it as huge tiles.

Though you should take a look at how levels can be made out of sprites without having a huge illustration.

Thanks for the videos and advice! Doesn't sf::Texture::getMaximumSize return the max texture size for your particular GPU, though? I'd like to support older GPUs as well.

[Elias Daler]

Doesn't sf::Texture::getMaximumSize return the max texture size for your particular GPU, though? I'd like to support older GPUs as well.

It does, but when the user starts your game, the size will be computed for user's GPU. And you can subdivide the images by first putting them in RAM (sf::Image), dividing them into pieces and then putting them in VRAM (sf::Texture).

This might be quite computationally expensive for large pictures, so what you can do is to subdivide each one manually by something like 512x512 (the size which most cards support now) and then divide it in 256x256 (or even in 128x128 if things are really bad...) during runtime, if the game notices that getMaximumSize is less that 512.

P.S. OpenGL 3.2. guarantees that minimum supported texture size is 1024x1024.
P. P.S. More stats: http://feedback.wildfiregames.com/report/opengl/feature/GL_MAX_TEXTURE_SIZE