Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (498)
Games in Android Showcase (115)
games submitted by our members
Games in WIP (563)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  JOGL in applet  (Read 4729 times)
0 Members and 1 Guest are viewing this topic.
Offline flateric147

Senior Newbie





« Posted 2007-06-13 09:47:59 »

Hi,

one of the biggest disadvantages of JAVA+3d in web environments
(applets..) is the necessety to let the user authorize the use of the native
libraries (user has to click at least once "ok"). This and the load time
are the main problems with java compared to flash. Although flash's 3d
capabilities and quality are very poor, people like google prefer using flash
instead of java just for those reasons I believe (have you seen google's
street level, that could be 100 times nicer using java+jogl!). So are there
any chances that these issues will be resolved/addressed differntly in the future
(java's strict security policy could be revisited especially for JNI stuff...)?
I'm just afraid tha flash will take over the whole web, which is quite a pain....

What do you think?

Regards,

  Toni
Online cylab

JGO Ninja


Medals: 49



« Reply #1 - Posted 2007-06-13 11:24:59 »

As long as Java3D and Jogl are not parts of the regular JRE/Java plugin, this issue will not go away.

Mathias - I Know What [you] Did Last Summer!
Offline flateric147

Senior Newbie





« Reply #2 - Posted 2007-06-13 14:13:16 »

Is there any indication this could happen?
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #3 - Posted 2007-06-13 15:50:26 »

We have been considering not presenting the security dialog for Sun-signed binaries, as these are basically implicitly trusted. I have some reservations about this, as it should probably be the user's choice, but this would simplify deployment (even though in general you should only see the security dialog one time). What do you think?
Offline ryanm

Senior Member


Projects: 1
Exp: 15 years


Used to be bleb


« Reply #4 - Posted 2007-06-13 16:03:51 »

We have been considering not presenting the security dialog for Sun-signed binaries, as these are basically implicitly trusted. I have some reservations about this, as it should probably be the user's choice, but this would simplify deployment (even though in general you should only see the security dialog one time). What do you think?

Sounds like a winner to me. If a user doesn't trust Sun, they probably shouldn't be running the JRE in the first place.
Offline flateric147

Senior Newbie





« Reply #5 - Posted 2007-06-14 07:39:42 »

We have been considering not presenting the security dialog for Sun-signed binaries, as these are basically implicitly trusted. I have some reservations about this, as it should probably be the user's choice, but this would simplify deployment (even though in general you should only see the security dialog one time). What do you think?


Hi,

that could be a solution. It's not clean&nice but..... Yes, I know you have to confirm only
once the dialog box, but that's enough to scare away users. Users not knowing what a
"certificate" is, just don't understand what's going on, they perceive it as something
"negative" and are scared by the site. When they navigate the web, they don't want to
confirm anything. This pop-up must be eliminated somehow. Considering that there's
no standard yet for 3d applications on the web, sun is missing a great opportunity
here (they already failed with the JMF, do they learn from errors?). Perhaps including
JOGL into the JRE as suggested by "cylab" could be a good solution. OpenGL is cross
platform and a modern graphics API, you just can do everything you could imagine of in 3d,
in an APPLET !!! And more: we recentrly included the mp4 player from http://mediaframe.org/
into an applet, that stuff just rocks, listen: you can map a video stream as texture onto
arbitrary 3d objects! The page mediaframe.org is pretty much dead, but there are more
recent versions from airlock. They are worting on RTP streaming of mpeg4 files...
Just imagine youtube done with all this stuff. It would be a 100 times better and the world
would be a better place (flash is closed source and steered by "evil" companies like Adobe,
their new video codec o2 is a secret... :-) So, sun: WAKE UP, take the opportunity,
don't let us down with flash! Hopefully somwbody hears me....

Regards,

  Toni



Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #6 - Posted 2007-06-14 11:05:10 »

So can 3rd party libraries get signed by sun ?

Offline Ken Russell

JGO Coder




Java games rock!


« Reply #7 - Posted 2007-06-14 17:05:54 »

Considering that there's
no standard yet for 3d applications on the web, sun is missing a great opportunity
here (they already failed with the JMF, do they learn from errors?). Perhaps including
JOGL into the JRE as suggested by "cylab" could be a good solution. OpenGL is cross
platform and a modern graphics API, you just can do everything you could imagine of in 3d,
in an APPLET !!!

I'd like to think we have learned from our past mistakes. We did figure out how to do dynamic downloading of extensions like JOGL in the context of applets, and are continuing to refine the technology. Even though I'm the JOGL project lead, I continue to resist bundling it in to the core JRE, as doing so introduces problems and we need to solve the extension deployment problem more generally (and we are working on this).

And more: we recentrly included the mp4 player from http://mediaframe.org/
into an applet, that stuff just rocks, listen: you can map a video stream as texture onto
arbitrary 3d objects! The page mediaframe.org is pretty much dead, but there are more
recent versions from airlock. They are worting on RTP streaming of mpeg4 files...
Just imagine youtube done with all this stuff. It would be a 100 times better and the world
would be a better place (flash is closed source and steered by "evil" companies like Adobe,
their new video codec o2 is a secret... :-) So, sun: WAKE UP, take the opportunity,
don't let us down with flash! Hopefully somwbody hears me....

That's very cool. Do you have an online demo of this stuff?
Offline mrmacete

Innocent Bystander





« Reply #8 - Posted 2007-06-15 13:42:05 »

Even though I'm the JOGL project lead, I continue to resist bundling it in to the core JRE, as doing so introduces problems and we need to solve the extension deployment problem more generally (and we are working on this).

Hi to everyone... i'm very interested in this topic, as i'm really looking forward for Java as the standard for web multimedia.
Good and general design is important, but time is really critical now! The risk is to let Flash to become "the only solution", and loose the battle for Java as an open and versatile multimedia platform on the web.

If we keep on thinking and thinking for another year , we'll get a perfectly-designed, open,  and useless multimedia platform  Undecided
Offline Markus_Persson

JGO Wizard


Medals: 15
Projects: 19


Mojang Specifications


« Reply #9 - Posted 2007-06-15 15:02:36 »

We have been considering not presenting the security dialog for Sun-signed binaries, as these are basically implicitly trusted. I have some reservations about this, as it should probably be the user's choice, but this would simplify deployment (even though in general you should only see the security dialog one time). What do you think?

Replace "Sun" by "Microsoft" and notice the sudden creepy. I vote strongly against doing this.

Play Minecraft!
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline quintesse

Junior Member




Java games rock!


« Reply #10 - Posted 2007-06-18 16:09:24 »

Even though I'm the JOGL project lead, I continue to resist bundling it in to the core JRE, as doing so introduces problems and we need to solve the extension deployment problem more generally (and we are working on this)

Just curious, what's exactly the reason why you are against putting JOGL in the core?

I imagine that flexibility is one of the reasons? You wouldn't be able to keep on improving JOGL at he same rate as you are doing now. But what are the other reasons? Because personally I would love the idea that 3D graphics come with "the package".

Of course if JAMs and the whole OSGi-like system becomes a reality all of this might stop to be relevant.
Offline DzzD
« Reply #11 - Posted 2007-06-18 21:23:51 »

long time without news about this but we have finish the windows version of runtime loading of jogl dll (meaning that the user have the choice or not to enable hardware acceleration at runtime)

http://dzzd.net/demo/QUAKE/ just click the applet move/run than use H or S keys to switch from software/hardware mode, it use jogl for hardware rendering.

We have not works on the hardware implementation for a long time but there are a lot of improvment in the soft engine (wich is not online for now... ) wich are for now unavailable in hardware mode, anyways there will be a new demo and beta version soon donwloadable. I hope you will love it ;-)

