Tile performance

If you have a bunch of colorkeyed tiles, is it faster to (internally at
least) treat each tile as an individual surface? Right now I am using one
surface that consists of a “grid” of tiles. Setting SDL_RLEACCEL is
currently slowing me down and I have a feeling that this might be the cause.

  • Randi

Regimental Command
Generic Armored Combat System
http://www-users.cs.umn.edu/~relander/regcom/index.html

If you have a bunch of colorkeyed tiles, is it faster to (internally at
least) treat each tile as an individual surface?

Yes, if you use RLE acceleration.

Right now I am using one
surface that consists of a “grid” of tiles. Setting SDL_RLEACCEL is
currently slowing me down and I have a feeling that this might be the cause.

Yep, it has to recalculate the clipping each time you blit.

-Sam Lantinga, Lead Programmer, Loki Entertainment Software

If you have a bunch of colorkeyed tiles, is it faster to (internally at
least) treat each tile as an individual surface?

Yes, if you use RLE acceleration.

Right now I am using one
surface that consists of a “grid” of tiles. Setting SDL_RLEACCEL is
currently slowing me down and I have a feeling that this might be the cause.

Yep, it has to recalculate the clipping each time you blit.

If you use the patch submitted on this list a few days ago, clipping RLE
is basically “free” (i.e., not significantly slower than normal RLE
blitting). It also makes normal RLE blitting significantly faster (and
includes a small benchmark to test the speed of all RLE blitting cases).

If you missed it, its also available from:

http://linuxbox.fdns.net/SDL/SDL_RLE-speedup-patch.tar.gz

In the clipping case, the patch can give give over a 300% speed increase
over the current code. It also saves over 192K in uneeded static buffers.

Check it out, its been tested and seems to be solid (tested on x86 and
Solaris, but should work everywhere).

Ken Jordan aka Xark (on #sdl)

P.S. The patch is tiny (one file, like 4K), the size of the package above
is larger (85K) due to automake overhead mostly (for the rlebench program
included).On Fri, 19 May 2000, Sam Lantinga wrote: