Storing tilesets as an array of BITMAPS or as a single BITMAP
Jose Rubio

I have an implementation of a tile engine which uses an array of BITMAP objects, indexed by tile number, to draw the map.

I wonder if performance will be better if I put the entire tileset in a single BITMAP object and simply set the origin coordinates from where to get a particular tile (instead of being always 0,0 which is the case if I have a single tile per BITMAP).

Without delving into the Allegro code, I think this is not trivial to answer, and also I suspect there will be differences between Allegro 4 (software rendering) and Allegro 5 (OpenGL rendering).

Any thoughts on this topic?

Thanks in advance.

Niunio

In my engine I use a single bitmap to store all tiles. Then it uses a list of bitmaps, one per tile, but may be I change this in a future version (need to profile it though).

AFAIK it is better to use a single bitmap in OpenGL rendering. Less VRAM needed and faster rendering in old graphic cards.

Jose Rubio

So you decompose the bitmap at loading time and create a list of BITMAP objects? I do exactly this.

Niunio

So you decompose the bitmap at loading time and create a list of BITMAP objects? I do exactly this.

Not exactly. What I do is to load the bitmap and then create subbitmaps for each tile.

Arvidsson

Using Allegro 5 it will definitely be faster using a texture atlas (i.e. one large bitmap decomposed into several sub-bitmaps) if you enable deferred bitmap drawing.

Chris Katko

It's actually super simple. You just use subbitmaps instead of bitmaps.

The biggest difficulty is putting non-standard size tiles into the same bitmap. (Check that awesome packer tool in that other thread the guy ported to Allegro.)

If the tiles are the same size, it's as simple as loading the bitmap, and then running one or two for loops to create the sub-bitmaps into your array.

Performance WILL be better. Each bitmap is a texture. If you request a texture change too often (ala every draw call) its much slower and represents a bottleneck. I ran into that issue when I was making a Minecraft space clone way back when Minecraft was in its infancy. I called a texture change per block and it was much faster when I tried to reduce swaps by lining up similar blocks into one call. (I didn't realize back then I could use a texture atlas instead. Oh, youth...)

http://i.imgur.com/g0uHhMm.png

http://i.imgur.com/XnhetZu.png

(Not the best pics, but I lost most of them in a HDD crash.)

Felix-The-Ghost

Is there really a significant difference?
What if the number of bitmaps and dimensions for each is unknown? (Loading all graphics in a certain directory)

Eric Johnson

I don't quite understand the concept of a texture atlas. How does a it differ from simply storing all bitmaps into one big bitmap? Or is that exactly what a texture atlas is?

Felix-The-Ghost

Yes Eric I believe they are one and the same.
Even if it provides marginal boosts I don't see the point of investing the time to create a system to generate an atlas when the game/program already has insane speeds.

Chris Katko

Even if it provides marginal boosts I don't see the point of investing the time to create a system to generate an atlas when the game/program already has insane speeds.

I quickly hit the limits when I was doing 3-D, and it was only a Minecraft-clone using AllegroGL. I think I had a GTX ~9600 back then.

It really depends on your game type. Is your Allegro game, Factorio? Then absolutely.

https://gamedev.stackexchange.com/questions/73316/how-to-solve-the-big-video-memory-requirements-in-2d-game

Is your game a C64 remake with 8 (80, or 800) sprites on the screen at most? Your time as an indie developer is better spent elsewhere.

But again, it doesn't take that much time. It's just a bunch of sprites on a single texture instead of separate textures. So it's about as simple as mipmapping except for how you plan on putting them and finding them, ala the mapping phase.

So the question was: Is it faster? And the answer is YES. Significantly. The only question is, "In my application, is sprite drawing my bottleneck?"

Felix-The-Ghost

The post you linked said even without an atlas you wouldn't encounter problems until 20,000 sprites were on the screen. Even assuming that's a generous over-estimate I can't imagine any 2D game similar to NES/SNES titles in style hitting that limit.

Chris Katko

You're arguing something different. I'm not restricting the domain to SNES games. There are clearly 2-D games (Factorio) that hit that limitation. Bullet-hell and "simulation" like games can easily hit that limit.

If you personally have a game type that doesn't need many sprites, then you aren't effected. But the question is, DOES it significantly speed things up, and the answer is "Yes."

Felix-The-Ghost

I'm not so sure bullet-hell/SHMUP games would ever have ~20,000 sprites on screen, and Factorio is a bizarre case.

You've made your point though—deferred drawing is ~5x faster, and you can do all kinds of things with it along with the other A5 features.

I guess I've always considered Allegro's niche to be the kind of games you can currently find in the depot (albeit most are A4 games) but you are right, if someone has an idea that would require an absurd amount of resources A5 provides the tools to handle it efficiently.

Simon Parzer

I wonder if performance will be better if I put the entire tileset in a single BITMAP object and simply set the origin coordinates from where to get a particular tile (instead of being always 0,0 which is the case if I have a single tile per BITMAP).

Do you currently have performance issues?

Thread #616854. Printed from Allegro.cc