Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (482)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (550)
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  
  midp 1.0 back-buffering  (Read 1461 times)
0 Members and 1 Guest are viewing this topic.
Offline ZeDuS

Junior Newbie




Java games rock!


« Posted 2005-02-14 10:12:59 »

I recenetly started coding j2me midp 1.0,
i added some basic animation and keyboard control but the animation looks choppy, this is probably because the lack of back buffering in my app.

can someone please post a simple example of how to implement back buffering in midp 1.0 ?
(i'm talking about the process of drawing into a virtual screen buffer and then flipping into the real screen with vertical sync)
thanks in advance  Smiley

Edit: i managed to do the back buffering, i'm simply writing to an Image i created (in the same size of the device actual screen size) and whenever i want to "flip", i just do g.drawImage(backBufferImage,0,0,g.TOP|g.LEFT);

but the animation is STILL choppy ;(
is there a way i can wait for vert sync?
Offline shmoove

Junior Member




Doh!


« Reply #1 - Posted 2005-02-14 10:53:59 »

Most phones implement double buffering themselves. The Canvas class has a isDoubleBuffered method you can query. But on some devices (T610 I'm looking at you), even though they say they are double buffered they still act wierd.

Anyway, here is a pretty generic implementation that can handle both types of devices:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
class MyCanvas extends Canvas {
  private Image backBuffer;
  private Graphics backBufferGraphics;

  public MyCanvas() {
    if (!isDoubleBuffered()) {
      // note: on some phones getHeight() gives wrong results, so watch out
     backBuffer = Image.createImage(getWidth(),getHeight());
      backBufferGraphics = backBuffer.getGraphics();
    }
    // ....
 }

  public void paint(Grapphics g) {
    Graphics original;
    if (backBuffer != null) {
      original = g;
      g = backBufferGraphics;
    }
    // regular paint code using g
   if (original != null) {
      original.drawImage(backBuffer,0,0,Graphics.TOP|Graphics.LEFT);
    }
  }
}


shmoove
Offline ZeDuS

Junior Newbie




Java games rock!


« Reply #2 - Posted 2005-02-14 11:05:49 »

thanks alot shmoove Smiley
after posting my question i found a similar solution, but the animation still looks choppy Sad
description of what my app does:
(i didn't know that some devices are auto-double-buffered so i'll add code to handle that as well now  - thanks Smiley )


first i clear the virtual buffer image.
I draw some image to the virtual buffer image.
I draw a rectangle and in it some text to the virtual buffer image.
i draw the virtual buffer image into the real device screen.

the rectangle that has text in it is controlled with the keys of the mobile.

for some reason, the rectangle+text leaves some sort of a trail, and looks VERY choppy when running the app on my device (nokia 3100).

any idea of what might be the cause?

here is my code:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
public void paint(Graphics g) {          
      
      if (!bInitedGraphicsSize)      
            initBackBuffer(g);                
      
    // clear the screen:
   backBufferGraphics.setColor(0xffffff);
     backBufferGraphics.fillRect(CORNER_X, CORNER_Y, DISP_WIDTH, DISP_HEIGHT);
    
    // draw text
    Font dFont = backBufferGraphics.getFont();
     int fontH = dFont.getHeight();
    int fontW = dFont.stringWidth("Devour!");
    
      backBufferGraphics.setColor(0xff0000);
      backBufferGraphics.fillRect((DISP_WIDTH-fontW)/2 - 1 + iTextPosX, (DISP_HEIGHT-fontH)/2 + iTextPosY,
                   fontW + 2, fontH);          
      backBufferGraphics.setColor(0x00ff00);      
      backBufferGraphics.setFont(dFont);
      backBufferGraphics.drawString("Devour!", (DISP_WIDTH-fontW)/2 + iTextPosX, (DISP_HEIGHT-fontH)/2 + iTextPosY,
                   g.TOP|g.LEFT);

        // draw the player
   player.paint(backBufferGraphics);
      
      // flip the back buffer onto the real device screen
     g.drawImage(backBufferImage, 0,0, g.TOP|g.LEFT);      
      
  }


Edit:
ok, i changed my code (now it's more similar to yours, and handles both cases)
i tested and found that the device i'm testing (nokia 3100) has double buffering... :/
prehaps the reason is different.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline wooD

Senior Newbie




J2ME Developer


« Reply #3 - Posted 2005-02-14 13:20:40 »

I have solved this by not redrawing the entire back buffer every time. I draw the front  buffer into the back buffer with the offset and then only draw the edges of the back buffer. Once I have the edges drawn, I swap front and back buffers.  This is only useful for the background, but drawing the dynamic items directly on the screen after bliting of the background has worked well for me.  My back buffers are typically 20 pixels larger than screen size and I scroll them smoothly on the screen and only update/swap the back buffer on 20 pixel boundaries.

This doesn't work on a Samsung phone I have, but I do have a work around which I posted in another topic. Otherwise, it has worked well for me on every other phone.

Wood

Offline shmoove

Junior Member




Doh!


« Reply #4 - Posted 2005-02-14 13:56:33 »

Quote

for some reason, the rectangle+text leaves some sort of a trail, and looks VERY choppy when running the app on my device (nokia 3100).

Aaahhh. An older Series 40 phone. In that case I think I have some bad news for you. It's a hardware issue. They use cheapo screens and if you move high-contrast fast enough they always leave a trail (the pixels just seem to hang around for a while longer). The only possible workaround is to try to use colors that don't have high contrasts between them in order to "hide" the ghosting effect.

shmoove
Offline ZeDuS

Junior Newbie




Java games rock!


« Reply #5 - Posted 2005-02-14 20:00:11 »

shmoove:
Thanks, i'll be aware from now on to this and tell my artist to create the art accordingly... Smiley
i'm not too annoyed by this hardware issue because i just played might & magic in my nokia 3100 and it was so cool, so apperently some really cool things can still be done Smiley

wood:
i'm not sure i understood your answer ;(

What does your solution solve?
it prevents the trail of fast moving sprites? it is your implementation of double buffering?

didn't quite understand parts like
"I draw the front  buffer into the back buffer with the offset and then only draw the edges of the back buffer."
Offline wooD

Senior Newbie




J2ME Developer


« Reply #6 - Posted 2005-02-15 20:39:58 »

Quote
wood:
i'm not sure i understood your answer ;(

Performance Enhancement 1:
If you are having performance problems, the first thing you do is start drawing offscreen and bliting the offscreen image to the screen on update. That's what you are already doing.

Performance Enhancement 2:
If you are still having problems then you have to look at where else you can cut out drawing. One of my solutions is to draw one offscreen image with another being offset in the direction the screen is moving, then only update the edges. Instead of redrawing the entire offscreen image everytime three is a change.

Performance Enhancement 3:
The next step is to keep a larger than screen set of offscreen images and offset the offscreen blit until you reach and edge, then do the redrawing of the edges in #2 above and reset the offset.

I have yet to launch a game where I have not had to do all three of these steps for at least one of the devices and now I just do all 3 for all devices as it makes the game faster on all the devices.

Wood

Offline ZeDuS

Junior Newbie




Java games rock!


« Reply #7 - Posted 2005-02-16 19:04:34 »

thanks Smiley
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.

CopyableCougar4 (14 views)
2014-08-22 19:31:30

atombrot (28 views)
2014-08-19 09:29:53

Tekkerue (25 views)
2014-08-16 06:45:27

Tekkerue (23 views)
2014-08-16 06:22:17

Tekkerue (15 views)
2014-08-16 06:20:21

Tekkerue (22 views)
2014-08-16 06:12:11

Rayexar (61 views)
2014-08-11 02:49:23

BurntPizza (39 views)
2014-08-09 21:09:32

BurntPizza (31 views)
2014-08-08 02:01:56

Norakomi (37 views)
2014-08-06 19:49:38
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!