Click to See Complete Forum and Search --> : Full Screen Questions


Demonpants Software
June 6th, 2004, 01:31 AM
Full screen mode seems like it is much more of a pain in the arse than it needs to be. I am new to it, however, so this is most likely just me messing up. I have recreated Mario using Java's Swing components in a windowed mode. The game runs great, no problems, everything's good. Before putting it away as a completed project, however, I wanted to put it into full screen mode to increase performance.

THE PROBLEM:
*****
I have never put anything into full screen mode before, and, needless to say, I have hit a few snags. I've looked everywhere, but all the tutorials I can find have incomplete answers, examples, or whatever, to the point that I just can't get it all to work correctly. I have put the game into full screen no problem - that was easy - but I can't figure out how to make the program sync with the refresh rate like the Swing repaint() method does automatically. Therefore, I get painful flickering, and everything runs slow.

I tinkered around with things and have made a few discoveries.

The setIgnoresRepaint(boolean) method didn't seem to work. Everything continued to repaint(). I manually commented out my repaint() methods because of this. This made things stop displaying at all, which was not really a surprise to me as there was now nothing ever telling the program to draw itself.

So, to have it draw again, I made this mysterious "rendering loop" that is never well explained in Java's tutorials on full screen mode and doesn't make any sense to me. It creates an infinite loop that calls the paintComponent(Graphics) method I had already made for use with Swing's repaint() method. After doing this, everything started displaying, but with the exact same flickering it had before.

On a hunch, I deleted the super.paintComponent(g); call I had in my own paintComponent method, thinking that perhaps this linked to repaint() somewhere. After doing this, the screen does not flicker. However, the JPanel this method is contained in does not draw its background (easy to do manually), and it does not erase everything after it has been drawn. So it all runs smoothly, but with a black bkgd (odd? should it not be grey?) and as pictures are moved they leave their old pictures behind them.
*****



THE QUESTION:
*****
So my question is this: if there is anyone on this planet who actually knows how to adequately use a full screen mode that refreshes constantly, (as by the countles tutorials I searched I found none) tell me how I can sync things up correctly and why setIgnoreRepaint(boolean) will not work. If there isn't, then how do I get the JPanel to erase what it has already drawn, so that I can do this manually?

Thankee for reading my long message, gurus. Just want to be specific. Also, sample code would be nice.

Demonpants Software
June 6th, 2004, 02:14 PM
I'm beginning to think that there is no one on this planet who knows how to use full screen mode properly. :(

Joe Nellis
June 6th, 2004, 06:14 PM
http://www.google.com/search?q=using+fullscreen+%22full+screen%22+mode+GraphicsDevice&btnG=Search&hl=en&lr=&ie=UTF-8

http://javaalmanac.com/egs/java.awt/screen_Flip.html

BTW, I know NOTHING about fullscreen mode and Java.

Demonpants Software
June 6th, 2004, 08:12 PM
Originally posted by Joe Nellis
http://www.google.com/search?q=using+fullscreen+%22full+screen%22+mode+GraphicsDevice&btnG=Search&hl=en&lr=&ie=UTF-8

http://javaalmanac.com/egs/java.awt/screen_Flip.html

BTW, I know NOTHING about fullscreen mode and Java.
Sadly I've already been to both of those. If nobody knows anything about fullscreen, does anyone at least have any idea how to make the screen erase itself?

Joe Nellis
June 7th, 2004, 01:58 AM
Have you seen this?

Toolkit.getDefaultToolkit().sync();

It might be useful in your main paint method().

cjard
June 7th, 2004, 05:05 AM
note that painting out of sync with the refresh rate does not cause flickering, it causes "jaggies" - broken vertical lines. to avoid flickering, you paint onto an offscreen buffer, then blit everything onscreen. this is called double-buffering

Joe Nellis
June 7th, 2004, 11:34 AM
I think the problem might be the blit action that the jvm is using is not sync'ed to the refresh rate. I am just making a guess here but normally on a windows machine the awt package could be using GDI to paint. When it goes to fullscreen I am guessing some form of DirectX or OpenGL is used.

I'm really interested to find out what the story is. I didn't even know you could go fullscreen with Swing. What about the system supplied frame border and should this even be drawn.

Demonpants Software
June 7th, 2004, 01:54 PM
Originally posted by Joe Nellis
I'm really interested to find out what the story is. I didn't even know you could go fullscreen with Swing. What about the system supplied frame border and should this even be drawn.

Well, you technichally don't use Swing to go full screen, although you do have some sort of Window that fills the screen. I am using a JFrame, because that's what I was using when it was not fullscreen. No, you shouldn't draw a border and you should not enable resizing.. these can bring a lot of problems.

@cjard - Yes, I think the problem is in double buffering. While I said, setDoubleBuffered(true), that is the section of the Sun tutorial that I did not fully understand, because they're horrible at using layman's terms. :) My friend has recently been experimenting with full screen also, and he gave me a link to site that may help:

http://fivedots.coe.psu.ac.th/~ad/jg/

Check it out, as I will doing so as well. I'll make sure to post my final result when I am able to get full screen to work properly.