TiledLayer & blit performance

[kingstone]

Hello everyone!

Im planning to develop a game which will require numerous TiledLayers (around 3 or 4) for rendering. This means that most tiles in many layers will be fully transparent (tile index 0). I suppose TiledLayer.Paint() looks something like this:

//Pseudo code
for (x=0;x<this.cols;x++)
   for (y=0;y<this.rows;y++)
      if (this.tiles[x][y]!=0)
          blitTile(...);

So for each TiledLayer this double loop will be executed each frame although blitTile() will only be executed a few tiles since most tiles are transparent. My question is: Will this generate a performance overhead - or is the cpu needed for the loop negliable as compared to the blit operations? If this is an overhead, could i increase performance by not using TiledLayers and instead blit a list of tiles for each layer using Sprite.paint(), Graphics.drawImage(), Graphics.copyArea(), Graphics.drawRGB() or something like that? Or is TiledLayer somehow magically optimized?

Nice forum by the way, first post for me here. Peace!

Mathias Johansson
SLX Entertainment

[Anon666]

performance of TiledLayer varies tremendously.

There are some handsets where it has been written optimally, and performs better than a hand-made implementation could manage.
However, the vast majority simply copied Sun’s reference implementation - which is a complete pile of *hite.

I suggest you write your own optimised renderer - perhaps using a back-buffer.
Though I suggest avoiding the use of copyArea, as it too can be very slow when copying onto itself on some devices.
The alternative is to use what I have branded a ‘dynamic origin quadrant back-buffer’, I have no idea if it has a proper name - that name simply describes its function best.

I might get around to knocking up a webpage explaining how it works sometime.

[kingstone]

Thanks for the reply Anon666!

Dynamic origin quadrant back-buffer sounds mighty fancy ;D What API function do you use for the blitting? Does the Sprite.paint() function suffer from the same varying performance as does TiledLayer.paint()? I find the sprite transformation to be really handy - the biggest drawback of TiledLayers is that you cannot mirror your sprites. But i suppose that if one hopes to get some decent performance the gfx has to mirrored and stored in some buffer first to be blitted normally.
What do you mean by “I suggest you write your own optimised renderer - perhaps using a back-buffer”? I use backbuffering but just the the only way that affects things is that i call myGameCanvas.flushGraphics() to flip the buffers, nothing else.

[OverKill]

If you are gonna use tiled backgrounds, go to gamedev.net and check out the tutorials and forums.
You will find all the optimisations and techniques you need.
Naturally you’d also have to optimise those further because of the extreme limitations of mobiles.

[Anon666]

This is the Thread you want :-

http://www.gamedev.net/community/forums/topic.asp?topic_id=277210

In particular, this post describes the buffering system I was giving a name to.

Treat the backbuffer like it’s circular (i.e. a two dimensional ring buffer), when scrolling you just wrap around the edges and blit any new tiles on the other side. Finally you copy the buffer to screen in four separate pieces.

And the result is unlimited four-directional scrolling without using any extra copying!
Am I the only 386 coder left around here? ;)[quote]

[/quote]

[kingstone]

Thanks a lot guys, I’m on it! I guess there is a lot of cpu to be saved by making one large blit instead of many small.

I just need to get one more question answered, please… If I implement my own renderer (I suppose I’ll be using an instance of Image for the back buffer), what method should I use for the blitting operation? Graphics.drawImage(), Graphics.copyArea(), Graphics.drawRGB() or something else?

Great forum by the way, I hope i can contribute somewhat.

[Anon666]

Depends on the handset, and whether you intend to support flipping in your tileset.

You should definitely implement a layer of abstraction, so you can render through various APIs (and various mechanisms within said APIs) without having to rewrite any core game code.

A few notes you will find useful :-

Nokia

1. drawPixels on Nokia Series 40’s is approx. 3 times faster than drawImage. (though I believe it is due to the implementation of drawImage having its performance dependant upon the size of the source image).
2. drawPixels is broken on Platform 2 series 40’s. (it doesn’t honour clip areas correctly, and under certain cirumstances will blow up with an AIOOBException)
3. storing your images in raw 4444 pixel format in the jar will result in the images consuming ~10-15% more jar space.
4. drawRegion leaks lots of memory very quickly on midp2 S60’s.

Samsung

1. drawRegion is inconsistently buggy across the many different handsets. The general rule is that, only mirroring, flipping and both together work. Though each handset appears to be broken in different ways.
   For example, the Samsung D500 can do all 8 transforms - so long as the region of the source image being drawn (in the target coordinate system) does not extend beyond 176 in either X or Y axis’. (co-incidence the screenWidth is 176? I think not…)
   The Samsung D600 breaks in a completely different fashion, if the target area of the drawRegion intersects any screen edge, and the transform being performed is a rotation, the source image will become corrupted, and garbage will be drawn to the screen.

The list goes on and on, it is comical how pathetic the phone manufacturers are at implementing a trivially straight-forward API such as midp2.
I realy think Sun need to get their arses in gear, and enforce some kind of quality control on JVM implementations that claim to support a certain API - when they clearly don’t.

The most reliable, most consistent, and best performing midp implementations are easily SonyEricsson.
The high-end Sharp handsets (902SH and similars) are also very good, which is odd after the early handsets were so poo.

[kingstone]

Wow thanks a lot Anon666!

I read in an article in may that at least motorola is making some effort to make life easier on us developers for midp 3.0.
http://www.infoworld.com/article/06/05/15/78287_HNjaveclipsemotorola_1.html?s=feature. But as long as the midp 2.0 handsets are still out there (which they will be for long still) one will always have to concern oneself with backwards compability. That’s why I’m considering to use j2mepolish (http://www.j2mepolish.org/) for upcoming projects, has anyone got any experience with it?