Help with FSEM
burgerm...@gmail.com
Never have posted in this group before. Anyways, I am also somewhat new
at Java (although not totally inexperienced), and I'm trying to make a
sort of monopoly game, and I would like to do it in FSEM mode. However,
getting the basic setup for FSEM is proving to be difficult for me, and
I was hoping someone could tell me what I am doing wrong. I've been
looking at different tutorials, and I got one to work, but when I try
to rewrite the code in the tutorial for my own purposes it doesn't
work. Sooo....first, is the code that works, modified from a tutorial:
http://www.inaneasylum.org/m/MultiBufferTest.java
and here is the code that doesn't work, when I'm attempting to put it
into my own program:
http://www.inaneasylum.org/m/Monopoly.java
Basically what happens is that the program actually goes fullscreen but
just stays a black screen and then the console has these error
messages:
Exception in thread "main" java.lang.IllegalArgumentException: Width
(0) and hei
ght (0) cannot be <= 0
at
java.awt.image.DirectColorModel.createCompatibleWritableRaster(Direct
ColorModel.java:999)
at
sun.awt.image.SunVolatileImage.getBackupImage(SunVolatileImage.java:2
07)
at
sun.awt.image.VolatileSurfaceManager.getBackupSurface(VolatileSurface
Manager.java:229)
at
sun.awt.image.VolatileSurfaceManager.initialize(VolatileSurfaceManage
r.java:91)
at
sun.awt.image.SunVolatileImage.<init>(SunVolatileImage.java:58)
at
sun.awt.image.SunVolatileImage.<init>(SunVolatileImage.java:67)
at
sun.awt.image.SunVolatileImage.<init>(SunVolatileImage.java:78)
at
sun.awt.image.SunVolatileImage.<init>(SunVolatileImage.java:72)
at
sun.awt.windows.WComponentPeer.createVolatileImage(WComponentPeer.jav
a:501)
at java.awt.Component.createVolatileImage(Component.java:3005)
at
java.awt.Component$BltBufferStrategy.createBackBuffers(Component.java
:3542)
at
java.awt.Component$BltBufferStrategy.<init>(Component.java:3528)
at java.awt.Component.createBufferStrategy(Component.java:3248)
at java.awt.Window.createBufferStrategy(Window.java:2216)
at java.awt.Component.createBufferStrategy(Component.java:3188)
at java.awt.Window.createBufferStrategy(Window.java:2191)
at Monopoly.drawStuff(Monopoly.java:71)
at Monopoly.main(Monopoly.java:25)
Anyways, it's probably something really retarded, but I haven't been
able to figure it out after a few days of pulling my hair out, so
hopefully someone here can lend me a hand. TIA!
Roedy Green
quoted :
>I would like to do it in FSEM mode.
What means this word, FSEM?
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.
Roedy Green
quoted :
> at Monopoly.drawStuff(Monopoly.java:71)
Backing up the trace stack, the problem looks to be your code at
Monopoly.java on line 71.
To tell you want you did wrong, we would need to see at least that
class with line 71 marked.
Rhino
"Roedy Green" <my_email_is_post...@munged.invalid> wrote in
message news:emsal1hehvqnensbr...@4ax.com...
> On 18 Oct 2005 12:54:10 -0700, burgerm...@gmail.com wrote or
> quoted :
>
> >I would like to do it in FSEM mode.
>
> What means this word, FSEM?
From the context, I think FSEM is Full Screen something something (Full
Screen Extended Mode?? or something like that).
Rhino
burgerm...@gmail.com
Look again, I have the whole java files for both the working and
non-working code, just click the links. Also, FSEM stands for Full
Screen Exclusive Mode.
Thanks.
Andrew Thompson
> Look again, I have the whole java files for both the working and
> non-working code, just click the links.
Unfortunately, usenet posts can arrive 'late, and out of
posting order'. Further, if a local news-server crashes or
has a hicc-up, the post may *never* appear on that server.
The result is that you cannot presume..
- a poster has seen earlier posts
- a poster will *ever* see those earlier posts
Further, even of the posts arrive, you cannot be sure
- That they were ..
- threaded correctly, or..
- read by the person replying..
As a result of this, I might have responded thusly..
"Missed the links? They were in the first post. They are..
http://www.inaneasylum.org/m/MultiBufferTest.java
and here is the code that doesn't work, when I'm attempting to put it
into my own program:
http://www.inaneasylum.org/m/Monopoly.java"
OK - where was I.. Oh yeah.
I tried your codes and could not reproduce the problem,
..until I realised you had *also* put a main() inside
'Monopoly.java'. When I ran *that* I got the behaviour
you described, and...
My very first suggestion for further investigation of this
problem is that you try running the main() in the other class
and report back to us. See how you go at figuring what you
are doing wrong from that point..
(No, I do not immediately know the answer to your problem,
but I do not have time to check into it at the moment..)
HTH
Roedy Green
quoted :
>Look again, I have the whole java files for both the working and
>non-working code, just click the links. Also, FSEM stands for Full
>Screen Exclusive Mode.
I formatted your code which for some reason came across jumbled. Did
you use tabs?
The problem appears to be here
static Frame mainFrame;
public static void drawStuff()
{
mainFrame.createBufferStrategy(numBuffers);
^^^^^^
bufferStrategy = mainFrame.getBufferStrategy();
You did quite a bit of scary looking stuff to your Frame:
dm = new DisplayMode(800,600,16,0);
try {
numBuffers = 2;
env = GraphicsEnvironment.getLocalGraphicsEnvironment();
device = env.getDefaultScreenDevice();
try{
gc = device.getDefaultConfiguration();
mainFrame = new Frame(gc);
mainFrame.setUndecorated(true);
mainFrame.setIgnoreRepaint(true);
device.setFullScreenWindow(mainFrame);
if (device.isDisplayChangeSupported()) {
device.setDisplayMode(dm);
}
mainFrame.createBufferStrategy(numBuffers);
bufferStrategy = mainFrame.getBufferStrategy();
Some thoughts:
1. Should you not be using a JFrame?
2. why did you call createBufferStrategy(numBuffers)
more than once?
3. this does not look like any Java painting code I have ever seen.
Normally you override paint and trigger repaints. Are you following
some sample code in a book or did you make this all up from individual
methods?
burgerm...@gmail.com
First, as Andrew stated I guess there could have been nicer ways of
referring you to the links already posted. I don't want to sound like a
jerk, or anything, just came out wrong I guess. Anyways in response to
your suggestions...
1. Maybe I should be using JFrames? Like, the tut. I pulled this code
from was using Frames, so I just kind of rolled with that. Really, I
don't even know what the difference between the two, just that JFrame
is newer.
2. I called that function twice basically for experimental purposes,
and I guess I never deleted it. It doesn't seem to change the end
result any though, so...
3. Yea, painting in FSEM is crazy, because you're basically
manipulating the hardware directly rather than allowing the OS to do
it, so like if you tried to use paint or repaint functions it will
actually cause problems. So basically you have to do all that yourself.
In fact, that one line...
mainFrame.setIgnoreRepaint(true);
...prevents repaint from working in the window. Check out some of these
tutorials if you have time:
http://www.daimi.au.dk/~rrs/spilbog/ch3.pdf
http://java.sun.com/docs/books/tutorial/extra/fullscreen/
Hope to hear from you again!
Roedy Green
quoted :
>First, as Andrew stated I guess there could have been nicer ways of
>referring you to the links already posted. I don't want to sound like a
>jerk, or anything, just came out wrong I guess. Anyways in response to
>your suggestions...
It is just so rare for anyone to post code at links that I overlooked
them. We keep asking people to do it, but you are one of the first to
ever comply.
Roedy Green
quoted :
>3. Yea, painting in FSEM is crazy, because you're basically
>manipulating the hardware directly
Hmm. The closest I have come to that is using VolatileImage. I am not
at all familiar with FSEM mode. I have seen newbies concoct some
pretty elaborate Rube Goldberg painting machines by gluing together
various methods without ever reading about how all the methods are
supposed to fit together. I wanted to make sure you were not doing
that. Your code looked pretty strange.
Thomas Weidenfeller
> Basically what happens is that the program actually goes fullscreen but
> just stays a black screen and then the console has these error
> messages:
>
> Exception in thread "main" java.lang.IllegalArgumentException: Width
> (0) and hei
> ght (0) cannot be <= 0
> at
> java.awt.image.DirectColorModel.createCompatibleWritableRaster(Direct
> ColorModel.java:999)
This repeated code fragment in your initializeVars() method resets to
normal window mode fare before you even start to draw something:
>
> } finally {
> device.setFullScreenWindow(null);
> }
May I suggest that you familiarize yourself with the working of finally
and compare your usage very closely to the original from which you claim
you have copied things.
/Thomas
--
The comp.lang.java.gui FAQ:
ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq
http://www.uni-giessen.de/faq/archiv/computer-lang.java.gui.faq/
Oliver Wong
"Roedy Green" <my_email_is_post...@munged.invalid> wrote in
> On 18 Oct 2005 22:53:07 -0700, burgerm...@gmail.com wrote or
> quoted :
>
>>3. Yea, painting in FSEM is crazy, because you're basically
>>manipulating the hardware directly
>
> Hmm. The closest I have come to that is using VolatileImage. I am not
> at all familiar with FSEM mode. I have seen newbies concoct some
> pretty elaborate Rube Goldberg painting machines by gluing together
> various methods without ever reading about how all the methods are
> supposed to fit together. I wanted to make sure you were not doing
> that. Your code looked pretty strange.
For what it's worth, when I write games in Java, I usually also use
setIgnoreRepaint(true) and do the repainting manually. When writing
traditional GUI apps, usually something happens, then you trigger a repaint.
In games, usually time passes, and you have figure out whether something
happened or not, and you repaint regardless.
- Oliver
burgerm...@gmail.com
blocks or error handeling in general or anything like that, I was just
copying that blindly, and see, the original code basically called the
constructor which would try and draw flashing colors on the screen
using a for loop, and then of course it would hit that finally block so
that the window would close down. I overlooked that null in there, so
yea, that problem is taken care of, but this stupid thing is still
crashing. I'm thinking about messing around with this for another
couple of days and if I still can't get it to go, then I'll just do
everything out of a constructor like the working code does, which is
obviously horrible form but...at least it will work then!
Thomas Weidenfeller
May I suggest that you learn to use a debugger?
burgerm...@gmail.com
you're using Frames, you *have* to work out of the constructor. Why
this is...I'm still not sure, but it does work. So, to any other newbs
like myself, that might stumble across this thread -- if you're using
FSEM and you are using Frames, you have to do everything in the class
constructor that is enabling full-screen mode.
Persistant link with examples:
http://java.sun.com/docs/books/tutorial/extra/fullscreen/