Nex Gen LWJGL Applets!

[kappa]

@brackeen

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.

Agreed, one of the main reasons to have the first few screens was the “Trust Dialog Box” that pops up. I don’t think it leads to a nice user experience if, as soon as the page loads that trust dialog pops up. Hence the play button, so that the user knows why its there and more likely to click yes. Second screen is needed to get rid of the ugly grey applet box, the remaining could easily be changed. Think oNyx’s post looks like a great solution to remedy this.

@oNyx

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.

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.

oNyx that looks like an awesome solution to streamline it into a smooth loading process, would also get rid of seeing a lagged ajax loading gif which happens atm when jvm starts.

[kappa]

@quixote_arg

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

Sounds like an error in the game code, hopefully not an applet issue, get any output on console?

@Niwak

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…

1. those area’s should be blank, guess they should be cleared or overwritten when window is switched, again game code issue and not applet, but thx for pointing it out
2. yeh sorry about that as an alternative to WASD movement you can still use the cursor keys to move around.

@Abuse

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.

Not sure lwjgl has multiple monitors support yet, will ask one of the lwjgl dev’s.

@irreversible_kev

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.

Yup looks like behavior of the new Java N plugin, great stuff comming with the new Java Plugin, guess they still have some issues but they are fixing them pretty fast. Using the new “seperate_vm” parameter here, since we load native files with lwjgl, starting a new VM allows to load same natives multiple times on different vm’s.

[Riven]

I thought you cuold influence tthe target monitor by Display.setLocation(x, y), and IIRC it picked the ‘nearest fit’

[kappa]

@Riven

I thought you cuold influence tthe target monitor by Display.setLocation(x, y), and IIRC it picked the ‘nearest fit’

hmm… would that work if you have a Display.setFullscreen(true) set?

[kappa]

@Markus_Persson

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

@Orangy Tang

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.

@tom

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:
Firefox, 2.0.0.14, Windows XP

That sounds like a distrubing bug, could be a number of isses, which graphics cards are you on?
Could also be due to caching problem, since its run from cache after first run, can you delete the cache and see if it works again, its located in the temp folder getProperty(“java.io.tmpdir”). So should be under “(temp folder)/kappa.javaunlimited.net/betashot” just delete the folder.

[quixote_arg]

@kapta

Sounds like an error in the game code, hopefully not an applet issue, get any output on console?

Nothing on the console… I played it on Windows and it worked ok. It seems that the code that makes the big boss ship flash when it’s hit is messing up somehow in linux

[kappa]

@quixote_arg

Nothing on the console… I played it on Windows and it worked ok. It seems that the code that makes the big boss ship flash when it’s hit is messing up somehow in linux

hmm could be a video driver bug or something, whats gfx card and driver are you using?
Same flash effect is also used when your ship is killed and respawns white, does that bit work for you?
btw game was made on linux, so works fine for me here

[Orangy_Tang]

@kapta

That sounds like a distrubing bug, could be a number of isses, which graphics cards are you on?
Could also be due to caching problem, since its run from cache after first run, can you delete the cache and see if it works again, its located in the temp folder getProperty(“java.io.tmpdir”). So should be under “(temp folder)/kappa.javaunlimited.net/betashot” just delete the folder.

Graphics card is a 6800 Ultra.

Closing FF and trying again results in the same exception. Closing FF, deleting the cache dir and trying again does work. Oddly, trying to delete the cache with FF still running (but the applet not running) fails as FF still has file locks on the cached files (something to do with the VM still existing while FF is open?).

Java version 1.6.0_03-b05.

[kappa]

@Orangy Tang

Graphics card is a 6800 Ultra.

Closing FF and trying again results in the same exception. Closing FF, deleting the cache dir and trying again does work. Oddly, trying to delete the cache with FF still running (but the applet not running) fails as FF still has file locks on the cached files (something to do with the VM still existing while FF is open?).

Java version 1.6.0_03-b05.

k thx for that, does look like some sort of caching issue, will investigate this tonight, hopefully its not something to do with files being locked by OS so that they can’t be accessed a second time.

