Np, you know my rate :p.

MrSnowflake wrote:

Syntax: [ Download ] [ Hide ]

Syntax: [ Download ] [ Show ]

Using java Syntax Highlighting

1.             try {
2.                canvas = mSurfaceHolder.lockCanvas(null);
3.                 synchronized (mSurfaceHolder) {
4.                   // Draw you stuff
5.                 }
6.             } finally {
7.                 // do this in a finally so that if an exception is thrown
8.                 // during the above, we don't leave the Surface in an
9.                 // inconsistent state
10.                 if (canvas != null) {
11.                     mSurfaceHolder.unlockCanvasAndPost(canvas);
12.                 }
13.             }
14.  

Parsed in 0.032 seconds, using GeSHi 1.0.8.4

is it necessary to make it synchronized?

I guess not, but by synchronizing you have a WaitForVBlank, which means the canvas will be drawn to the screen when the screen refreshes. Which gives you a steady refresh rate (supposed to be 50Hz on G1). So if you don't synchronize, you won't wait with changing the canvas, so you could draw to the canvas when the canvas is being copied to the graphics buffer. This means you will get garbled graphics, as you probably wipe the canvas before drawing, you will get a not complete image, or an image with a lot of tear!

There is no real preformance lost by waiting for this (VBlank). The movement of the screen objects and other game relate stuff should be done before the rendering. If you need too much time to render, the canvas will be drawn the next iteration, which will give you a refresh rate of 25fps. If you have really heavy calculations to do, you should do them in another thread. But then you have to keep in mind that you need to sync each object you move from these calculations.

For the record: DS Games (and GBA and gb* games) do all their game stuff in 1 thread and they run at 60Hz, with WaitForVBlank on!

Yesterday, I have taken a look on your 'DroidGaming' sources at Google Groups (trunk), which is really nice in my opinion.

You have taken a similar synchronized(mSurfaceHolder) block and two other ones holding the same mSurfaceHolder lock, where you set and release the pausing status of the game with a boolean value.

What I was thinking about on that place, was, whether you can replace the synchronized blocks by using 'private volatile boolean' for example- which means that if there is only one operation on the attribute, this certain operation remains atomic and therefore doesn't need to be synchronized.

I agree that if you make an animation which one's behavior is influenced by user interaction, you necessarily have to make the drawing part (and other parts) synchronized (because if the user interaction changes variables that are also used during the drawing process by the canvas, you never know what's the final result// so the changes triggered by the user interaction have to wait until the canvas is fully drawn -> synchronized).

However, I don't think that the drawing part has to be made synchronized if you just want to paint a static picture for simple displaying issues, which is independent from other influences.
My question was therefore, if the 'synchronized' is generally necessary on that place (which would mean that there are some synchronized(mSurfaceHolder) blocks under the surface making it necessary to do so.

MrSnowflake wrote: If you have really heavy calculations to do, you should do them in another thread.

Hmm, I've made bad experiences with that. It usually slows down the game even more (especially in a mobile phone i suppose).

MrSnowflake wrote:For the record: DS Games (and GBA and gb* games) do all their game stuff in 1 thread and they run at 60Hz, with WaitForVBlank on!

That means grafic drawings and game logics in same thread?

Danuubz wrote:

MrSnowflake wrote: If you have really heavy calculations to do, you should do them in another thread.

Hmm, I've made bad experiences with that. It usually slows down the game even more (especially in a mobile phone i suppose).

Well, it will probably not be a very good idea indeed, but you should know the option is there .

Danuubz wrote:

MrSnowflake wrote:For the record: DS Games (and GBA and gb* games) do all their game stuff in 1 thread and they run at 60Hz, with WaitForVBlank on!

That means grafic drawings and game logics in same thread?

Yup. Actually, the drawing to the screen is done in hardware by the DS (even for 2D), you set registers to the values u want, so the drawing itself doesn't affect your game speed.

MrSnowflake wrote:Yup. Actually, the drawing to the screen is done in hardware by the DS (even for 2D), you set registers to the values u want, so the drawing itself doesn't affect your game speed.

What does 'DS' mean?

Usually putting things on screen should be the most time consuming process (much more than rendering). It may be fairly accelerated if drawing operations are done directly by hardware, but they still remain rather time intensive.

That's why you need double buffering in (regular) Java to process the images offscreen first if you want good results.

DS == Nintendo DS.

The double buffering is not nescessairy because of the synchronization.

MrSnowflake wrote:The double buffering is not nescessairy because of the synchronization.

Hmm, double buffering has nothing to do directly with synchronization.

'synchronized' means, that if one thread enters a method declared as synchronized, it captures the according lock and no other thread can enter a method that is bound to that lock until the work is done (the lock can be a class lock or an object lock).

Double buffering (in this case) means that the picture is rendered offscreen and then put to screen (instead of putting every single element seperately to screen). According to several O'Reilly books, rendering happens fast compared to putting (single) elements on screen- so it is better to do the whole rendering offscreen and then putting the result to the display.

-> double buffering and synchronization belong to different contexts.

Yes true, but because of the synchronisation, the surface is actually double buffered, because the buffer is only copied to the screen, when you aren't writing, so the effect is the same. Because when you are writing to the buffer, the buffer can't be accessed by the system.

Yep, you can't write to the buffer and to the screen the same time. But the advantage is another:

If you don't do double buffering and need to write lots of distinct bitmaps (lets take 10) to the screen, you need to access screen 10 times.

If you do double buffering, you create an offscreen bitmap and write 10 times to that, and when that is finished, you write that offscreen bitmap to screen. In this case, you need to access screen only 1 time.

That's why it is faster to take the second way. As an example, FreeCol (Colonization clone written in Java, which was project of the month on sourceforge.net, 550.000 downloads) uses both double buffering and synchronization.

It is possible, however, that Android does that automatically by default...