Fullscreen mode on Linux

Java 2D
#1

I have my game running in fullscreen mode fine on OS X and Windows, but I’m having trouble on Linux.

on Windows, I call GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDisplayModes() to get the available options for display modes, and I pick the one I want from the list by chosing an arbitrary resolution and color depth via a GUI I’ve made. So I can pick 1024x768 and 8 bit color if I want, or 800x600 with 32 bit color, or whatever is available.

On my tests on two comps running Fedora using
GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDisplayModes() only returned to me the current DisplayMode, and with the color depth as BIT_DEPTH_MULTI.
I KNOW that it supports plenty because the monitor was one of those 32" ones with the display up to 1600x1200. However it only gave me that one. That’s like… so useless. Even if it supports multiple bit depths, how can I specify to it what I want to use?

I want to get all the available screen setup options I can get… but the method I mentioned above isn’t giving them to me. What can I do? By the way this was on 1.4.2_03

#2

The fullscreen mode (and changing the display modes) is not supported on linux/solaris yet (as of 1.5). It will be supported in the next release, see rfe
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4661156

(it should be updated in a couple of days with some new info)

Unfortunately for now you can only use the emulated fullscreen mode: borderless frame resized to fill the whole screen (that’s what you’ll get if you call GD.setFullscreenWindow() on linux / solaris)…

Alternatively, run your game in windowed mode on platforms which do not support fullscreen/display mode change.

#3

You might want to check if enabling hw acceleration (I’m assuming you mean the hw compositing and accelerated translucen images) would help your app- just run it as an application with the flags enabled (see the page above on how to make sure webstart picks up your property - set _JAVA_OPTIONS env. variable)…

To see what loops are being used, enable logging: -Dsun.java2d.trace=help (see the page for more details).

#4

[quote]that’s what you’ll get if you call GD.setFullscreenWindow()
[/quote]
That’s what I’m currently doing.

[quote]see the page above on how to make sure webstart picks up your property
[/quote]
What page above? I’ve been wanting to know how, but according to other posts on the forums, it can’t be done because the Webstart loader initializes AWT so you can’t do it and that’s why a bug report has been submitted for it.

#5

Duh! I’ve replied to too many threads today, forgot where I saw the link:
http://java.sun.com/j2se/1.5.0/docs/guide/2d/flags.html

#6

[quote]The fullscreen mode (and changing the display modes) is not supported on linux/solaris yet (as of 1.5). It will be supported in the next release, see rfe
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4661156

(it should be updated in a couple of days with some new info)
[/quote]
(the update appears to have happened already - there’s lots of paras about the VidMode extension and how it will be used.)

It’s great news that at last something is being done (how much bad press has this generated for Sun? Everytime the marketeers touted fullscreen mode, more and more developers discovered it was windows-only). HOWEVER … two scary thoughts:

  1. By “next release” do you seriously mean 1.6, i.e. not until 2007? What’s the point even bothering if it’s going to be that long? Those of us developing java games on linux will either have switched OS or simply stopped using j2d entirely (in favour of anything, whether that’s LWJGL or anything else) because “it’s so crap it can’t even do fullscreen mode” (I’m guessing that will be the most frequently-phrased way of putting it, fairness aside!). I understand the need to prioritize development, and that every RFE is wanted ASAP by someone, but this makes java look really bad in gaming circles.

Developer: “Yeah, you should move over to java, it’s WORA, saves you all those porting costs for your games”

Publisher: “Great. So, let’s see your demo running on linux and OS X to prove it”

D: “Um, actually, no. It can’t cope with an OS that’s been around for longer than the language has. Um. But it really IS better than C++ at x-platform development, I promise!”

P: “BS. Come back when you’re ready to write your game in C++”.

  1. The XFree86 authors and/or nvidia (and presumably ATI too?) are pushing everyone on linux towards Xinerama, (whether you want to go that way or not - I didn’t, but now I have to for my multi-monitor support) and the bug report says that Xinerama won’t be supported. If it’s a case of “without Xinerama, we can have this in a gold JVM by Q2 2005” then OK. But if it’s going to be two years or more anyway, then how can we kick Xinerama out?

What was the first thing I was going to do when fullscreen mode appeared on linux? Write a multi-headed game, able to work on almost every nvidia or ati or matrox card sold in the last 4 years, as an excellent demonstration of the superior java API’s that make it trivial to use the latest greatest features for games.

Again, I appreciate that the number of people with more than one monitor is a minority. However, I suspect it’s actually higher than received wisdom suggests - it’s just that most people have no incentive to connect up the second monitor (from the PC they bought 3 years before their current one, which is now gathering dust because it’s running windows 98 or ME and is too slow). It’s up to devleopers to give them the incentive, but it’s up to Sun to enable the developers to do this.

