So now that 1.4.1_02 is out, it’d be great if you guys would report any new issues/problems you found, and if it helped with the old ones.
The sooner we find out about problems, the better.
Known issues (off the top of my head): deadlock in fullscreen, crashes during alt+tab on some boards. There’s also a bug with JavaWebStart on intel i815 boards on WindowsXP, which could cause system reboot (fixed in XP ServicePack 1).
Thanks in advance.
Is/can/will fullscreen work for win2k in the future? I’ve heard from a few people (me included) that isDisplayChangeSupported() returns false. I haven’t really looked into this since I’m busy with other things, but I find that kinda sucky.
Look in the java sound thread - 1.4.1 broke something (that worked in 1.4.0) and it still is not fixed in _02…
so far i’ve heard good things about fullscreen in _02. people who couldn’t get fullscreen to work on their machines on earlier versions are now having no problem. yay, sun.
the deadlock problem, tho… bummer. i’ve seen this on a couple machines. by the way, you guys should go vote for this deadlock bug:
http://developer.java.sun.com/developer/bugParade/bugs/4826573.html
hopefully a fix for it will be trivial… here’s looking to _03.
bedelf, the fullscreen is supposed to work on w2k. We haven’t had any complaints other than known bugs .
If that method retunrs false, it could be because of your configuration, or a bug in our code. Please post your system information - OS version, service packs, drivers, video board etc. A test would be nice, too - in case there’s something wrong with your code.
just win2k, service pack 3 (nothing else), version: 41.09 (i thought i was using the certified ones but i guess these arent) detonator for a geforce2mx
im just doing
GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().isDisplayChangeSupported()
not exactly that of course, but that’s it in a nutshell, all defaults.
[quote]just win2k, service pack 3 (nothing else), version: 41.09 (i thought i was using the certified ones but i guess these arent) detonator for a geforce2mx
im just doing
GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().isDisplayChangeSupported()
not exactly that of course, but that’s it in a nutshell, all defaults.
[/quote]
My understanding is that displayChangeSupported() returns false until you are in fullscreen mode, only then will it tell you whether you can change the resolution or not.
Incidentally, IMHO this is abit of a flaw in the api, for example :-
You want to write an app. that runs in a specific screen area. e.g. 800x600.
Also, if possible, you would like to use fullscreen, otherwise use an 800x600 window.
With the present api, to achieve this, you have to do the following…
it would be much nicer, if we could have a DisplayCapabilities type mechanism
(where by you request a displaymode that fits a certain set of requirements e.g. resolution, bitdepth, fullscreen, HW-accelerated etc etc)
Oh. I guess I assumed (mother of all fuckups) that you could check to see if a display change was viable before acually DOING anything.
You see this in the docs: Returns true if this GraphicsDevice supports low-level display changes.
Which is probably why I skipped over the few lines down from that: whether low-level display changes are supported for this graphics device. Note that this may or may not be dependent on full-screen exclusive mode.
I guess I didn’t puzzle out that you would have to set a full screen window BEFORE checking that, even if I did read it. Again, assuming things is bad.
Worst is, I wrote my code a long time ago and when I came back I looked all of that over and STILL didn’t catch it. Seeing what I want to see I spose. Certainly explains alot of my problems. 
And yeah, I could consider that a flaw in the API, but I really haven’t a clue what they can or can’t do. I’m not much of an engineer or care enough to try to be one.
I’m going to have to update my share code thread. 
This is strange, I keep ending up in a white fullscreen window.
So I ran the MultiBufferTest from the tutorials, and it worked, then I ran it again, and got the white fs window again.
I tested to see what display mode multi was trying to use and it was the same one I’m using. And it worked… once. My code is nearly identical but I can’t even get the example to work correctly.
So I think ima give up on this for now unless someone can tell me whats going wrong here.
the white fullscreen window is probably caused by the new deadlock bug that appeared in _02.
http://developer.java.sun.com/developer/bugParade/bugs/4826573.html
Yeah I realized that might be the case after I posted, (wasnt thinking, tired) but I just went to sleep. hehe.
Ok now I can enter fullscreen again with the workaround but I cant exit right.
I can get it to just plainly leave fullscreen without errors, but my fullscreen/windowed switching code needs to dispose the window and resize and other things before creating the bufferStrategy which the deadlock bug seems to HATE no matter what I do.
Whatever, back to waiting for a new version.