I will try to get some time to polish and post  to the jogl community the part of the code that made runtime loading, this way user will be less afraid as the applet will have already start.

Bruno

Offline flateric147

Senior Newbie





« Reply #12 - Posted 2007-06-19 10:27:29 »

long time without news about this but we have finish the windows version of runtime loading of jogl dll (meaning that the user have the choice or not to enable hardware acceleration at runtime)

http://dzzd.net/demo/QUAKE/ just click the applet move/run than use H or S keys to switch from software/hardware mode, it use jogl for hardware rendering.

We have not works on the hardware implementation for a long time but there are a lot of improvment in the soft engine (wich is not online for now... ) wich are for now unavailable in hardware mode, anyways there will be a new demo and beta version soon donwloadable. I hope you will love it ;-)

I will try to get some time to polish and post  to the jogl community the part of the code that made runtime loading, this way user will be less afraid as the applet will have already start.

Bruno

Hi Bruno,

the demo is absolutely mindblowing! I have tested it on two machines, on one the sw and hw mode made no
difference (a latest generation PC), on my older PC, in sw mode the texturing seemed to be GL_NEAREST
while in hw it was perhaps GL_MIPMAP (much nicer at least). So perhaps you added some autodetect
 for the performance? Very cool! I'd love to test this version ASAP!  Good man!

  Toni
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #13 - Posted 2007-06-19 21:08:24 »

