LWJGL Applet Demo

I’m currently running a feasibility test to see how compatible OpenGL (via LWJGL) applets are with a wider audience.

Applet (Click to Play)
NLA

WebStart (Reference)
NLA

Tell me the following.

  1. Does it work?
  2. Are the missile’s animations glitchy?
  3. Report the average framerate. It should be 60 FPS or more.
  4. Tell me these system specs.
  • Operating System
  • Browser(s) and exact versions thereof.
  • CPU
  • RAM
  • Video Card, if you have one
  • Java Version (family is OK, if you are using Update N, tell me the exact build number)

Compare?

How does the following game compare to ours in terms of load time and smoothness? Would you call the experience, Flash-like in this case? (in the good sense)
http://www.pulpgames.net/milpa/

Known Issues

  • Some machines get an inexplicable FPS drop to unplayable levels (30 FPS and below). If you are using Firefox, try Internet Explorer.
  • You may see graphical artifacts in the missiles.
  1. yup!
  2. no
  3. 60
  4. W2K, crud CPU, 4MX, java 1.6.0_03-b05
  1. yup!
  2. no
  3. 63
  4. Linux, AMD Athlon 3000+, nvidia 5900xt, java 1.6.0_03
  1. yup!
  2. no
  3. 60+
  4. Windows XP, 8600GTS, 2GB Ram, E6750, Java 1.6.0_03

Oh, and the loading is no where as neat as the milpa stuff. Not only does it download a lot faster but it also looks neater.

Mac OS X Leopard, Safari 3, Java 1.5, ATI Radeon X1600, Core 2 Duo 2.16Ghz, 2GB

It works, 63 fps. The missile images are missing or distorted after I reload the page, however.

In Safari 3, the game stops when I switch tabs (Safari calls stop() when the user switches tabs, and start() when switching back to the tab). I have to hit reload to continue playing. Sometimes the game reloads, other times only a blank white page appears.

One time I pressed command-T to open a new tab, and the browser crashed.

In Firefox, the game always stays on top, even if a different tab is selected.

Perhaps some of these problems could be avoided if the game was in a pop-up window instead of a normal browser window?

  1. Applet doesn’t work. I get the LWJGL loading image, but it doesn;t progress and when I came back to the firefox tab it was a white screen.
  2. Are the missile’s animations glitchy?
  3. Using webstart, which worked, the frame rate was 380.
  4. Tell me these system specs.
  • Windows XP
  • Firefox 2.0.0.7
  • 3.4 ghz intel with HT
  • 2G RAM
  • Intel integrated
  • Java 6 update N.

The webstart game worked an dlooks really really nice by the way.

the loading can be handled yourself - including fadein. The one thing we cant fix is the very fast loadtimes - because we do bring ~ 1MB in dependencies (can be brought down with obfuscation).

  1. Yep
  2. Nope
  3. 2 - 60 fps for applet reported, in reality I guess it was 0.2 - 60 fps. Typically sort of running fine ~60fps and then freezing up for several seconds quite frequently (100% CPU). This almost certainly because of the known lwjgl - ATI problem. Seemed to be specifically triggered by mouse over applet or key input though. 60-61 fps for WS.
  4. XP, FF 2 & IE 7, 1.8GHz, 2GB, ATI Mob. Radeon 9600, java 1.6.0_03

Mines (?) moved with the ship in applet version and stayed fixed in ws version. Game “ran” while the ATI glitches happened, and if ship was moving when glitch happened then it took a huge leap when game came to life again…

If ship went above the top, it wouldn’t come back again(ws only).

Closest parallax layer is a bit twitchy in between, not reaching up to the same “flash level” as milpa, but never the less it should be able to beat any similar flash game with a bit of effort.

A casual “flash gamer” would never guess that milpa is java, since you never see the java loading animation, (and it looks like a gfx designer made it :)). In stencyl, you are exposed to java animation and two “OK clicks”, that might scare away some customers.

