[mariusfahlbusch]

Hello all!
I just read the topics about handling large tileset areas and stuff, and I have the same problem with fullcanvas covered with tiles and need to redraw the whole screen each frame.
(AI enemy movement)

I have a large tileset image, which I clip and draw for each tile at its position.
But of course that leads to a lot of setClip and drawImage calls, which made it slow..

So I got the clue, that I need to set up a linear buffer, arraycopy the pixeldata that needs to be rendered to it and then blit it to the screen with drawPixels().

So here are my questions about it:
* would I create a seperate 'raw' buffer that contains my tileset pixeldata besides the raw backbuffer and release the tileset image after that, for quicker access when copying to the buffer? (you would not want to call getPixel every frame)
* should the buffer really be 128 * 128 ?
I mean for ARGB_8888 this is really huge!
Wouldn't be a quarter screen buffer be a good compromise, you would have 4 drawPixel method calls then per frame but only a quarter of permanent mem usage for your buffer.
* or is all the above mentioned completly wrong? : )

Marius

[dannyc4]

1) Yes, or just create separate linear buffers for each tile. You may use a 2D array for that. Provides faster texture selection (without multiplies and stuff).
2) It gets slower. You have to see it for yourself. BTW. Perhaps ARGB_444 or RGB_444 works fine too? I'm not sure your phone supports 888....
3) For s30/s40 not I guess.

4) BTW: If you use transparent sprites I'm not sure what would be faster: Blit the sprite using arrayCopy (leaves you with finding transparent pixels in between), using buffer[bufferPos] = sprite[spriteBufPos] (pixel by pixel), or use drawPixels() (lets native code handle the transparency). I guess latter should be fastest...

[mariusfahlbusch]

to 4) hmm.. but that's exactly what I want to avoid:
calling drawFunctions like 70 times per frame
or did I misunderstand you?

to 2) ARGB_4444 works fine too of course, sorry

So I came up with this:
To avoid the 128*128 buffer I use one 64*64 buffer and use it 4 times for each quarter of the screen.
In the beginning I copy the Tileset Image to a linear array with each tile line in row.
So each frame copy from that tilebuffer to the background buffer and then blit it with drawPixels()...

[dannyc4]

hmm.. but that's exactly what I want to avoid:
calling drawFunctions like 70 times per frame
or did I misunderstand you?

No I just mean your player/enemy character sprites, not the tiles. I don't think you will have 70 sprites on screen at the same time?

In the beginning I copy the Tileset Image to a linear array with each tile line in row.
Ok, but only once before actual game starts. Remember that creating a separate buffer for each tile will save you from doing offset calculations. If you just use one buffer to store all your tiles you have to calculate tilebuffer offsets to select the proper tile, which eats performance.

To avoid the 128*128 buffer I use one 64*64 buffer and use it 4 times for each quarter of the screen.
This is a very good solution. But perhaps you will have enough heap memory free to just use one buffer. It will make your blit go faster. In the end you still have 170KB free for your tiles and gamelogic.

[mariusfahlbusch]

Thanks for the help!
So tum sum it all up:

* create seperate linear buffers for each single tile from the tileset image
* create 64 * 64 or 128 bg buffer
* arraycopy the needed tiles to the bg buffer
* blit with one drawPixels call

* Sprites: there will only be ~ 8 sprites MAX on the screen, so I could either leave them as is or use drawPixels to speed them up too

one last question: as the screen moves only parts of the tiles are visible, so I will need to calc x / y offsets each frame anyway, don't I?
or should I enlargen the bg buffer by 1 tile at each edge and simply move it by x % TILESIZE and y % TILESIZE, but that would lead to overdraw..

[dannyc4]

Yeah, if you gonna use bigger buffer, you gonna waste time on filling invisible parts. That hurts framerate!

I would suggest you just stop drawing in time;)

Say your tile is 16 pixels wide, then it means you can scroll 16 pixels before the next tile is on exactly the same postion this one was.
So if you have a variable that counts from 0 to 15 when scrolling, you know:

* where to start drawing on the most left tile
* where to stop drawing on the most right tile

gr,

Danny