long time without news about this but we have finish the windows version of runtime loading of jogl dll (meaning that the user have the choice or not to enable hardware acceleration at runtime)

http://dzzd.net/demo/QUAKE/ just click the applet move/run than use H or S keys to switch from software/hardware mode, it use jogl for hardware rendering.

This is cool, or at least was after I cleaned the puke off my monitor (the camera control is way too touchy). The switching between software and hardware rendering is pretty slick.

I will try to get some time to polish and post  to the jogl community the part of the code that made runtime loading, this way user will be less afraid as the applet will have already start.

Please do. We should start posting this stuff in a more permanent place. I'm hesitant to start using the JOGL Wiki as it never really took off and we're probably going to recategorize it. If you do a writeup I could give you Developer access to the jogl-demos or joglutils projects and we could start checking in more documentation there.
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #14 - Posted 2007-06-19 21:10:43 »

Just curious, what's exactly the reason why you are against putting JOGL in the core?

I imagine that flexibility is one of the reasons? You wouldn't be able to keep on improving JOGL at he same rate as you are doing now. But what are the other reasons? Because personally I would love the idea that 3D graphics come with "the package".

Yes, tying JOGL to the glacial release cycle of the JRE is my main concern. It's completely unnecessary and would be very counterproductive to the community.

Of course if JAMs and the whole OSGi-like system becomes a reality all of this might stop to be relevant.

We're already most of the way there today, at least from the end user's standpoint. You can either click to launch (via Java Web Start) or visit to launch (via applets) content using JOGL with zero manual installation already. Again we are working on refining the technologies in particular in the applet arena.
Offline DzzD
« Reply #15 - Posted 2007-06-20 22:01:03 »

This is cool, or at least was after I cleaned the puke off my monitor (the camera control is way too touchy). The switching between software and hardware rendering is pretty slick.
anyways this is an obselete 3DzzD version, so as you can guess next release will have a lot of fixed bug and improvmentn this one will be available soon to download.

Please do. We should start posting this stuff in a more permanent place. I'm hesitant to start using the JOGL Wiki as it never really took off and we're probably going to recategorize it. If you do a writeup I could give you Developer access to the jogl-demos or joglutils projects and we could start checking in more documentation there.

note that thijs is doing most of the works, he said that it should be faster to do this times, as the code seems cleaner than last source code we downloaded, last time we works on the runtime loading of JOGL., this code should be released soon  Smiley

Offline DzzD
« Reply #16 - Posted 2007-07-19 23:42:32 »

Hi,

finally finished a working version... before a new release of jogl.

First of all we made a little mistake and compile the jogl.jar with JDK 1.6, this means that hardware rendering and compile of sample provided will only works with JDK1.6

