Nex Gen LWJGL Applets!

With LWJGL 2.0 beta 1 just released, some truly awesome work has gone into it.

One of the notable new features being the new LWJGL Applets. They were present in previous LWJGL releases but have been completely rewritten and are now much faster, compatible, have better compression and smoother deployment.

However need some testing to iron out any remaining bugs.

below is an example applet

http://kappa.javaunlimited.net/betashot4/betashot.html

  • on the fly fullscreen supported (click blue button in bottom right of applet).
  • all known opera problems have been fixed
  • some macs may have problem with fullscreen (fix being worked on, something to do with crt monitors)
  • above applets has a total download size of about 300kb.

appreciate if you could test (including fullscreen) and report any issues you may have.

Wow, that’s slick. Worked flawlessly in Opera (v 9.25), Firefox (v 2.0.0.14) and IE (v 7) on WinXP here. Fullscreen is slick too. The only oddity was having to accept the certificate twice in Opera, but that’s really minor issue.

Nice to see proper Opera support - that was what was really stopping me using it. What’s the game code for on-the-fly fullscreen like? I assume it’s not reloading all the textures etc. when you switch? Also, I’m guessing you’re a Cave shooter fan. ;D

Display.setFullscreen(true); with a bit of glViewPort settings.

funny you should say that, it is indeed very SLICK

Shhhhhhhh ;D

The new loading bar looks great!

Mac OS X 10.5.2 Intel. However, it only ran the first time. Trying a second time just gave me a black box with 100% CPU. Even if tried a different browser (Safari, FF3) it wouldn’t show again. I didn’t see anything in the Java Cache - is some code cached somewhere else?

Same thing on Windows IE7 with Java 6u10 - the second time, it froze on the indeterminate loading graphic. I had to kill the browser.

The second time in Windows FF3 ran fine.

There are a lot of loading steps - is it possible to cut some of those out? Here’s the current user experience:

  1. See a “play” button, press it.
  2. See a indeterminate loading graphic for a few seconds.
  3. See a “trust” dialog, press “run” or “trust”
  4. See a LWJGL loading bar (looks great!)
  5. See the game’s loading bar.

Wow, that works absolutely beautifully (Windows XP, 8600M GT, FF2). And no issues at all with reloading or switching to fullscreen. I have to say the latter really impressed me. It was just as smooth as switching to fullscreen using flash, and coming from using desktop applications where I usually expect a 2-3 second jarring delay when I swap from fullscreen to windowed or vice versa, I was very happy when I saw how well this worked.

Subsequent load times were just about as fast as flash too, barely (not even maybe) a second on my computer; really quite good demo you have here.

Hopefully you can get this to work just as smoothly on on browsers/platforms. Keep up the good work!

Only one minor gripe with fullscreen mode - it maximizes to the primary monitor, irrespective of which monitor the browser is positioned in.

Still looked very polished though.

Just one more time I’m going time, this is AWESOME! :slight_smile:

Great work Kappa.

Kev

Load perfect on Ubuntu, Firefox 3 beta 5, Java Plug-in 1.6.0_06

But while playing the game, when a big ship comes and I shoot it, the screen goes blank and nothing else happens…

Hangs the second time I tried it. Happened in the first loading screen, after 3 dots showing. Got the following exception in the Java Console:

STARTING DESTROY METHOD
destroyLWJGL() method called
destroyLWJGL() method complete
Wed Apr 23 08:28:46 CEST 2008 INFO:Clear up
DESTROY METHOD COMPELTE
Wed Apr 23 08:29:04 CEST 2008 INFO:Slick Build #173
org.lwjgl.LWJGLException: Could not find a valid pixel format
at org.lwjgl.opengl.WindowsPeerInfo.nChoosePixelFormat(Native Method)
at org.lwjgl.opengl.WindowsPeerInfo.choosePixelFormat(Unknown Source)
at org.lwjgl.opengl.WindowsDisplayPeerInfo.initDC(Unknown Source)
at org.lwjgl.opengl.WindowsDisplay.createWindow(Unknown Source)
at org.lwjgl.opengl.Display.createWindow(Unknown Source)
at org.lwjgl.opengl.Display.create(Unknown Source)
at org.lwjgl.opengl.Display.create(Unknown Source)
at org.lwjgl.opengl.Display.create(Unknown Source)
at utils.f.a(Unknown Source)
at utils.d.run(Unknown Source)
Exception in thread “Thread-35” java.lang.NullPointerException
at org.newdawn.slick.p.a(Unknown Source)
at utils.a.e(Unknown Source)
at utils.f.a(Unknown Source)
at utils.d.run(Unknown Source)

Firefox, 2.0.0.14, Windows XP