#7

As wonderful as this is, I think it is important to prioritize… Linux is not a popular gaming platform. It’s as simple as that. Heck try to go the store to get a game for a PC in general these days and you are directed to the back corner. If it is a game for a non-Windows OS then don’t even bother going in the door. If a game isn’t on a console it gets little attention, with the exception of the big names, like Doom3, HalfLife 2,etc…

Can we honestly justify Sun spending much effort on fullscreen support for Linux when it is just us programmers that will ever run it?

Specially after reading all the different ways that the Linux folks have painted themselves into a corner by using X-windows which can’t decide how to do it right in the first place… VidMode, Xinerama ?? and the next 10 conflicting APIs that the Linux haxors will spit out next month.

It will take till 2007 before it is clear what API is going to actually be supported well on Linux in the first place. From my observations I conclude that graphics in general on a Linux box is a bag of tricks… let it settle down and by then Linux might have stable support that makes it worth it.

This response is not an attempt to bash Linux. I’m just trying to be practical

#8

I don’t know, but … Sun is somewhat in the position of being a market-maker here. By making this pre-existing feature actually work they enable x million programmers to write attractive games on linux without switching to OGL or similar, which could give enough of a kick to a virtuous circle to help commercial linux game sales take off.

But I think the bigger concern is the extent to which the windows / linux disparity makes a very obvious and visual mockery of the WORA claims. If you ignore fullscreen mode, then (bugs aside) java 1.4 has finally laid to rest the demons of the “write once, write workarounds everywhere” accusations. But the disparity continues to be a PR problem.

Sure. Likewise, I don’t know how important this ought to be to Sun, but I had thought it would be important enough to be added in 1.5. So I’m just questioning whether it will be 1.5 or not, and if not whether that really is wise…

It really depends what the alternatives are. For instance, an incrementally installing JVM is 10 times more important to get games developers taking java seriously, and a console JVM is 10 times more important than that. But, if both those things were to go ahead anyway (or not) independently of this one, then it becomes worth looking at this, particularly in light of the embarassing flagrant breach of WORA.

#9

[quote]…particularly in light of the embarassing flagrant breach of WORA.
[/quote]
I guess I just don’t see it as that. Just because the Fullscreen APIs actually have a built-in work around so that the code will still run on Linux. Better support is always good. But in this case they at least did something to keep the code running.

#10

What is this workaround? How can I use it? I still face the same problem where it in fact does NOT work on Linux, so please let me know how I can use it.

#11

I was referring to the fact that it is emulated with a window the size of the display placed above the other windows. At least that’s what I’ve read here and elsewhere. I don’t often run linux.

#12

My tests on Windows and Mac run fine. My tests (on 3 different Linux machines) result in the program displaying a full screen of gray, then locking up. You can switch back and forth between programs, but any time you go back I get nothing but a frozen program. I haven’t run it yet with the console up. That’ll be what I do tomorrow when I have more time on one. This was just for me leaning over peoples’ shoulders saying, “hey can I try something?” and putting in my URL :slight_smile: But yeah, whatever shows up in the console, Java most certainly does not have a nice way of covering the problem for me. It only crashes.

#13

It should work in linux with the fullscreen window thing, but there are many downsides. Basically, an app that thinks it is fullscreen will often do things like capture (steal) mouse and keyboard events - yet you are still in a window, and this sometimes means you cannot escape from the window back to your OS. You can see your start bar (yes, the window is a “real” window, so it does NOT overprint the start bar; fortunately, this is not DirectDraw, so we don’t get the flickering, but all those games DO have a big bright startbar at the top you can’t get rid of unless you change your OS settings to auto-hide it, which ahs problems of it’s own), but you can’t move the mouse to it, and sometimes can’t alt-tab either IIRC.

So, all in all, it’s a cheap tacky hack that sounds OK, normally works, but looks terrible on a lot of machines, and several games I’ve played have naively acted as if they were fullscreen and just made life a mess for all concerned.

So…it’s really rather crummy at the moment. Not that I think you could do any better without actually going fullscreen…

#14

[quote]It should work in linux with the fullscreen window thing, but there are many downsides. Basically, an app that thinks it is fullscreen will often do things like capture (steal) mouse and keyboard events - yet you are still in a window, and this sometimes means you cannot escape from the window back to your OS.
[/quote]
Why not? Surely you would use the same operation that you would have used to exit full-screen mode and return to the “OS”.

