How to deal with arbitrarily large images in 2D games?

Question

Question

When you have a 2D game that uses really large images (larger than your hardware can support), what do you do? Maybe there's some interesting solution to this problem that never occured to me before.

I'm basically working on a sort of graphic adventure game maker. My target audience are people with little to no game development (and programming) experience. If you were working with such an application, wouldn't you prefer for it to handle the problem internally rather than telling you to "go split your images"?

Context

It's well known that graphic cards impose a set of restrictions on the size of the textures they can use. For instance, when working with XNA you're restricted to a maximum texture size of 2048 or 4096 pixels depending on which profile you choose.

Usually this doesn't pose much a problem in 2D games because most of them have levels that can be constructed from smaller individual pieces (e.g. tiles or transformed sprites).

But think about a few classic point'n'click graphic adventure games (e.g. Monkey Island). Rooms in graphic adventure games are usually designed as a whole, with little or no repeatable sections, just like a painter working on a landscape. Or perhaps a game like Final Fantasy 7 which uses large pre-rendered backgrounds.

Some of these rooms can get pretty large, frequently spanning three or more screens of width. Now if we consider these backgrounds in the context of a modern high definition game, they will easily exceed the maximum supported texture size.

Now, the obvious solution to this is to split the background into smaller sections that fit within the requirements and draw them side by side. But should you (or your artist) have to be the one splitting all of your textures?

If you're working with a high level API, shouldn't it perhaps be prepared to deal with this situation and do the splitting and assembling of the textures internally (either as a pre-process such as XNA's Content Pipeline or at runtime)?

Edit

Here's what I was thinking, from a XNA implementation point of view.

My 2D engine only requires a very small subset of Texture2D's functionality. I can actually reduce it down to this interface:

public interface ITexture
{
    int Height { get; }
    int Width { get; }
    void Draw(SpriteBatch spriteBatch, Vector2 position, Rectangle? source, Color  color, float rotation, Vector2 origin, Vector2 scale, SpriteEffects effects, float layerDepth);
}

The only external method I use that relies on Texture2D is SpriteBatch.Draw() so I could create a bridge between them by adding an extension method:

    public static void Draw(this SpriteBatch spriteBatch, ITexture texture, Vector2 position, Rectangle? sourceRectangle, Color color, float rotation, Vector2 origin, Vector2 scale, SpriteEffects effects, float layerDepth)
    {
        texture.Draw(spriteBatch, position, sourceRectangle, color, rotation, origin, scale, effects, layerDepth);
    }

This would allow me to use an ITexture interchangibly whenever I used a Texture2D before.

Then I could create two different implementations of ITexture e.g. RegularTexture and LargeTexture, where RegularTexture would simply wrap a regular Texture2D.

On the other hand, LargeTexture would keep a List of Texture2D's each corresponding to one of the splitted pieces of the full image. The most important part is that calling Draw() on the LargeTexture should be able to apply all the transformations and draw all the pieces as if they were just one contiguous image.

Finally, to make the entire process transparent, I'd create an unified texture loader class that would act as a Factory Method. It would take the path of the texture as a parameter and return a ITexture which would be either a RegularTexture or a LargeTexture depending on the image size exceeding the limit or not. But the user didn't need to know which one it was.

A bit overkill or does it sound okay?

Answer 1

I think you are on the right track. You have to split the images to smaller pieces. Since you making a game maker you can't use the XNA's Content pipeline. Unless your maker is more like an Engine that will still require the developers to use Visual Studio. So you need to build your own routines that will do the splitting. You should even consider streaming the pieces a bit before that become visizble so that you still don't put limit of how much video memory the players should have.

There are some tricks you can do specifically for adventure games. I imagine like all classic adventure games you will have few layers of these textures so that ... your character can walk behind the tree or the building...

If you want these layers to have paralaxing effect then when you splitting your tiles just skip all the translucent once. Here you need to think of the size of the tiles. Smaller tiles will add managing overhead and draw calls, but will be less data where larger tiles will be more GPU friendly but will have a lot of translucency.

If you don't have paralaxing effect then instead of covering the whole scene with 2-4 giant images that have 32bits depth you can create just one 32 bits depth. And you can have a stenciling or depth layer that will be only 8 bits per pixel.

I know this sound like hard to manage assets by non game developers but it actually doesn't have to be. For example if you have a street with 3 trees and the player goes behind 2 of them and in front of the third tree and the rest of the background... Just make the scene layout the way you want in your editor and then in a build step from your game maker you can bake these giant images (well small tiles of a big image).

About how the classic games were doing it. I'm not sure they probably did simmilar tricks but you have to remember that at the time the screen were 320x240 the games were with 16 colors which when using palattelized textures allows you to encode 2 pixels in single byte. But this is not how the current architectures work so :D

Good Luck

Answer 2

Cut them up so they're no longer arbitrarily large, like you say. There is no magic. Those old 2D games either did that or they were rendered in software, in which case there were no hardware restrictions beyond RAM size. Of note is that many of those 2D games really didn't have huge backgrounds, they just scrolled slowly so they felt huge.

What you're looking to do in your graphic adventure game maker is pre-process those big images during some kind of "build" or "integrate" step before the game is packaged up to run.

If you want to use an existing API and library instead of writing your own I'd suggest that you convert those big images to tiles during that "build" and use a 2D tile engine, of which there are many.

If you want to use 3D techniques of your own you may still want to split into tiles and use a well known and well designed 2D API to write your own 3D library for that, in this way you're guaranteed to at least be starting with a good API design and less design required on your part.

Answer 3

If you're familiar with how a quadtree looks in visual practice, I have used a method that cuts detailed large images into smaller images relatively similar to what a proof/visualization of a quadtree looks like. However mine were made that way to cut up areas specifically that could be encoded or compressed differently based on the color. You could use this method and do what I described, as it is also useful.

At run time cutting them would require more memory temporarily and cause load times to be slowed down. I would say though it depends on whether you care more about physical storage or the load time of a users game made with your editor.

Load/Run Time: The way that I would go about the loading is just cutting it up into proportionally sized pieces. Account for one pixel on the right most piece if it's odd number of pixels though, no one likes their images being cut, especially inexperienced users who might just not know that it's not entirely up to them. Make them half the width OR half the height (or 3rds, 4ths whatever) the reason not into squares or 4 sections (2 rows 2 columns) is because it would make tiling memory smaller since you wouldn't be worrying about both x and y at the same time (and depending on how many images are that large, it could be pretty important)

Before Hand/Automatically: In this case I like the idea of giving the user the choice of storing it in one image or storing it as separate pieces (one image should be default). Storing the image as a .gif would work great. The image would be in one file, and rather than each frame being an animation it would be more like a compressed archive of all the same image (which is essentially what a .gif is anyway). It would allow for ease of physical file transportation, ease of loading:

1. It's a single file
2. All of the files would have almost identical formatting
3. You could easily choose when AND if to cut it up into individual textures
4. It may be easier to access the individual images if they're already in a single loaded .gif since it wouldn't require as much of a mess of image files in memory

Oh and if you use the .gif method, you should change the file extension to something else (.gif -> .kittens) for the sake of less confusion when your .gif animates like it's a broken file. (don't worry about legality of that, .gif is an open format)

Answer 4

This is going to sound obvious, but, why not just split your room into smaller pieces? Pick an arbitrary size that won't bump heads against any graphics cards (like 1024x1024, or maybe larger) and just break your rooms into multiple pieces.

I know that this avoids the problem, and honestly, this is a very interesting problem to solve. Anyway, this is kind of a trivial solution, which may work some of the time for you.