This is absolutely impressive (WinXP + Firefox 2.0.0.14) !

Two minor issues ;

  • when switching to fullscreen, I have a bit of garbage above and below the game area,
  • the keyboard input is only suitable for QWERTY keyboards, I have an AZERTY, so…

looks really cool but got some error output in the console

STARTING DESTROY METHOD
destroyLWJGL() method called
EXITED MAIN GAME LOOP
Display.destroy() called
destroyLWJGL() method complete
Wed Apr 23 17:12:29 EST 2008 INFO:Clear up
DESTROY METHOD COMPELTE
Wed Apr 23 17:12:33 EST 2008 INFO:Slick Build #173
org.lwjgl.LWJGLException: Parent.isDisplayable() must be true
at org.lwjgl.opengl.Display.createWindow(Unknown Source)
at org.lwjgl.opengl.Display.create(Unknown Source)
at org.lwjgl.opengl.Display.create(Unknown Source)
at org.lwjgl.opengl.Display.create(Unknown Source)
at utils.f.a(Unknown Source)
at utils.d.run(Unknown Source)
Exception in thread “Thread-53” java.lang.NullPointerException
at org.newdawn.slick.p.a(Unknown Source)
at utils.a.e(Unknown Source)
at utils.f.a(Unknown Source)
at utils.d.run(Unknown Source)
Wed Apr 23 17:12:33 EST 2008 INFO:Slick Build #173
Wed Apr 23 17:12:33 EST 2008 INFO:Starting display 640x480
Wed Apr 23 17:12:33 EST 2008 INFO:Early loading of deferred resource due to req: org/newdawn/slick/data/default_00.tga
Wed Apr 23 17:12:35 EST 2008 INFO:Early loading of deferred resource due to req: data/demo_00.tga
MIDI DISABLED
STARTING DESTROY METHOD
destroyLWJGL() method called
EXITED MAIN GAME LOOP
Display.destroy() called
destroyLWJGL() method complete
Wed Apr 23 17:13:01 EST 2008 INFO:Clear up
DESTROY METHOD COMPELTE

very well done, really smooth and fast after the initial lag, hopefully with the new applet plugin it will be even better :slight_smile:

imo the initial play button is a better user experience than having the applet load (and thus lag the browser) automatically. I got no “trust” dialogs here, i suppose i must have accepted the certificates previously.

on the fly fullscreen supported (click blue button in bottom right of applet).

Awesome shizzle! :o

Mr. Brackeen has a point though. The different loading bars might be a bit irritating for the average user. Well, we know what each of em is good for, but everyone else doesn’t.

An interesting paper on progress bars:
Rethinking the Progress Bar (pdf)

Let’s see… his steps were:

  1. See a “play” button, press it.
  2. See a indeterminate loading graphic for a few seconds.
  3. See a “trust” dialog, press “run” or “trust”
  4. See a LWJGL loading bar (looks great!)
  5. See the game’s loading bar.

We can’t do anything about #3. So, let’s ignore this one.

However, the rest can be seamlessly blended into a single progress screen.

  1. Placeholder:

http://kaioa.com/k/laload1a.png

  1. Placeholder hover:

http://kaioa.com/k/laload1b.png

  1. Switch with:

http://kaioa.com/k/laload2.png

  1. Loading:

http://kaioa.com/k/laload3.png

The download part goes up to… say… 80% and once the game takes over it continues at that percentage. There might be some flicker at that spot, but that’s alright, I would say.

The first 3 images can be put into one image file btw. This gets rid of any load delay.

Worked once (but with low fps… around 25) then:

Wed Apr 23 10:09:24 CEST 2008 INFO:Slick Build #173
Wed Apr 23 10:09:26 CEST 2008 INFO:Starting display 640x480
Wed Apr 23 10:09:26 CEST 2008 INFO:Controllers not available
Wed Apr 23 10:09:27 CEST 2008 INFO:Early loading of deferred resource due to req: data/demo_00.tga
MIDI DISABLED
STARTING DESTROY METHOD
destroyLWJGL() method called
EXITED MAIN GAME LOOP
Display.destroy() called
destroyLWJGL() method complete
Wed Apr 23 10:11:07 CEST 2008 INFO:Clear up
DESTROY METHOD COMPELTE
Wed Apr 23 10:12:09 CEST 2008 INFO:Slick Build #173
org.lwjgl.LWJGLException: Could not find a valid pixel format
	at org.lwjgl.opengl.WindowsPeerInfo.nChoosePixelFormat(Native Method)
	at org.lwjgl.opengl.WindowsPeerInfo.choosePixelFormat(Unknown Source)
	at org.lwjgl.opengl.WindowsDisplayPeerInfo.initDC(Unknown Source)
	at org.lwjgl.opengl.WindowsDisplay.createWindow(Unknown Source)
	at org.lwjgl.opengl.Display.createWindow(Unknown Source)
	at org.lwjgl.opengl.Display.create(Unknown Source)
	at org.lwjgl.opengl.Display.create(Unknown Source)
	at org.lwjgl.opengl.Display.create(Unknown Source)
	at utils.f.a(Unknown Source)
	at utils.d.run(Unknown Source)
