fullscreen. Which method?

[craiten]

Hey java programer,

I just started for a few days to 'programming' a game in Java. Well I only watched two tutorials.
In this two tutorials the guys used two different ways to create a screen.
One use frames (JFrame), and the other use Displaymode + Window.

My quetion is, what is the better method to create a full screen window?
Or exist also another method?

(btw: I'm from germany. I hope u can handle my syntax! )

 

[gouessej]

Hi

I used simulated full screen mode for years (just by maximizing a frame) but it is not guaranteed to work. Exclusive full screen mode doesn't work very well on some machines under Windows, don't forget to disable the Direct3D pipeline to work around this bug; it doesn't work at all under GNU Linux with KDE 4 (the task bar is still drawn above the window). The most reliable exclusive full screen mode is in the native windowing systems of JogAmp (NEWT) and LWJGL.

[alesky]

look hire ii will help u

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

I used my i game and obtained a fantastic result

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

[theagentd]

For my project work in high school I used a a maximized undecorated JFrame with setAlwaysOnTop() set to true to show it above the task bar at the bottom. That was because the computers that they had in school had insanely old Intel cards (+ possibly permission problems) that made any attempt to go to fullscreen crash. That was with LWJGL though, but the JFrame trick works no matter what you draw to it of course.

[Damocles]

Here a little "fullscreen" makeshift class.
Not very clean, but should be a good start.

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   30   31   32   33   34   35   36   37

import java.awt.Color; import java.awt.Graphics; import java.awt.GraphicsDevice; import java.awt.GraphicsEnvironment; import javax.swing.JFrame; public class Fullscreen extends JFrame {    public Fullscreen()    {              this.setUndecorated(true);       GraphicsEnvironment ge = GraphicsEnvironment.       getLocalGraphicsEnvironment();       GraphicsDevice[] gs = ge.getScreenDevices();       gs[0].setFullScreenWindow(this);          }        public void paint(Graphics g)    {       g.setColor(new Color(0,0,0));       g.fillRect(0, 0, this.getWidth(), this.getHeight());       g.setColor(new Color(155,155,155));       g.drawString("I should be Fullscreen now", 100, 100);    }            public static void main(String[] args)    {             new Fullscreen();    } }

[craiten]

The most reliable exclusive full screen mode is in the native windowing systems of JogAmp (NEWT) and LWJGL.

Well I think I will use LWJGL if its true that this is much less susceptible as JFrame.

That was because the computers that they had in school had insanely old Intel cards (+ possibly permission problems) that made any attempt to go to fullscreen crash. That was with LWJGL though, but the JFrame trick works no matter what you draw to it of course.

What is the reason if you dont have permission to your graphic card?
I think it's a special case if you are at a school where the computers has old Intel cards.


So thats the difference?
JFrame is stable if you could have permision problems and LWJGL is stable for all other cases?

Here a little "fullscreen" makeshift class.
Not very clean, but should be a good start.

Thx for this but at first I want to look around, what's better.

[princec]

LWJGL is a whole different rendering API and way of life compared to Java2D... don't jump in unless you fancy learning OpenGL at the same time...

Cas

[craiten]

Either way, I will learn OpenGL programing in my study.
So I can hit two birds with one stone

[gouessej]

The most reliable exclusive full screen mode is in the native windowing systems of JogAmp (NEWT) and LWJGL.

Well I think I will use LWJGL if its true that this is much less susceptible as JFrame.

All suggestions above based on Java2D seem not to have been fully tested under several operating systems. In my humble opinion, claiming they work without performing these tests is really a bad idea. However, princec is right, Java2D and bindings to OpenGL are 2 different kinds of APIs. I don't want to start another flame war but you can consider using JogAmp too.

That was because the computers that they had in school had insanely old Intel cards (+ possibly permission problems) that made any attempt to go to fullscreen crash. That was with LWJGL though, but the JFrame trick works no matter what you draw to it of course.

What is the reason if you dont have permission to your graphic card?
I think it's a special case if you are at a school where the computers has old Intel cards.

It would be better to know exactly why it didn't work before concluding.

So thats the difference?
JFrame is stable if you could have permision problems and LWJGL is stable for all other cases?

JFrame is stable, the only problem comes from the exclusive full screen support introduced in Java 1.4 which has never been very reliable across platforms, that was why I used simulated full screen mode until it stopped working under GNU Linux with KDE 4. Then, I was forced to switch to NEWT (JogAmp) and I'm extremely glad of it. I can easily change the resolution and switch to full screen / windowed mode at runtime. I assume that if you use Java, you worry about the support under several operating systems.

Why not considering using JavaFX? Has someone tested javafx.stage.Stage.setFullscreen(true)?

Here a little "fullscreen" makeshift class.
Not very clean, but should be a good start.

Thx for this but at first I want to look around, what's better.

It's just plain exclusive full screen mode and his example is more dangerous than the one provided in the Java documentation (look at the missing try/finally clause):
http://docs.oracle.com/javase/tutorial/extra/fullscreen/exclusivemode.html

Either way, I will learn OpenGL programing in my study.
So I can hit two birds with one stone

Good luck with JogAmp... or LWJGL  

[craiten]

Ough, much information.

Does it make sense to learn how the API of Java works if I learn OpenGL programing soon?
Or is this a good beginning for a newbie?

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

[theagentd]

That was because the computers that they had in school had insanely old Intel cards (+ possibly permission problems) that made any attempt to go to fullscreen crash. That was with LWJGL though, but the JFrame trick works no matter what you draw to it of course.

What is the reason if you dont have permission to your graphic card?
I think it's a special case if you are at a school where the computers has old Intel cards.

It would be better to know exactly why it didn't work before concluding.

Either my school have blocked programs from going to exclusive fullscreen mode to prevent people from playing games, or there was a bug in the Intel drivers. Probably the latter. How am I supposed to find out which one? I graduated 1.5 years ago and it's not like I could've just walked into tech support and ask them if they're blocking my games. xD

[kappa]

One easy option if you want to skip learning OpenGL (or come back to it later) is to use a higher level library like Slick2D, it wraps the low level API's of LWJGL to make it very similar to Java2D (plus it has a very nice game framework and other stuff to make writing games easier). Therefore you get the speed of OpenGL and the ease of Java2D at the same time. LibGDX is also another really nice option.

[davedes]

Ough, much information.

Does it make sense to learn how the API of Java works if I learn OpenGL programing soon?
Or is this a good beginning for a newbie?

OpenGL is pretty advanced, so it may not be the best place for a newbie to start.

Swing/Java2D is good for learning GUIs and the basics of a graphics API (images, shapes, paths, etc).

Other than that, it is not very good as a game library. For a complex game, you end up needing a lot of boilerplate, such as game loops, graphics context and buffer strategy setup, input handling setup, texture atlas tools, tiled map loading, etc. You will end up struggling with huge differences in performance across systems, and generally very poor performance compared to what you might expect from an application in 2012. You will also need to struggle with JavaSound which is pretty awful.

So I'd suggest learning the basics with Java2D -- develop some simple tic-tac-toe games, make various software tools so you can understand GUIs and programming concepts, etc. Once you're ready, you can move onto game development with a library like LibGDX.

[gouessej]

Once you're ready, you can move onto game development with a library like LibGDX.

LibGDX has an excellent GUI library, scene2d.ui  It has several backends, I will port the existing JOGL 1 backend to JOGL 2.0, probably next month.

If you can live without a working full screen mode, Java2D is enough to learn a few very basic concepts.

[craiten]

Okay, thx guys for the tips!
At first I will start with the JFrame and then I will take a look on LWJGL.
That's a good way I think.

Wish me luck! 

[SHC]

See http://code.google.com/p/game-engine-for-java/source/browse/src/com/gej/core/GWindow.java

[gouessej]

See http://code.google.com/p/game-engine-for-java/source/browse/src/com/gej/core/GWindow.java

Your source code just uses plain software emulated full screen mode and exclusive full screen mode if available. Have you read what we already wrote?

[nsigma]

that was why I used simulated full screen mode until it stopped working under GNU Linux with KDE 4.

Slight OT - is actual (not simulated) FSEM still broken under KWin?  Things seem fine here on the dark side (Gnome / Unity).  This still stuck in an argument over how the NetWM hints are meant to work?

[SHC]

See http://code.google.com/p/game-engine-for-java/source/browse/src/com/gej/core/GWindow.java

Your source code just uses plain software emulated full screen mode and exclusive full screen mode if available. Have you read what we already wrote?

However it works for me in Ubuntu, Win 7 and even in OS X.