You would loose me on this laptop as a customer, because everything becomes unplayable unfortunately with my gfx card. Would be interesting to know how big percent of possible visitors would suffer from this though.

  1. Yes
  2. No
  3. 60-61fps, rock solid and smooth
  4. XP, Opera 9.24, 2.4GHz, 1GB, GeForce 6800GT, Java 1.6.10 build 07

Had to click “OK” 7 times on scary Opera dialog! Also the applet behaved slightly differently to the webstarted version; when I move up and down in the applet the gidrahs also move up and down, but not in webstart.

Tapping ESC in the applet just exits Opera as if from a crash.

I mustard mitt that seeing an applet running at a cool 60fps makes me think it is time to make Ultratron and Titan into applets.

But overall - the loading experience was pretty grim, applet-wise. Lots of clicks, grey square for too long, “click to use and activate this control” daftness.

I think perhaps we should create the ULWJGL (Ultralightweight) with most of the extensions cut out too to get the payload down to a couple of hundred Kb.

Cas :slight_smile:

  1. Does it work? - yes
  2. Are the missile’s animations glitchy? - no
  3. Report the average framerate. It should be 60 FPS or more - seems locked @ 40 - smooth tho
  4. Tell me these system specs.
  • Operating System - winxp sp2
  • Browser(s) and exact versions thereof. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.10) Gecko/20071115 Firefox/2.0.0.10
  • CPU - x2 3800+
  • RAM - 2gb
  • Video Card, if you have one - 7600gt
  • Java Version (family is OK, if you are using Update N, tell me the exact build number) - Java Plug-in 1.6.0_03

Compare?

How does the following game compare to ours in terms of load time and smoothness? Would you call the experience, Flash-like in this case? (in the good sense)
http://www.pulpgames.net/milpa/

  • load time wasnt too bad, cant really avoid the first applet lag , the screenshot did fool me for a second tho :wink: only 1 click and no grey boxes here either
  • well milpa was alot faster loading, but then i didnt reboot after testing this one so…

latest lwjgl applet code now fixes the applet loading issues that were being experianced before with opera, where it was hanging at 10%.

Also have been on opera’s case about the crash on exit (which is due to opera not closing applets properly) and can confirm that this bug is now fixed in opera 9.5+. :slight_smile:

However opera still use there own version of the java applet plugin, so explains why its still a bit crappy especially with the tons of dialog boxes for signed applets (thats why you should use a real browser like FF ;D), hopefully they will switch to the new java plugin when that comes out, which i expect will fix alot of the applet issues.

Do think ULWJGL is a very good idea, especially for applets as they don’t need any of that native window, keyboard, mouse stuff. As its using AWTGLCanvas and awt for inputs, if ULWJGL with obfuscation does get to a few 100kb would be great for lwjgl applets.

  1. Yep works
  2. No, very smooth,no glitches
  3. 60/61 FPS (both applet and ws).
  4. Windows 2000, Firefox 1.5.0.10, Del Laptop (Intel Pentium, 1.70GHz), 768M Ram

ws loaded in about 45 seconds. + Same problems as reported by others…i.e. Hitting escape in Browser closed down the browser window and applet/ws versions were different (i…e in applet the mines followed ship and in ws version ship could dissapear from top of the screen and doesnt return)…

Overall very smooth, would be great if could get loading times down a little…
Steve

think the escape key browser crash is due the game using a System.exit(0); when escape key is pressed and not a lwjgl applet problem. ;D

AMD XP 2800+ 512MB

[quote=“JonathanC”]
I’ve noticed this with Bloodridge - I think it’s where they’ve got unusual display setups (wide screens, double displays &c)

Regarding ULWJGL: you can already adjust which extensions to generate with the ‘opengl-template-pattern’ ant option to the lwjgl build.xml (remember to clean the old generated files with ‘ant clean’). If you can live with not stripping the natives, proguard should suffice to cut the java side bloat. This is the proguard config file we’re using the proguard lwjgl apps:


-keep class org.lwjgl.LWJGLUtil {*;}
-keep class org.lwjgl.LWJGLException {*;}

