| Reply | « Previous Thread | Next Thread » |
|
Hi,
I'm trying to make a 4-way scrolling with 16x16 tiles. 143 tiles to draw each frame (fullscreen) It takes about 100 ms to draw the frame. It tried to only draw 90 tiles and then I have a time of about 60ms. The problem is that when I scroll I have white lines that appears randomly and a little flickering... ANd that whatever the frame rate choosen. Here's my run routine: long start; int elapsed; int timePerFrame = 1000/10; while( running ) { start = System.currentTimeMillis(); try { repaint(); serviceRepaints(); } catch(Exception e) {} elapsed = (int)(System.currentTimeMillis() - start); if( elapsed < timePerFrame && running ) { try { t.sleep(timePerFrame-elapsed); } catch( Exception e ) {} } } // end while running I don't use double flickering because it's handeld by 7650. Of course when I'm not scrolling all is ok.... What I am doing wrong? Thanks |
| FatalError |
| View Public Profile |
| Find all posts by FatalError |
|
Flickering is usually due to painting dependant mutations while painting.
For example, say you have a 3D renderer and you are rotating 10 degrees every 20 ms. Now if the paint cycle takes 40 ms, the rotation angle always changes during a paint. So if your paint method uses some class variable to store the angle some of the screen will be drawn with a different angle. If this is what happens you might see into the following solutions: * Synchronize your game logic to repaint(). One way requires a framebuffer. I'm not sure if getGraphics() returns the next buffer that will painted the next repaint(). Otherwise you'll have to create a short[] or Image to act as buffer. The other way uses callSerially(). * Don't mutate variables while painting. A way to do this is copying all class variables to local ones: class X { public y; public z; public void paint(Graphics g) { int y = this.y; int z = this.z; // blah blah blah } }
Last edited by dannyc4 : 2003-10-13 at 20:32.
|
|
thanks for the reply.
I optimize a little the engine so I draw the entire 176x208 screen between 40 and 70 ms. I tried what you said about buffer, here's what I tried: my loop of the run function is: ... update(); repaint(); serviceRepaints(); .... the update do all the mutations and draws everything in a buffer the paint function only does 1 thing: g.drawImage(buffer,0,0,0) But I still have the same problem: these parasite white lines accross the screen... |
| FatalError |
| View Public Profile |
| Find all posts by FatalError |
|
I've tried the callSerially version.
It looks that the scrolling is a little more smooth (perhaps because I'm not call sleep) BUT I still have these fu**tuuuuttt! white lines accross the screen |
| FatalError |
| View Public Profile |
| Find all posts by FatalError |
|
you're not alone on that problem,
besides, Metal Bluster, a really nice iso commericial game, has that lines too! http://www.handango.com/PlatformProd...xtSearch=metal Btw, there's a way., so player won't notice that.., scroll your screen fast! perhaps making the player move faster, this way, the 'lines' won't be that obvious.... please post if you guys have solved this problem, thanks, |
|
BUT I still have these fu**tuuuuttt! white lines accross the screen
Well, in that case it might be a hardware or JDK problem as well... In that case you cannot solve it. You might try one last thing: use the Nokia UI API instead. Perhaps that helps a bit. I'm not sure if DirectGraphics.drawImage() is able to draw microedition.Image though. If I remember correctly someone else had some flickering problems as well (perhaps it was Bartekn or J2ME_ray, but I'm not sure...)... Just do a search on this forum... gr, Danny |
|
I tried with DirectGraphics drawImage & drawPixels but they are slower than drawImage on 7650 and it doesn't correct the problem.
It's very frustrating because the scrolling is now fluid. I just discovered one interesting thing: when I scroll vertical I haven't the white lines or at least they are rare!!! With horizontal scrolling it seems that the white lines are starting from the top of the screen and go to the bottom. Again & again... |
| FatalError |
| View Public Profile |
| Find all posts by FatalError |
|
Mmm, so what happens if you just animate the display by drawing the same Image at same position over and over again?
gr, Danny |
|
you mean when I'm not scrolling ? It's perfect
|
| FatalError |
| View Public Profile |
| Find all posts by FatalError |
|
Ok, I think I have this similar problem, but it are black "spots".
This is because of the LCD display. I'm not sure how to put it in English, but the display "glows after". Thus when a pixel changes from for example white to black, it takes a few more frames before the pixel really turns black... Maybe 7650 has this problem with white. gr, Danny |
|
hmm.,
why not try to color fillrect the screen with white? |
|
I tried with non-white tiles and I have a similar phenomen: there are no more white lines but we can feel a little wave from top to down. This is much discreet but still not perfect at all
When I see videos like this... :-( It's not impossible http://www.jamba.de/i/storage/view/d...uhnSeasons.avi |
| FatalError |
| View Public Profile |
| Find all posts by FatalError |
|
Yeah, but it if it is due LCD you won't see it in the emulator or a avi (which probably is recorded by an emulator)...
If you are really sure you don't paint the screen in 2 iterations or so, I don't think this is unavoidable... gr, Danny |
|
Strange, that effect from vertical scrolling differ from the horizontal one..
|
|
Uhm, I was probably thinking of some pussy or so... I should have written: it might be unavoidable....
@doctordarf: indeed! But it might be due to those little RGB LEDs as well.. They are sequenced linearly. For example: if you put a pixel 0xFF00 to the left of a pixel 0xF00F you'll see a black spot in the middle of them. This is because the left pixel only has red LED fully lit and right pixel only has blue LED fully lit. So the LED sequence is ON,OFF,OFF,OFF,OFF,ON... If they change colour you'll for a moment see a small line in wrong colour due this "after glowing". @FatalError: If you have read the above you may do a final test to test if it'sa LCD problem or not: Convert your graphics to a primary colour, for example only RED or GREEN. Whatever you like. You can use all 4 bits. If you'll also experience the problem this way it's NOT the LCD. If it's gone it is, because then only one LED per pixel is lit and the error you'll see will be in shades of the primary colour you picked. Or, I'm totally wrong:) gr, Danny |
| Reply | « Previous Thread | Next Thread » |
| Thread Tools | Search this Thread |
|---|---|