[java] wanna break away from doing applets

If your using JApplet and the user has the latest jre then all of your drawing operations will be using hardware accelerated blitting if you use BufferedImage or VolatileImage and it can. I can get 100+ fps with a 400x400 JApplet. EDIT: So no, I don't think using an app instead of an applet will be faster if you use the latest features. But I haven't tested this to be sure so don't flame me.

This link has a very good sample of using fullscreen.



[edited by - nonnus29 on December 31, 2003 5:59:10 PM]

Running application without a browser in background is certainly faster and safer way. No sandbox is price for it. Applications are cute offline.

quote:

---

Original post by Raghar
Running application without a browser in background is certainly faster and safer way. No sandbox is price for it. Applications are cute offline.

---

Applications are cute? Huh?

Applications are definitely better for games, as you get to actually go into fullscreen mode. Plus its easier to invoke the Server VM which gives you more speed (pass -server flag).

There seems to be a problem with This article. Whenever I alt+tab out of the full screen it''s unable to get back running. How do I fix this?

This is a link that you might find useful. I''ve only got 1.4.1 on OS X, so this bug still exists.

quote:

---

Original post by NuffSaid
This is a link that you might find useful. I''ve only got 1.4.1 on OS X, so this bug still exists.

---

I missed the useful part of that link

Its useful, as it stops you from banging your head against the wall At least you know it isn''t something you''re doing wrong and you get to point the finger elsewhere

I think I know the problem.. I just think I got some names wrong, but when you alt+tab it''s losing it''s surfaces, any way to restore the surfaces?(maybe recreate the windows, if it''s this what message is posted when the app regains focus?)

Take a look at the WindowFocusListener and the corresponding addWindowFocusListener methods that are available in JWindow/JFrame/Frame/Window/etc.

You might want to head over to Javagaming where there is a much more active community of Java game developers.

edit: The SDK documentation on VolatileImage seems ot be very helpful in this regard. In the code you are working with, the moment the contents is lost, you just forget about it. However, in the SDK example, you are meant to recreate the scene after testing if the volatile image has been restored.

So to modify the code in the article, you draw the scene if the contentsLost is false, or if contentsRestored is true (i.e. the buffer has been reinitialised into a blank white state).

Here's the modified version of the code in the article.

private void render()
   {
 // If we've lost our video memory, don't bother drawing anything

 
 if( !bufferStrategy.contentsLost() || bufferStrategy.contentsRestored() )
 {
    Graphics g = bufferStrategy.getDrawGraphics();
 
    // Clear the drawing buffer to white

    g.setColor( Color.white );
    g.fillRect( 0, 0, ScreenWidth, ScreenHeight );
 
    // Say hello

    g.setColor( Color.black );
    g.drawString( "Hello World!", i, i );
 
    // We'll stop after 400 frames.

    i++;
    if( i > 400 )
  Running = false;
 
    bufferStrategy.show();
    g.dispose();
 } 
   }
 

Note: I can't seem to test this on OS X as I can't seem to command-tab out of a fullscreen app.

[edited by - NuffSaid on January 5, 2004 7:13:45 PM]

quote:

---

Original post by NuffSaid
Take a look at the WindowFocusListener and the corresponding addWindowFocusListener methods that are available in JWindow/JFrame/Frame/Window/etc.

You might want to head over to Javagaming where there is a much more active community of Java game developers.

edit: The SDK documentation on VolatileImage seems ot be very helpful in this regard. In the code you are working with, the moment the contents is lost, you just forget about it. However, in the SDK example, you are meant to recreate the scene after testing if the volatile image has been restored.

So to modify the code in the article, you draw the scene if the contentsLost is false, or if contentsRestored is true (i.e. the buffer has been reinitialised into a blank white state).

Here's the modified version of the code in the article.

private void render()
   {
 // If we've lost our video memory, don't bother drawing anything

 
 if( !bufferStrategy.contentsLost() || bufferStrategy.contentsRestored() )
 {
    Graphics g = bufferStrategy.getDrawGraphics();
 
    // Clear the drawing buffer to white

    g.setColor( Color.white );
    g.fillRect( 0, 0, ScreenWidth, ScreenHeight );
 
    // Say hello

    g.setColor( Color.black );
    g.drawString( "Hello World!", i, i );
 
    // We'll stop after 400 frames.

    i++;
    if( i > 400 )
  Running = false;
 
    bufferStrategy.show();
    g.dispose();
 } 
   }
 

Note: I can't seem to test this on OS X as I can't seem to command-tab out of a fullscreen app.

[edited by - NuffSaid on January 5, 2004 7:13:45 PM]

---

Sorry for taking a while to reply to this, but I do that, and it becomes responsive again, but won't paint anything :/, anyhow thx for the help you've been so far.

EDIT: It works perfectly if you remove the if statement altogether..

[edited by - eedok on January 8, 2004 12:59:15 PM]

When you remove that statement, does it still consume loads of CPU time even after you''ve tabbed out?

quote:

---

Original post by NuffSaid
When you remove that statement, does it still consume loads of CPU time even after you''ve tabbed out?

---

Nope, but it''s not doing a whole lot in the first place, I think I''ll just make a boolean that goes to false when focus is lost and true while it has focus..

Ah well. As long as it works :D

I got another problem with that source, when I run it on this(my schools) computer.. It has this error and doesn''t do anything.

java.lang.InternalError: Could not get display modes
at sun.awt.Win32GraphicsDevice.enumDisplayModes(Native Method)
at sun.awt.Win32GraphicsDevice.getDisplayModes(Unknown Source)
at Test.bestmode(Test.java:32)
at Test.(Test.java:50)
at Test.main(Test.java:27)
Exception in thread "main"

There seems to be a problem with the Java VM itself. Are you using the latest version in school? What video card is the machine using and are you using the latest drivers?

If you''re feeling generous and have some time, try isolating out when the bug appears. Then file a bug report at BugParade

Found the line that''s killing it..

DisplayMode[] modes = gd.getDisplayModes();