About 3DzzD:
3DzzD now include this feature, demo available here (apologies but  JRE 1.6 only for hardware until we recompile with JDK 1.4 or a next release of jogl with those new files Smiley )
http://dzzd.net/demo/V2007-08-18/

the demo will start in full Java 1.1 compatible mode, and than you will be able to switch to hardware using H key (S to get back to software)

FPS: it is limited to 50 fps in either software and hardware mode because when swithing to hardware FPS is growing too much and control become impossible, (NB: quake level test show about 300/400 fps with an ATI x200 using hardware mode... of course...).

Know bugs: multiple switching is not recommended....

note : as it is a WIP (3DzzD V2.0) all software optimisation have been removed and so the software engine can appear to be a bit slower than before, optimisation will be putted back when 3DzzD-V2.0 will be released.

About JOGL
Ken,

they are only two file that have to be added to the jogl package to enable runtime loading of JOGL within an applet, I have put those files in my server to make it easier to download:

they must be added in the following directory of jogl project "src/classes/com/sun/opengl/util" (of course...)

here you can download the source code of the two requiered files:
http://dzzd.net/jogl/JOGLAppletContainer.java
http://dzzd.net/jogl/JOGLAppletLauncher.java

Directory access:
http://dzzd.net/jogl/

How to use it
also I provide this file as an utility that does not requiere to be in the jogl release, it show how to load JOGL from an applet at runtime:
http://dzzd.net/jogl/JOGLAppletLoader.java

you may download a sample project and source code there:
RuntimeJoglAppletSample.zip

once again , I apologize for the 1.6 JRE/JDK requierment.


waiting feed back!


special thank to thijs: he has coded and compiled the two new jogl library files





Offline Ken Russell

JGO Coder




Java games rock!


« Reply #17 - Posted 2007-07-20 15:20:55 »

Thanks for posting this. However, we have recently released the new JNLPAppletLauncher which I believe solves this problem more elegantly. This class does not load the native libraries up front (although it does currently download them from the server up front) so it should support the lazy loading that your modifications enable. Please take a look at the JNLPAppletLauncher and see whether it serves your needs. I would prefer not to make any more changes to the JOGLAppletLauncher as I am planning to remove it from the source tree.
Offline thijs

Junior Member




Lava games rock!


« Reply #18 - Posted 2007-07-22 20:45:47 »

Quote
Thanks for posting this. However, we have recently released the new JNLPAppletLauncher which I believe solves this problem more elegantly. This class does not load the native libraries up front (although it does currently download them from the server up front) so it should support the lazy loading that your modifications enable. Please take a look at the JNLPAppletLauncher and see whether it serves your needs. I would prefer not to make any more changes to the JOGLAppletLauncher as I am planning to remove it from the source tree.

Hi Ken,

The new JNLPAppletLauncher is indeed a step forward, but for our specific case it wouldn't solve our problem. In our case JOGL is just a driver to render over opengl. There are some reasons why we chosen to implement it like this:

1.) The JNLPAppletLauncher would force us to load our applet through another applet. Something that would put restrictions on backward compatibility (for example, in our case jre 1.1 compatibility)

2.) We dont want to narrow our framework to be JOGL specific (hence not load as a subapplet from JOGL). Another driver to render things would be through LWJGL, maybe the upcomming DirectX binding or our software renderer. This is why we want our own applet to be in control and force these "drivers" to load when a user requests so (like when you chose another renderer in fx unreal).

3.) We want to keep the applet loading and booting as fast as possible, when a user asks to do things over jogl or lwjgl, only then download and install this driver (when not yet present). JNLPAppletLauncher downloads everything upfront... also the jars in the archive param now can be downloaded at runtime using our approach (wip)

4.) We want to be in control of how this downloading/installing progress gets visualized to the user... for example through our own GUI system (not through Swing as JNLPAppletLauncher imposes).

5.) We dont want to require our applet to popup an security warning initially (we run using the software renderer at default)... only when the user requests this explicitly this warning should be raised before downloading and installing the driver.

