Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (498)
Games in Android Showcase (114)
games submitted by our members
Games in WIP (563)
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  
  Custom game UI  (Read 2766 times)
0 Members and 1 Guest are viewing this topic.
Offline yarpen

Junior Newbie





« Posted 2003-12-12 06:51:41 »

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

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #1 - Posted 2003-12-12 07:17:48 »

Quote
like, should I use separate thread for each menu screen

Shocked Shocked
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.

Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #2 - Posted 2003-12-12 07:24:59 »

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!
Legends of Yore - The Casual Retro Roguelike
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #3 - Posted 2003-12-12 07:26:38 »

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

Smiley

Offline yarpen

Junior Newbie





« Reply #4 - Posted 2003-12-12 07:37:58 »

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

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #5 - Posted 2003-12-12 08:57:17 »

Quote
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 Smiley

Why are you doing setCurrents while scrolling a selection bar?

Offline yarpen

Junior Newbie





« Reply #6 - Posted 2003-12-12 09:13:37 »

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().
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #7 - Posted 2003-12-12 09:44:22 »

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.

Offline shareme

Junior Member




Java games rock!


« Reply #8 - Posted 2003-12-18 23:04:44 »

Quote

Shocked Shocked
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!

Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #9 - Posted 2003-12-19 04:44:47 »

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!
Legends of Yore - The Casual Retro Roguelike
Offline yarpen

Junior Newbie





« Reply #10 - Posted 2003-12-19 05:07:19 »

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).
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #11 - Posted 2003-12-19 07:18:35 »

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

Offline yarpen

Junior Newbie





« Reply #12 - Posted 2003-12-19 07:21:50 »

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

Junior Member




Java games rock!


« Reply #13 - Posted 2003-12-19 08:01:28 »

okay to fix flickering:

display.callSerially (this);

final statement in the paint method..



Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #14 - Posted 2003-12-19 09:54:44 »

Quote
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(...));.


Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

BurntPizza (12 views)
2014-09-21 02:42:18

BurntPizza (11 views)
2014-09-21 01:30:30

moogie (13 views)
2014-09-21 00:26:15

UprightPath (23 views)
2014-09-20 20:14:06

BurntPizza (27 views)
2014-09-19 03:14:18

Dwinin (40 views)
2014-09-12 09:08:26

Norakomi (70 views)
2014-09-10 13:57:51

TehJavaDev (96 views)
2014-09-10 06:39:09

Tekkerue (49 views)
2014-09-09 02:24:56

mitcheeb (70 views)
2014-09-08 06:06:29
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org 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‑gaming.org
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!