The PSP giveaway at the Darkstar booth was a brilliant idea. Never thought I'd see a crowd of a hundred game developers yelling "Sun!"

I made a copy of the JOGLAppletLauncher class and added a public getSubApplet method:



This change did the trick and I was then able to call methods on my applet from JavaScript like this:




So, yes, please add the getter to JOGLAppletLauncher.


As an aside, I tried getting around having to change JOGLAppletLauncher by noting that JOGLAppletLauncher isa Container with the sub-applet as its only child. The following JavaScript worked in Firefox:



but it did not work on IE, giving me an error along the lines of "document.appletlauncher.getComponents().0 is null or not an object". Anyone with more JS foo than I have any idea why this wouldn't work in IE?

Hi,

I was wondering if it is possible to call methods on the JOGLAppletLauncher subapplet (the "real" applet) from JavaScript. As I understand it, you can only call methods publicly exposed by the applet from JavaScript. Since the applet happens to be JOGLAppletLauncher, there seems no way for me to invoke methods on MY applet that is being started by JOGLAppletLauncher. Is there something I'm missing?

If there is currently no way to do this, I think a reasonable way to allow this behavior (though I haven't tried it yet) would be to add a "getSubApplet" method to JOGLAppletLauncher.

Hi,

We're considering releasing a 3D game-like application in a few months that is to run within a browser window, and we'd like some recommendations for 3D engines to use.
Our users are primarily on broadband, so download size isn't a big concern (within reason, > 20MB would be too much). What is a concern is dealing with the plethora of
graphics cards and system configurations.

We've looked at JOGL but we're not sure what the level of OpenGL support is out there. Java3D can also run on top of DirectX but can it run in a browser window?
Is Java3D still supported? (Sun activity seems to be primarily on JOGL...) WildTangent seems to run on top of DirectX, but it looks like they haven't had an
API release in 3-4 yrs, which worries me.  We'd like to have a software-rendering fallback, in case the user has an ancient graphics card, but we haven't
seen much in terms of software-rendering engines.

So, do you guys have any recommendations? Any engines we've missed? Anything we shouldn't be worrying about? Anything we SHOULD be worrying about and
haven't?


Thanks for any pointers,
S.

Um, how? I go to jogl.dev.java.net , click on mailing lists on nthe left panel and it says there are no mailing lists for this project. Did I miss something?

And a team of 732 artists, don't forget the 732 artists!

Spiff == Spiff.

I've been bitten by small-object overheads. There are workarounds (such as creating a float array for all vertices and having multiple triangles index into that array) but it would still be nicer to be able to have small objects w/out the overhead.

*Bump*

It has been more than 4 months since the last Community Board meeting minutes. Is this still going on?

I didn't realize LWJGL was actually faster than Jogl. Do you perhaps have some links showing which operations are faster and by how much? Numbers are always nice...

Thanks for the numbers, it is always good to know that "real" scenes were tested

Now, if Aviatrix3D is a Java scene graph on top of an OpenGL binding (much like Java3D, just a better implementation) does anyone know the reason for the OpenGL.org headline:

"Xj3D Toolkit vM9 adds native OpenGL API renderer that is twice as fast as the Java3D version"

Makes it sound like "they dropped Java, went native and got a 2x speedup"...

Do you have a pointer to the types of scenes they used to determine that the new renderer is twice as fast? Or any actual numbers for that matter? Pretty much every VRML scene I've seen in the past has been tiny, but perhaps that has changed...

I believe the way it works is that the autoupdater only downloads on minor revision updates (the 2 in 1.4.2_05). You do NOT want to be ticking off users by updating on the _x revisions which come out every couple of months or so (unless the fixes are major security bugs). You do that and they'll simply turn off the autoupdater.

IRC chat can foster a better sense of community than message forums alone. It encourages simple chatting as opposed to the more formal discussions seen on the forums. Some of us have attempted to create an IRC channel but have met with limited success. We suspect this may be because people who do not use IRC regularly find it cumbersome to figure out how it works and install the appropriate client. An IRC applet would reduce this barrier. Additionally, if we placed this applet on or close to the main page on java-gaming.org it might encourage more participation. Would you like to see such an applet on java-gaming.org?

Anyone doing significant floating point work should try out 1.4.2's with the -server option. It uses SSE and I've seen large performance increases with it.

I see a problem with this. Right now there's the rule "no allocating in the main loop". Adding bounded GC would give us the rule "you can allocate some, but not enough to overwhelm what the GC can collect in about 10ms". And of course, this rule would change depending on the deployment scenario. I imagine it might be pretty hard to determine just how many new's you're allowed and of what size each new should be.

It seems to me that this would make programming harder than just using the no-allocation rule. Unless, of course, the GC can collect gobs more in a few ms than you would ever likely allocate.

I'd like to see lightweight objects in Java. And by this, I don't mean the structs proposal on the bug parade. I just want to get rid of the cost associated with temporary objects. I'm tired of making my code ugly to avoid doing news. Even if the GC ever gets fast enough that doing news of temporaries is a non-issue (it isn't there now), you still have the problem that following references is cache-unfriendly. For example, if I have

class A {
float v1;
float v2;
float v3;
}

I know that once I reference v1, v2 and v3 will also be loaded in the cache so accessing them will be fast. However, if I have

class A {
Vector3f v1;
Vector3f v2;
Vector3f v3;
}

I'll be jumping all over memory accessing v1, v2, and v3. I want v1, v2, and v3 to be inlined in memory just like primitives are. I want to not have an 8-byte per object overhead, just like primitives don't have. I don't want to be able to extend v1, v2, and v3, just like I can't extend primitives. I don't even want operator overloading. I want lightweight objects.

Check out the size of the Windows 1.4.2beta JRE: 1.3MB