PocketMatrix

sorry, but I don't understand, immediate data??? what's that? my poor english...
what I were pointing to is that source is a tile data without empty spaces (for 3d iso tiles etc) and dest is backbuffer/frontbuffer/whatever he feels it should go to... so what's wrong with it???


or do you mean using precompiled code like this:
*dest=20;
dest++;
*dest=30;
etc?
well I don't know how to code it propertly in C(so you can load images from files etc) and it takes more memory to store. (and I would guess the speedup isn't really worth it most of the time)

Mirek,

You understood me correctly. I was referring to writing hard-coded values into the frame buffer rather than reading them from another buffer (sprite). This is also known as "pre-compiled sprites." I'm not a fan of using this scheme, but I thought I'd throw out the idea for discussion.

well currently I've got 64 background tiles, and i'm sure im going to have over 200 by the time I finish, sorry, I can't see myself hand coding 200+ tiles

-brendan

I agree with you, I can't see anyone doing this either for a large number of tiles. Unless all of your tiles shared the same transparent pixels, then even what Mirek suggested is going to be a lot of work.

Brendan,

The idea with "compiled sprites" is not to compile them yourself. You write a simple generator, give it your tiles, and it'll give you the code to plot each individual tile.

However, from my point of view, they have more disadvantages than advantages. The generated code will be large (between 1/4 and 3 instructions per *pixel*).. not fun .. say an average pixel takes 2 instructions (a MOV and a STRH)

32*32 = 1024 pixels
1024 * 4 * 2 = 8192
= 8KB/tile..

which is going to *shaft* the cache.

The afore-mentioned RLE scheme would/will probably be the one I'd go for, certainly for partially-transparent tiles.

Another scheme that would work would be to store a mask bit for each pixel in the tile, and use a bitwise AND and OR with the screen data to plot it... the only disadvantage is that you have to load what you've already written to the screen when you plot (but if you're writing in scanlines then it should be in the cache). Obviously it's not as space-efficient as the RLE method.

I always strive for a zero-overdraw method, but for some tile-based engines it simply isn't efficient (because blasting entire tiles to the screen and overdrawing is faster than scan-lining the tiles, I reckon ... it's less complicated, certainly ).

Sorry, I'm waffling again,

Refractor.

digby:nah, why do you think my code will be a lot of work? It's pretty simple. Both the loader and bitmap drawer can be written in 15-30mins.
And you get a nice speedboost (no need for if's and only ~half the amount of pixels is drawn) and save some memory too.
The RLE alpha-compression is tricky. It's hard to code and for pure tiles the algorith above is better. But for objects over the 3d-iso tilemap (and all sprites with a decent amount of fully transparent pixels) it's a huge speed gain.
My 80x86 version works often FEW TIMES FASTER then a normal if version. It often works much faster then a normal bitmap copy(without transparency) because of all the data you DON'T HAVE to copy.
If anyone is interested I can present both my 80x86 asm code and a general approach used in my code(so you can do your own RLE sprites, but as said, it's not easy to implement)