-keep class org.lwjgl.opengl.DisplayMode {*;}
-keep class org.lwjgl.opengl.WindowsDisplay {*;}
-keep class org.lwjgl.opengl.WindowsFileVersion {*;}
-keep class org.lwjgl.opengl.PixelFormat {*;}
-keep class org.lwjgl.opengl.GL11 {public *;}
-keep class org.lwjgl.opengl.GL12 {public *;}
-keep class org.lwjgl.opengl.GL13 {public *;}
-keep class org.lwjgl.opengl.ARBBufferObject {public *;}
-keep class org.lwjgl.opengl.GLContext {public *;}
-keep class org.lwjgl.opengl.Display {public *;}

-keep class org.lwjgl.opengl.WindowsDirectInput {*;}
-keep class org.lwjgl.opengl.WindowsDirectInput3 {*;}
-keep class org.lwjgl.opengl.WindowsDirectInput8 {*;}
-keep class org.lwjgl.opengl.WindowsDirectInputDevice {*;}
-keep class org.lwjgl.opengl.WindowsDirectInputDevice3 {*;}
-keep class org.lwjgl.opengl.WindowsDirectInputDevice8 {*;}
-keep class org.lwjgl.opengl.WindowsDirectInputDeviceObjectCallback {*;}

-keep class org.lwjgl.openal.ALCcontext {*;}
-keep class org.lwjgl.openal.ALCdevice {<init>(long);*;}
-keep class org.lwjgl.openal.AL10 {*;}
-keep class org.lwjgl.openal.AL11 {*;}
-keep class org.lwjgl.openal.ALC10 {*;}
-keep class org.lwjgl.openal.ALC11 {*;}

-keep class org.lwjgl.BufferUtils {*;}

-keep class net.java.games.input.OSXEnvironmentPlugin {*;}
-keep class net.java.games.input.LinuxEnvironmentPlugin {*;}
-keep class net.java.games.input.DirectInputEnvironmentPlugin {*;}
-keep class net.java.games.input.RawInputEnvironmentPlugin {*;}
-keep class net.java.games.input.OSXHIDDeviceIterator {*;}


Yep, I am heading in the same direction (already started my own lib/framework before Pulp was official, but everybody should have their own, right?). LWJGL (Slick really) would be nice, but incompatibility and scary popups is just a little bit too much for me I think to be worthwhile. Java is getting fast enough that applets get ok framerate with plane old java2D. Would be great to hear if anyone has done any somewhat recent applet shmups (or similar), and what tech and how it worked out. Hope I am not hijacking thread, but I guess it would be interesting to know, right? A bit shy of pulp cause I read a while ago that it wasn’t intended for scrolling backgrounds. Not sure if that still is true.

By the way doing a vertical shmup myself, but starting with logic and coding against interface for rendering, so I haven’t really made my decision yet either :slight_smile:

[quote]A bit shy of pulp cause I read a while ago that it wasn’t intended for scrolling backgrounds.
[/quote]
Right, PulpCore’s got its own software render and has automatic dirty rectangles, which is great for single-screen games, but not so great for scrolling screens. You can do scrolling screens with it (try the TileMap demo), but like JonathanC says, most machines won’t have vsync (it’s automatic in Mac OS X, but AFAIK that’s it)

[quote]A little off-topic, but is that why you do this in the code?

// When scrolling, disable dirty rectangles and hide the cursor
setDirtyRectanglesEnabled(!tileMap.isScrolling());

[/quote]
Yeah, when the entire surface is scrolling, it’s just one big dirty rectangle - no use in calculating dirty rectangles (although in that demo, if you left it enabled there would be no performance hit since there are hardly any sprites)

I tested the applet.
The first time, I got a white screen, the second time it worked : 61 FPS
Firefox
Mandriva Linux 2007
ATI Radeon 9250 Pro

Why is it so slow? Only 61 FPS for a 2D game?? What’s wrong?? How many vertices do you draw? 100000?

Good job.