Exception in thread "Thread-25" java.lang.NullPointerException
	at org.newdawn.slick.p.a(Unknown Source)
	at utils.a.e(Unknown Source)
	at utils.f.a(Unknown Source)
	at utils.d.run(Unknown Source)

worked great
700-1000 fps
32% cpu

Intel Q6600, Nvidia 8800GTS 320MB
Java 1.6.0_10-beta-b21

Never any exceptions in console

Every refresh loads a new JVM. They do seem to time out though.

For example I refreshed to get 5 JVMs running - each taking approx 60MB. Then within about a minute, only one JVM remains and that is the one currently running the applet.

This is of course only behavior seen using the new plugin.

I get the same as Marcus on my work machine - worked once in FF, then started throwing exceptions in both IE and FF when run for the second time.

Java Plug-in 1.6.0_03
Using JRE version 1.6.0_03 Java HotSpot(TM) Client VM
User home directory = C:\Documents and Settings\xxx


----------------------------------------------------
c:   clear console window
f:   finalize objects on finalization queue
g:   garbage collect
h:   display this help message
l:   dump classloader list
m:   print memory usage
o:   trigger logging
p:   reload proxy configuration
q:   hide console
r:   reload policy configuration
s:   dump system and deployment properties
t:   dump thread list
v:   dump thread stack
x:   clear classloader cache
0-5: set trace level to <n>
----------------------------------------------------

Wed Apr 23 09:43:53 BST 2008 INFO:Slick Build #173
org.lwjgl.LWJGLException: Could not find a valid pixel format
	at org.lwjgl.opengl.WindowsPeerInfo.nChoosePixelFormat(Native Method)
	at org.lwjgl.opengl.WindowsPeerInfo.choosePixelFormat(Unknown Source)
	at org.lwjgl.opengl.WindowsDisplayPeerInfo.initDC(Unknown Source)
	at org.lwjgl.opengl.WindowsDisplay.createWindow(Unknown Source)
	at org.lwjgl.opengl.Display.createWindow(Unknown Source)
	at org.lwjgl.opengl.Display.create(Unknown Source)
	at org.lwjgl.opengl.Display.create(Unknown Source)
	at org.lwjgl.opengl.Display.create(Unknown Source)
	at utils.f.a(Unknown Source)
	at utils.d.run(Unknown Source)
Exception in thread "Thread-10" java.lang.NullPointerException
	at org.newdawn.slick.p.a(Unknown Source)
	at utils.a.e(Unknown Source)
	at utils.f.a(Unknown Source)
	at utils.d.run(Unknown Source)

thx for all the great feedback

org.lwjgl.LWJGLException: Could not find a valid pixel format
	at org.lwjgl.opengl.WindowsPeerInfo.nChoosePixelFormat(Native Method)
	at org.lwjgl.opengl.WindowsPeerInfo.choosePixelFormat(Unknown Source)
	at org.lwjgl.opengl.WindowsDisplayPeerInfo.initDC(Unknown Source)
	at org.lwjgl.opengl.WindowsDisplay.createWindow(Unknown Source)
	at org.lwjgl.opengl.Display.createWindow(Unknown Source)
	at org.lwjgl.opengl.Display.create(Unknown Source)
	at org.lwjgl.opengl.Display.create(Unknown Source)
	at org.lwjgl.opengl.Display.create(Unknown Source)

the above exception when running second time is known, this is due to Display not shutting down properly the first time. It should work second time if you close browser and start it again, working on fix for it.

Kappa has asked me to post my latest prototype as an applet, it has some slightly different code so might work in a few places the other one doesn’t:

http://www.cokeandcode.com/demos/putty3/putty.html

The game is just a WIP so please ignore :slight_smile:

Kev

Heh, I’ve just been reminded, it also might break in other ways. :slight_smile:

Kev

Hmm odd problem that, applet is cached once it is downloaded, so the next time it is run it just loads from cache (could be a corrupt download or something). Code should be cached in the temp directory, think on mac the temp directory is private:/tmp (which is got by getProperty(“java.io.tmpdir”)), so look for something like private:/tmp/domain/gamename, e.g. “kappa.javaunlimited.net” folder in temp directory.