Custom game UI

[yarpen]

Can anyone direct me to any _good_ (detailed, not only general guidelines) examples/documents about doing custom game UI (using low level classes), especially for Nokia S60 phones? I'm having some problems with that (like, should I use separate thread for each menu screen, I experience flickering when switching screens etc). Thanks in advance.

[Matzon]

like, should I use separate thread for each menu screen

Not unless you're prepared for long nights of debugging and drining coffee!

Create a class called a Screen, which inherits from Displayable. This displayable should hold any components you need (which you write yourself).
All of the components the Screen holds, should draw themsleves to an Image which you have precreated to the size of the screen:

1   2   3

// Create offscreen graphics buffer.        Image bufferImage = Image.createImage(getWidth(), getHeight());         Graphics bufferGraphics = bufferImage.getGraphics();

Whenever a component needs to paint, paint onto that bufferImage.
You then only need to paint the bufferImage in your Screens paint method:

1   2   3

public void paint(Graphics g) {         g.drawImage(bufferImage, 0, 0, Graphics.TOP | Graphics.LEFT);     }

This technique is called Double Buffering and will avoid flickering when painting. I have seen flickering when changing Displayable's through the

1	Display.setCurrent()

though.

Keep your program single threaded at ALL times, unless you do lengthy calculations that would lock the UI, or do network communication.

[Matzon]

FWIW, if at all possible - avoid using Device specific api's (or make them easily changable) since it will limit your market potential

midp & game ui (nokia specific)
http://www.forum.nokia.com/ndsCookieBuilder?fileParamID=2867

Games published by our own members! Check 'em out!

[Matzon]

one more:
http://www.forum.nokia.com/ndsCookieBuilder?fileParamID=2822

[yarpen]

Thanks for the tips. I have these Nokia documents, they're quite OK, but sadly they don't describe the details. Right now I have a FullCanvas derived class where I blit my menu. I don't use threads and repaint manually when the user moves selection bar. Seems to work OK except for that flickering problem. It's not caused by the lack of buffering it's rather something connected with the "Display.setCurrent()" you mention. When I switch between different menu screens (with setCurrent()) I can see the Nokia application menu (with "game", "settings" etc icons) for a fraction of second.

[Matzon]

When I switch between different menu screens (with setCurrent()) I can see the Nokia application menu (with "game", "settings" etc icons) for a fraction of second.

Yeah, thats the one I mentioned too - I haven't investigated it thoroughly yet - so I have no solution to the problem (if any). If you do find one, please share it here

Why are you doing setCurrents while scrolling a selection bar?

[yarpen]

I don't. I only call repaint() in order to refresh the selection bar. The flickering I mentioned happens when I have to switch to different menu screen (for example from main menu to settings menu with totally different options), then I have to call setCurrent().

[Matzon]

I tried looking at the Nokia boards - but to no avail.

One possible solution, is to have only one screen - a proxy screen. which is always shown. When you change "screens" you just change the reference to the screen that should receive the paint event... _ ought to work, though cumbersome.

[shareme]

Not unless you're prepared for long nights of debugging and drining coffee!

Create a class called a Screen, which inherits from Displayable. This displayable should hold any components you need (which you write yourself).
All of the components the Screen holds, should draw themsleves to an Image which you have precreated to the size of the screen:

1   2   3

// Create offscreen graphics buffer.        Image bufferImage = Image.createImage(getWidth(), getHeight());         Graphics bufferGraphics = bufferImage.getGraphics();

Whenever a component needs to paint, paint onto that bufferImage.
You then only need to paint the bufferImage in your Screens paint method:

1   2   3

public void paint(Graphics g) {         g.drawImage(bufferImage, 0, 0, Graphics.TOP | Graphics.LEFT);     }

This technique is called Double Buffering and will avoid flickering when painting. I have seen flickering when changing Displayable's through the

1	Display.setCurrent()

though.

Keep your program single threaded at ALL times, unless you do lengthy calculations that would lock the UI, or do network communication.

will not fix his problem as Nokia doe suse double buffering!

[Matzon]

Yeah, I think we pretty much established that his primary problem, was the visibilty of some other screen, while changing displayables. A problem for which I have no solution - nor any other, it would seem  :-/

Games published by our own members! Check 'em out!

[yarpen]

I'm afraid I didn't find any solution. Well, I did, but it's not what I hoped for. I simply recoded everything to use one canvas, so no setCurrent() needed (apart from the one at the beginning of course).

[Matzon]

While this method works fine for custom UI, it fails miserably when using system input boxes  

[yarpen]

True. That's why I had to recode everything (including 'get name' screens etc) to use custom, low-level based UI.

[shareme]

okay to fix flickering:

display.callSerially (this);

final statement in the paint method..

[Matzon]

okay to fix flickering:
display.callSerially (this);
final statement in the paint method..

Hmm without wreaking too much havoc in our engine, I tried to do this - but didn't work.
Normally I would just call a method called 'setVisibleDisplayable(Displayable displayable)' - now I've created a small class DisplayableChanger which extends Thread, which does exactly the same, albeit in its run method. Still get flickering when changing from TextBox to TextBox by calling 'repaint(); display.callSerially(new DisplayableChanger(...));.