and yes the vm does continue to run on once an applet is started and closed, it only shuts down once browser is shutdown also the reason why if you reject a certificate you have to restart browser to be able to accept it again.

[Riven]

If everything else fails, you can make dynamicly randomize the URLs like: mylib.dll?random=1237856892375 (timestamp)

That way it will never use the cache, but I don’t know whether it interfers with System.load(…)

[wazoo]

Very good work, and a great showpiece for the new capabilities of LWJGL!

(I only saw the progress meter, then just a blank screen. I accepted the cert, but I blame our extremely restrictive corporate firewall…I’ll try this again from home)

I love it, and my immidiate free time is now going to be spent on getting something as cool mocked up on my site!

Kudos!

[oNyx]

A shiny diagram of the loading sequence:

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

(click to enlarge)

Accordingly to that paper (I mentioned earlier) it’s absolutely fine if the progress bar stalls for a bit at the beginning. In this case it’s the startup phase of the VM. Absolutely nothing will happen there for a few seconds, but that’s alright.

The downloading will typically take longer (especially with slower connections) than the actual loading. So, it would be a good idea to use a 60/40, 70/30 or even a 80/20 percentage split (instead of a default-ish 50/50 one). Accordingly to that paper (again) it feels subjectively faster if the progress bar speeds up towards the end.

[brackeen]

[quote]oNyx that looks like an awesome solution to streamline it into a smooth loading process, would also get rid of seeing a lagged ajax loading gif which happens atm when jvm starts.
[/quote]
I agree - looks good, oNyx!

[quote]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.
[/quote]
Ok so I deleted /tmp/kappa.javaunlimited.net and I was able to run again (and I tried fullscreen this time, and it worked very smoothly - great work!). However, the same problem occurred after that - I have to delete that tmp folder in order to play again.

[DzzD]

works excellent on IE 6/WinXP AMD 1.7GH ATI X800 85 fps windowed and fullscreen.

[Riven]

First time load:

Vista, IE 7, ATI HD2400 PRO

After 75% of the progressbar, the applet turns black.
When going to the desktop and back, I can still see my desktop where the applet is supposed to be (so, no framebuffer update at all!)

[kappa]

@Riven

First time load:

Vista, IE 7, ATI HD2400 PRO

After 75% of the progressbar, the applet turns black.
When going to the desktop and back, I can still see my desktop where the applet is supposed to be (so, no framebuffer update at all!)

got any output or exception on the console? also which java version are you on? thx

[kappa]

@bobjob

looks really cool but got some error output in the console
org.lwjgl.LWJGLException: Parent.isDisplayable() must be true

thx for trying, did it continue to work as expected for you despite that exception?

[Riven]

Kinda unnocent looking Exception

Wed Apr 23 20:24:04 CEST 2008 ERROR:Unable to determine Slick build number
Wed Apr 23 20:24:05 CEST 2008 INFO:Starting display 640x480
Wed Apr 23 20:24:05 CEST 2008 ERROR:Resource not found: org/newdawn/slick/data/default_00.tga
java.lang.RuntimeException: Resource not found: org/newdawn/slick/data/default_00.tga
	at org.newdawn.slick.a.g.a(Unknown Source)
	at org.newdawn.slick.c.b.a(Unknown Source)
	at org.newdawn.slick.m.<init>(Unknown Source)
	at org.newdawn.slick.m.<init>(Unknown Source)
	at org.newdawn.slick.m.<init>(Unknown Source)
	at org.newdawn.slick.m.<init>(Unknown Source)
	at org.newdawn.slick.a.<init>(Unknown Source)
	at org.newdawn.slick.c.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.newdawn.slick.k.<init>(Unknown Source)
	at org.newdawn.slick.p.j(Unknown Source)
	at utils.a.a(Unknown Source)
	at utils.f.a(Unknown Source)
	at utils.d.run(Unknown Source)
EXITED MAIN GAME LOOP
Display.destroy() called

[Riven]

Bah, I can’t edit my posts…

Java version: 1.6.0_05

[kappa]

k, thx for that will have to get a non proguarded version up, to see where its failing.