Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (780)
Games in Android Showcase (233)
games submitted by our members
Games in WIP (857)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  TiledLayer & blit performance  (Read 6765 times)
0 Members and 1 Guest are viewing this topic.
Offline kingstone

Senior Newbie

« Posted 2006-07-17 10:02:01 »

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)

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
Offline Anon666

Junior Devvie

aka Abuse/AbU5e/TehJumpingJawa

« Reply #1 - Posted 2006-07-17 14:43:01 »

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.
Offline kingstone

Senior Newbie

« Reply #2 - Posted 2006-07-18 13:21:14 »

Thanks for the reply Anon666!

Dynamic origin quadrant back-buffer sounds mighty fancy  Grin 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.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline OverKill

Junior Devvie

Java games rock!

« Reply #3 - Posted 2006-07-20 08:16:26 »

If you are gonna use tiled backgrounds, go to 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.
Offline Anon666

Junior Devvie

aka Abuse/AbU5e/TehJumpingJawa

« Reply #4 - Posted 2006-07-20 15:17:02 »

This is the Thread you want :-

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? Wink
Offline kingstone

Senior Newbie

« Reply #5 - Posted 2006-07-24 11:00:56 »

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.
Offline Anon666

Junior Devvie

aka Abuse/AbU5e/TehJumpingJawa

« Reply #6 - Posted 2006-07-24 22:04:29 »

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 :-


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.


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.
Offline kingstone

Senior Newbie

« Reply #7 - Posted 2006-07-25 11:20:03 »

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. 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 ( for upcoming projects, has anyone got any experience with it?
Pages: [1]
  ignore  |  Print  

hadezbladez (1095 views)
2018-11-16 13:46:03

hadezbladez (498 views)
2018-11-16 13:41:33

hadezbladez (1087 views)
2018-11-16 13:35:35

hadezbladez (251 views)
2018-11-16 13:32:03

EgonOlsen (2540 views)
2018-06-10 19:43:48

EgonOlsen (2740 views)
2018-06-10 19:43:44

EgonOlsen (1544 views)
2018-06-10 19:43:20

DesertCoockie (2248 views)
2018-05-13 18:23:11

nelsongames (2082 views)
2018-04-24 18:15:36

nelsongames (2777 views)
2018-04-24 18:14:32
Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08

Deployment and Packaging
by gouessej
2018-08-22 08:03:45

Deployment and Packaging
by philfrei
2018-08-20 02:33:38

Deployment and Packaging
by philfrei
2018-08-20 02:29:55

Deployment and Packaging
by philfrei
2018-08-19 23:56:20

Deployment and Packaging
by philfrei
2018-08-19 23:54:46 is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!