At the moment I'm refining the current implementation to help achieving this even better than it does now... We'll release it as opensource, so people with the same goals as set out above can use that instead (though need to sign the jars with their own certificate)

Thijs

<a href="http://www.dzzd.net">3DzzD!</a>
<a href="http://www.arcazoid.com">Arcazoid!</a>
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #19 - Posted 2007-07-23 02:32:46 »

1.) The JNLPAppletLauncher would force us to load our applet through another applet. Something that would put restrictions on backward compatibility (for example, in our case jre 1.1 compatibility)

I see.

2.) We dont want to narrow our framework to be JOGL specific (hence not load as a subapplet from JOGL). Another driver to render things would be through LWJGL, maybe the upcomming DirectX binding or our software renderer. This is why we want our own applet to be in control and force these "drivers" to load when a user requests so (like when you chose another renderer in fx unreal).

The JNLPAppletLauncher knows nothing about JOGL. LWJGL could easily be modified to work with the JNLPAppletLauncher, and the libraries aren't loaded until the code which requests for example the JOGL native libraries actually loads them.

3.) We want to keep the applet loading and booting as fast as possible, when a user asks to do things over jogl or lwjgl, only then download and install this driver (when not yet present). JNLPAppletLauncher downloads everything upfront... also the jars in the archive param now can be downloaded at runtime using our approach (wip)

If you would be willing to share your code for this technique when it's done I would very much appreciate it. This seems like a pretty hard problem in my experience.

4.) We want to be in control of how this downloading/installing progress gets visualized to the user... for example through our own GUI system (not through Swing as JNLPAppletLauncher imposes).

Understood, agreed.

At the moment I'm refining the current implementation to help achieving this even better than it does now... We'll release it as opensource, so people with the same goals as set out above can use that instead (though need to sign the jars with their own certificate)

That would be really nice. Looking forward to seeing it.
Offline thijs

Junior Member




Lava games rock!


« Reply #20 - Posted 2007-08-06 13:58:34 »

Alrighty, I've put the runtime loader online... I hoped to post a more polished version here, but like most of you I dont have much spare time  Undecided
It shows the runtime downloading & installing I talked about earlier:

http://dev.arcazoid.com/matthijs/jogl/index.htm

Sources can be downloaded here:

http://dev.arcazoid.com/matthijs/jogl/jogloader.zip

After compiling the classes, the packages need to be put in the following jars:
jar cf Applet.jar deployed\*.class
jar cf Loader.jar loader\*.class
jar cf JOGLLoader.jar runtime\*.class

* Loader.jar needs to be signed, JOGLLoader.jar must not be in the applet archive tag, or else its classes will be resolved by the applet classloader instead our own.
The files downloaded at runtime will be placed in the users homedir in a directory JOGL-Test.

Thijs

PS: I noticed that it can take ~30 seconds before anything is shown when you press RUN JOGL (after all files are already downloaded, though this doesnt happen when you run it local), will look into that later.

<a href="http://www.dzzd.net">3DzzD!</a>
<a href="http://www.arcazoid.com">Arcazoid!</a>
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #21 - Posted 2007-08-06 15:47:35 »

Thanks for posting this. I've filed Issue 312 to look into this and consider incorporating a similar technique into the JNLPAppletLauncher.
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

radar3301 (11 views)
2014-09-21 23:33:17

BurntPizza (29 views)
2014-09-21 02:42:18

BurntPizza (19 views)
2014-09-21 01:30:30

moogie (20 views)
2014-09-21 00:26:15

UprightPath (27 views)
2014-09-20 20:14:06

BurntPizza (30 views)
2014-09-19 03:14:18

Dwinin (47 views)
2014-09-12 09:08:26

Norakomi (74 views)
2014-09-10 13:57:51

TehJavaDev (102 views)
2014-09-10 06:39:09

Tekkerue (50 views)
2014-09-09 02:24:56
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!