[quote] You can see your start bar (yes, the window is a “real” window, so it does NOT overprint the start bar;…
[/quote]
Irritating, sure, but not a show stopper.

[quote]and several games I’ve played have naively acted as if they were fullscreen and just made life a mess for all concerned.
[/quote]
What sort of mess ? They SHOULD be acting as if they were full screen. But that shouldn’t cause problems. Is it the way the input devices interact with the window manager?

[quote]Not that I think you could do any better without actually going fullscreen…
[/quote]
Well there you go then. If that is true, I don’t blame Sun at all… it is the Linux developers that have to un-botch the fullscreen situation with Linux/X-Windows. I recall that the Java guys were here two years ago asking for good solutions to the problem, but there were all sorts of issues - like needing admin/root access or other incompatibilities. X-Windows was never designed for this sort of thing and it shows like a big zit that’s ready to pop.

#15

Is there a way to ask the OS the size and position of the start menu bar thing? Or the equivalent ones in different OS’s? If I can’t do FullScreen for real, and I let people use the hacky version on Linux, I’d like to resize my screen to not extend past that bar so that you can see the rest of the screen. Is there something to help me with that?

#16

[quote]Is there a way to ask the OS the size and position of the start menu bar thing? Or the equivalent ones in different OS’s?
[/quote]
Yes. check the javadocs

http://java.sun.com/j2se/1.5.0/docs/api/java/awt/GraphicsEnvironment.html#getMaximumWindowBounds()

#17

[quote]I’d like to resize my screen to not extend past that bar so that you can see the rest of the screen.
[/quote]
That’s what it does automagically - leaves the start bar showing - at least on IceWM. Now, what happened to that RFE for a forum dedicated to x-platform issues ;P?

#18

Sorry, I meant stuff like:

  • you can see the start bar + button, but you cannot click on it, and pressing “start” key on kb has no effect
  • you can’t alt-tab out of the windowed game; in fullscreen, capturing alt-tab is not too surprising - in a windowed game, it’s disturbing to see your other apps on the start bar but be unable to reach them!
  • games that crash in pseudo-fullscreen sometimes seem to be crashing because it wasn’t true fullscreen (unconfirmed - I just have vague memories of finding crashes that authors later claimed to be related to the not-true-fullscreen status; this was probably largely a video driver problem, if true?).
  • games that crash in pseudo-fullscreen (for whatever reason) often leave the screen a grey or black rectangle with the start bar showing but input still captured, so you can see the start bar but cannot get to it to kill the application - and the only way out is to be a linux expert and know you can ctrl-alt-f2, login on a separate text terminal (assuming your distro configures more than one of these by default, otherwise you are simply f***ed at this point…), ps -A to find the JVM, then manually kill it from the terminal, then ctrl-f7 to jump to the special pseudo terminal that is where X is running, and get back to your desktop.

NB: I know that in theory fullscreen mode is literally just a fullscreen window with a tiny bit of magic to tell the OS that this particular fullscreen window requires the non-painting of the OS stuff, unlike regular fullscreen windows (more “full desktop” than “fullscreen”). It just seems sometimes that there is a bit more of a difference than that.

#19

Heh, I wish everything else worked like IceWM then. I don’t know what that is, but so far I haven’t had anything but a gray screen with no escape but to reboot or jump to another terminal to kill the process.

#20

I consider Java as a really good alternative and very attractive as a gaming platform.
As i could see on the last Game Developer Conference, developers are taking seriously to develop using java technology.
Just consider current OpenGL (JOGL, lwjgl, …) and OpenAL libraries, search some development projects and you’ll find arcades, 3d, MMRPG. i.e. Quake ports to Java that run smoothly using acceleration features.
Just because Java is only the language, the technology beneath is the hardware through those libraries, same as C++.
What else ? Those games I mention easily implement multiplayer features, they work on all platforms, they can use upgrading tools such a Java Web Start, and so on.
Additionally, Java is becoming an standard on mobile gaming devices for similar reasons.
I think you’re wrong if you consider games will still be done on C++ two years from now, and considering gaming industry as some of the MOST important (at least for the money involved), GAME DEVELOPMENT on JAVA SHOULD TAKE PRIORITY.
Something else: don’t think on gaming only for a Windows desktop user. Games run on embedded devices such as consoles, entertainment machines, …
Well, I have seen Sega runs Windows on Daytona USA, but I think PS2 uses Linux on some of their development process, and with the proper support Linux can run on those devices and become a real option through Java.

So let’s Sun support the API and the specs and do the FULLSCREEN feature definitely working on Linux.