Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (577)
games submitted by our members
Games in WIP (498)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2 3 ... 6
  ignore  |  Print  
  JSR-231 1.1.1a Released  (Read 94571 times)
0 Members and 1 Guest are viewing this topic.
Offline Ken Russell

JGO Coder




Java games rock!


« Posted 2006-12-23 00:32:49 »

JSR-231 1.1.0 Release Candidate 1 Released

JSR-231 1.1.0 Release Candidate 1 has been posted on December 22, 2006. This is not an "official" release of JSR-231, but a pre-release of Sun's reference implementation including planned specification updates. The binaries and source code are available at the link above. The on-line JOGL demos have been updated to use this release of the code. The current extension JNLP listed in the JOGL User's Guide has also been updated:

1  
<extension name="jogl" href="http://download.java.net/media/jogl/builds/archive/jsr-231-webstart-current/jogl.jnlp" />


The following changes have been made since JSR-231 1.0.0:

  • The glext.h and associated header files JOGL uses have been updated to OpenGL 2.1 with NVidia's GeForce 8 series extensions. The new functions are available as methods in the GL interface.
  • The JOGL applet launcher now supports deployment of applets which use both OpenGL for 3D graphics via JOGL as well as OpenAL for spatialized audio via JOAL. It now prompts the user on Windows platforms to allow it to enable the -Dsun.java2d.noddraw=true system property for best robustness. It has been updated for the changes in the GlueGen runtime classes and native library structure. Some bugs have been fixed, some of which were preventing different JOGL-based applets from being deployed from the same codebase. The documentation and on-line examples have been updated as well.
  • The developer build bundles have been changed to zip archives, so instead of having to download multiple jars, you can now just download the zip archive for your particular platform. The new zip archives are versioned with the build date.
  • The source distribution now contains the generated sources like GL.java, GLU.java, etc. for more convenient use in IDEs.
  • The chosen GLCapabilities are now exposed from the GLDrawable via GLDrawable.getChosenGLCapabilities(); this functionality works on all platforms even in cases where the GLCapabilitiesChooser is not supported, and attempts to provide correct answers so programs can make decisions based on the results.
  • The native code for the "DRI hack" (to support the open-source DRI drivers on Linux and other X11 platforms) has been removed; JOGL now uses the GlueGen NativeLibrary class for this purpose.
  • The GlueGen runtime classes have been removed from jogl.jar. These have been factored out into gluegen-rt.jar and are referenced by both the JOGL and JOAL projects.
  • Thanks to John Burkey some optimizations have been made to the buffer object-related validity checks in glVertexPointer, etc. as well as a buffer size query that was being made in the glMapBuffer implementation. This improves performance for applications performing a lot of VBO- or vertex array-based rendering, in particular with the multithreaded OpenGL implementation on Mac OS X.
  • Various bug fixes and robustness improvements were made to the GlueGen runtime and JOGL implementation.
  • Windows/AMD64 binaries, including the JOGL Cg binding, are now supplied.
  • Worked around breakage of JOGL with 5.0u10; see Sun bug IDs 6504460 and 6333613.

More changes are planned in future release candidates. There are some RFEs including adding a copyContext method (which will impact the specification) which will be addressed. Previously announced functionality like text rendering support will be added in future builds.

Thanks go in particular to Travis Bryson from Sun for pushing through a build at the last minute.

Please post here with any questions or comments about the new build. Happy holidays!
Offline K.I.L.E.R

Senior Member




Java games rock!


« Reply #1 - Posted 2006-12-23 01:58:45 »

Thank You. Smiley
Glad to see GL and so forth are finally added and buffer performance has increased.

I really do love JOGL, it's a personal pet and obsession of mine.

Vorax:
Is there a name for a "redneck" programmer?

Jeff:
Unemployed. Wink
Offline mabraham

Junior Member





« Reply #2 - Posted 2006-12-29 22:25:09 »

Lovely to see you decided to supply Windows x64 binaries that is a real time saver for us...  Smiley

Matt.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline aNt

Senior Member




AFK


« Reply #3 - Posted 2007-01-02 16:46:22 »

nice work dude! rockin work mate
Offline emzic

Senior Member





« Reply #4 - Posted 2007-01-04 10:01:17 »

great work Ken!

Previously announced functionality like text rendering support will be added in future builds.

i cant wait for that feature! Cheesy do you have any estimates on a release date for this? Smiley

thanks!

www.embege.com - personal website
webstart blendinspect - OpenGL BlendingModes visualization.
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #5 - Posted 2007-01-04 19:28:35 »

i cant wait for that feature! Cheesy do you have any estimates on a release date for this? Smiley

It's ready. Smiley Please see this thread. The classes are already present in the nightly builds.
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #6 - Posted 2007-01-24 00:36:56 »

JSR-231 1.1.0 Release Candidate 2 has been released on January 23, 2007. The following changes have been made since 1.1.0 release candidate 1:
  • The TextureIO implementation has been changed to no longer copy the data associated with BufferedImage TextureData objects. Instead, the necessary vertical flip is now implemented by flipping the texture coordinates vertically.
  • An API for updating a sub-image of a Texture object from a sub-portion of a TextureData object has been added.
  • Three new Java 2D interoperability classes are now included in the com.sun.opengl.util.j2d package: TextureRenderer, Overlay, and TextRenderer. Based on community feedback, the TextureRenderer and TextRenderer classes have been expanded to make it easier to draw 2D rendering results and text in 3D.
  • Four new text-related demos are now included on the JOGL demos web page.
  • Added a GLContext.copy() operation based on community feedback.
  • Reliability improvements when a makeCurrent() operation fails and a GLException is thrown.
  • Reliability improvements to the so-called "DRI hack" class; this has been confirmed as once again working with ATI's proprietary drivers on Linux and should also work better with NVidia's drivers.
  • Robustness improvements to the JOGLAppletLauncher when the JOAL classes are not present on the web server.
  • Based on community discovery, added documentation to JOGLAppletLauncher on why JOGL applets may run slowly in the Mozilla / Firefox browsers (root cause: the Talkback agent).

Please try this release with your applications and post feedback here. We plan to submit these APIs to the JCP soon; the official release of JSR-231 1.1.0 should follow roughly six weeks afterward.

Offline Ken Russell

JGO Coder




Java games rock!


« Reply #7 - Posted 2007-01-24 03:06:37 »

Also, thanks to the staff at O'Reilly, Pack200 compression is now enabled for JOGL. If you are running with a Java SE 5.0 or later Java Web Start or Java Plug-In client, you will automatically download the pack200-gzip compressed versions of the jar files, which are considerably smaller than the versions compressed with normal zip compression. We're additionally going to look into ways to reduce the size of jogl.jar even further.
Offline romilos

Junior Newbie





« Reply #8 - Posted 2007-02-05 09:45:12 »

I don't know if it's the right place to put this message, but I could not find a better one.

I'm concerned about the decision to map (void*) type from C to java.nio.Buffer in Java. One of the methods using that mapping is glTexImage2D(). I'll try to describe the problem I have with it.

I'm working on a concrete implementation of GL interface, which instead of calling OpenGL library functions directly, would send the data to output stream, redirecting the actual rendering to the process (or any kind of input stream reader) sitting at the other end of the output stream.

The story behind this idea is very short. What I wanted to achieve is to perform rendering in Java, using an abstraction of OpenGL provided by GL interface. But the goal was to redirect actual rendering to different process (in my case it's a Cocoa application on Max OS X).

The problem I have is simple: there are a couple of methods having java.nioBuffer argument. What I need to do, is send the content of the buffer to the WritableByteChannel. The problem is, that it can not be done in general, because the write() method on the WritableByteChannel takes ByteBuffer as a parameter. There's no way in Java to wrap a Buffer into ByteBuffer, or to read the content of the buffer in general. The only thing which I can do, is try to downcast an instance of Buffer to ByteBuffer, and pray that it really is an instance of ByteBuffer.

I'm aware of the fact, that from the JOGL's point of view, it does not matter which kind of buffer is passed to the gl method, because it's possible to get access to the buffer content using JNI. But using pure Java it's not possible. That's why it makes the GL interface flawed in that are, because it's not possible to implement it without using JNI.

What is your view on that issue? Has it already been discussed somewhere else? I'm waiting for your response.

Best regards,
Michal Pociecha-Los
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #9 - Posted 2007-02-05 10:19:23 »

From the standpoint of the API, mapping void* to Buffer reduces the number of overloadings at the potential expense of more code in the back end. You can look at the source code for the run-time helper class com.sun.gluegen.runtime.BufferFactory in the GlueGen workspace to see some of the extraction routines that are necessary behind the scenes to deal for example with direct vs. non-direct Buffers. The JOGL implementation occasionally has to down-cast Buffer to e.g. ByteBuffer or FloatBuffer in order to perform certain operations.

Since WritableByteChannel only accepts a ByteBuffer as argument, if the incoming Buffer is of a different type I think you'll have to copy the data into a temporary ByteBuffer before writing it out. That would be true even if the API exposed void* as multiple overloadings such as ByteBuffer, IntBuffer, FloatBuffer, etc.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline emzic

Senior Member





« Reply #10 - Posted 2007-02-05 11:06:37 »

hello, i was trying to update to RC2 but i experienced texture issues when setting mipmaping to false.

i am reading pngs like this:

Texture tex = TextureIO.newTexture(TextureIO.newTextureData(ImageIO.read(new File("loading.png")), false));

but the outcoming texture is either completely white or scrambled. looks like it is somehow interlaced....
however, if i turn on mipmapping like this:

Texture tex = TextureIO.newTexture(TextureIO.newTextureData(ImageIO.read(new File("loading.png")), true));

everything seems to work.

edit: and i hate to say it, but to me it seems that performance is worse with RC2 than with jogl1.0.0. especially the newTexture() functions seem to take longer. i am creating and updating textures a lot during runtime, so it happens really often, that the game lags because of this.
i cant prove this with facts, its just a personal observation.


edit2:
ok, i have been testing the TextureIO.newTextureData and TextureIO.newTexture() functions using System.nanoTime()
here are the approximate results in nanoseconds

1.01.1 RC2
newTextureData10.000.00015.000
newTexture2.000.00030.000.000

since the newTexture functions has to be run in the GL-thread, i suspect this is the reason for the lags.

thanks.

www.embege.com - personal website
webstart blendinspect - OpenGL BlendingModes visualization.
Offline romilos

Junior Newbie





« Reply #11 - Posted 2007-02-05 11:47:56 »

Hi Ken, and thanx for your fast answer.

First of all, I'd like us to take a little bit deeper look at the Java NIO API.

The first observation is, that the Java NIO API not provide any method to copy the content of buffer of "different" type to a ByteBuffer. In other words, having an instance of, let's say, FloatBuffer it's not possible to create a ByteBuffer out of it, using Java NIO API. In that light, it's not possible to write generic method in Java, which would write the content of, let's say, FloatBuffer (or any other kind of buffer different than ByteBuffer) to a Channel.

The second observation is, that the only way to create an instance of buffer of "different" type is to create a wrapper on an instance of ByteBuffer. In example, to create an instance of FloatBuffer, you MUST first create an instance of ByteBuffer, and then wrap it with FloatBuffer using ByteBuffer.asFloatBuffer() method.

That's why I think, that using ByteBuffer, instead of Buffer, as an argument in the mentioned methods in GL interface would be a sligtly better solution. I believe that it would simplify the native code a little bit (no need to downcasting), and increase the flexibility of GL interface, because it would make it possible to implement it purely in Java, in a complete way.

I love the idea of having a GL interface, because it provides an abstraction of GL to the Java developer. Having that, it's possible to implement the GL interface in any, custom way. Unfortunalety, because the java.nio.Buffer was used in a couple of methods, it's not possible to implement those methods purely in Java.

Final thought. Isn't it some kind of a hint, that there's no generic WritableChannel class with write(Buffer) method to write content of any buffer? What we have, is only WritableByteChannel with write(ByteBuffer) method. Maybe the GL interface should go in the same direction? Or maybe the Java NIO API should be redesigned/extended to have a generic WritableChannel class with write(Buffer) method?

Best regards,
Michal.
Offline romilos

Junior Newbie





« Reply #12 - Posted 2007-02-05 15:38:29 »

Hi, Ken.

I just wanted to apologize for my last post, because it was a complete junk.
I've just missed few things while reading the Javadoc fpr Java NIO, and that's why I was convinced,
that it was not possible to write data from, let's say, FloatBuffer to WritableByteBuffer.

I'm still not sure how to write the content of FloatBuffer in case it's not backed by a float[] array,
but I'll try to investigate it on my own, rather than taking your valuable time.

Regards,
Michal.

Offline Ken Russell

JGO Coder




Java games rock!


« Reply #13 - Posted 2007-02-05 17:49:32 »

No problem. As a hint, here's a generic way to copy an arbitrary (direct or non-direct) FloatBuffer into a ByteBuffer:
1  
2  
3  
  FloatBuffer src;
  ByteBuffer dst;
  dst.asFloatBuffer().put(src);


To handle arbitrary Buffers you'll just need a helper routine similar to that in the GlueGen runtime which tests the type of the incoming Buffer and does the appropriate casts.
Offline romilos

Junior Newbie





« Reply #14 - Posted 2007-02-06 12:54:48 »

Thanx Ken.

This is the part which I have missed: the FloatBuffer.put(FloatBuffer) method.

With that knowledge, the project I'm currently working on, to send OpenGL rendering over input/output streams, is almost finished. As a proof of concept, I redirected the OpenGL rendering from my sample Java application to native Max OSX application through UNIX pipes.

The result was awesome! The overhead of pushing the data through the stream was insignificant, and the animation seemed to run as smooth as in Java. As a point of reference I'd like to mention, that in Java I used GLCanvas, and in Cocoa I used NSOpenGLView.

One of the most noticable side-effects was, that in case of the Java application I used for testing (simple ZX Spectrum emulator), it ran much smoother when the rendering was sent over the stream. This may be due to the fact, that the actual rendering was delegated to the separate UNIX process, and was not performed within the same process in separate Java thread.

Thanks for your help Ken, and I'm waiting impatiently for final 1.1.0 Release.

Regards,
Michal
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #15 - Posted 2007-02-06 17:34:02 »

Sounds like great results. I hope you'll consider making your project open source and posting here about its availability.
Offline yottzumm

Junior Newbie





« Reply #16 - Posted 2007-02-11 23:12:06 »

Is anyone else getting "Hello World" being continually being written to the Java console?  I don't
think this is my code. I'm using:

    <extension name="jogl" href="http://download.java.net/media/jogl/builds/archive/jsr-231-webstart-current/jogl.jnlp"/>


in my JNLP.

yottzumm
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #17 - Posted 2007-02-11 23:30:13 »

This println is definitely not in the JOGL code. Do a Find in Files in your project or check the other libraries you're using.
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #18 - Posted 2007-02-15 01:10:13 »

JSR-231 1.1.0 Release Candidate 3 has been posted on February 14, 2007. The following changes have been made since release candidate 2:
  • Support for two new applet parameters, jogl.silent.noddraw.check and jogl.disable.noddraw.check, has been added to the JOGLAppletLauncher. Please see the JOGLAppletLauncher javadoc.
  • A new RenderDelegate interface has been added to the TextRenderer class, providing more control over how the bitmapped text is rendered. A new CustomText demo has been posted on the JOGL demos website.
  • Minor bug fixes and other improvements.
Please try this new release and post any comments here. The APIs covered by the JSR-231 specification (javax.media.opengl, javax.media.opengl.glu) have been sent to the JCP and should be approved sometime in March. We will probably do another release candidate build before then with a couple of additional bug fixes.
Offline emzic

Senior Member





« Reply #19 - Posted 2007-02-15 18:10:34 »

thanks for the update Ken! i am very glad that the jogl project is so actively developed and new releases come at a regular basis.

i tried the RC3 out, and in my project, the performance in the TextureIO.newTexture() functions still seems worse than in the 1.0.0 release, because i do a lot of texture uploading at runtime.

i posted the comparisons here:
http://www.java-gaming.org/forums/index.php?topic=15594.msg125954#msg125954

can you confirm, that maybe more work is done now in the newTexture() functions, which has been done in the newTextureData() functions before?

www.embege.com - personal website
webstart blendinspect - OpenGL BlendingModes visualization.
Offline cylab

JGO Knight


Medals: 34



« Reply #20 - Posted 2007-02-15 20:54:06 »

I noticed the files "gluegen-rt.jar" and "gluegen-rt.dll" are missing in the webstart archive. Is this a bug or are the file optional at runtime?

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

JGO Coder




Java games rock!


« Reply #21 - Posted 2007-02-16 00:26:04 »

can you confirm, that maybe more work is done now in the newTexture() functions, which has been done in the newTextureData() functions before?

There should be less work being done overall for BufferedImage-based (including ImageIO-based) texture loading. The ImageIO subsystem is used to handle file formats like PNG. A lot of work used to be done in newTextureData() which is no longer done, but it shouldn't have necessarily been replaced with work in newTexture(), unless your input data was a TYPE_CUSTOM BufferedImage or other format which doesn't map to a native OpenGL texture format. If it is, you can circumvent this work by manually converting your loaded BufferedImage into a format supported natively by OpenGL before passing it to newTexture(). TYPE_INT_RGB or TYPE_INT_ARGB are good bets. You can look at the TextureData.createFromCustom() method for a hint on how to do this.
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #22 - Posted 2007-02-16 00:27:16 »

I noticed the files "gluegen-rt.jar" and "gluegen-rt.dll" are missing in the webstart archive. Is this a bug or are the file optional at runtime?

They're supplied in the separate GlueGen webstart archive available from the GlueGen home page.
Agrv2236
Guest
« Reply #23 - Posted 2007-02-16 07:27:06 »

After the update to 1.1.0 RC3 I had to do a "javaws -uninstall" in order for JOGL to work again through webstart, otherwhise I got an "no jogl found in java.library.path" exception in all webstart JOGL apps (including the demos on jogl.dev.java.net).

I don't know why I had to do this, but I post it here in case others have the same problem. I use Windows Vista and Java 6. By the way, it is sad that the javaws from Java 6 has no GUI any more, I found it useful.

EDIT : just found the "javaws -viewer" command, happy again now Wink
Offline emzic

Senior Member





« Reply #24 - Posted 2007-02-16 11:09:55 »

A lot of work used to be done in newTextureData() which is no longer done, but it shouldn't have necessarily been replaced with work in newTexture(), unless your input data was a TYPE_CUSTOM BufferedImage or other format which doesn't map to a native OpenGL texture format.

yes, unfortunately they are of type custom. so if i work out a way to convert my CUSTOMs to TYPE_INT_ARGB wouldnt this result in about the same things that are done in the TextureData.createFromCustom(BufferedImage image)  function?

thanks!

www.embege.com - personal website
webstart blendinspect - OpenGL BlendingModes visualization.
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #25 - Posted 2007-02-16 22:25:12 »

After the update to 1.1.0 RC3 I had to do a "javaws -uninstall" in order for JOGL to work again through webstart, otherwhise I got an "no jogl found in java.library.path" exception in all webstart JOGL apps (including the demos on jogl.dev.java.net).

I saw this problem on a couple of machines but in one case it seemed to fix itself. At the time I assumed that it was due to the timestamps changing on the files coming back from the web server. On the other machine the hard disk was failing and I assumed that was the root cause. If people continue to have problems please post.
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #26 - Posted 2007-02-16 22:26:49 »

yes, unfortunately they are of type custom. so if i work out a way to convert my CUSTOMs to TYPE_INT_ARGB wouldnt this result in about the same things that are done in the TextureData.createFromCustom(BufferedImage image)  function?

It will at least allow the conversion work to be done in a background thread instead of your rendering thread. The conversion work had to be moved to the point at which the OpenGL texture was created or updated in order to honor the new guarantees that updates to the image's contents will be reflected in the contents of the OpenGL texture.
Offline c_lilian

Senior Member


Projects: 1


Java games will probably rock someday...


« Reply #27 - Posted 2007-02-19 11:33:23 »

Also, thanks to the staff at O'Reilly, Pack200 compression is now enabled for JOGL. If you are running with a Java SE 5.0 or later Java Web Start or Java Plug-In client, you will automatically download the pack200-gzip compressed versions of the jar files, which are considerably smaller than the versions compressed with normal zip compression. We're additionally going to look into ways to reduce the size of jogl.jar even further.


Ken, is it possible to have access to these signed p200 gzipped files from the download section of jogl ?

I'd like to put them on my web server for JOGLAppletLauncher usage, and the best way to do that seems to get them from an official distribution, like the non p200 ones.

Many thanks !

Lilian Smiley

Offline Ken Russell

JGO Coder




Java games rock!


« Reply #28 - Posted 2007-02-20 00:51:24 »

I've updated the jogl-1.1.0-rc3-webstart.zip archive with the .pack.gz versions of jogl.jar, jogl-demos.jar, and jogl-demos-util.jar. There wasn't any gain to be had by Pack200 compressing the other jar files (including the native jar files), at least as far as I found. We'll try to remember to include these in this zip bundle in the future. For the record, though, if you just run Pack200 on the (signed) jogl.jar in the webstart archive, you'll get the same result as these .pack.gz files.
Offline c_lilian

Senior Member


Projects: 1


Java games will probably rock someday...


« Reply #29 - Posted 2007-02-20 20:40:37 »

Thanks !

if you just run Pack200 on the (signed) jogl.jar in the webstart archive, you'll get the same result as these .pack.gz files.

IIRC last year there was a repack needed between two signings (thus my request).

Lilian Smiley

Pages: [1] 2 3 ... 6
  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.

xsi3rr4x (22 views)
2014-04-15 18:08:23

BurntPizza (17 views)
2014-04-15 03:46:01

UprightPath (31 views)
2014-04-14 17:39:50

UprightPath (15 views)
2014-04-14 17:35:47

Porlus (31 views)
2014-04-14 15:48:38

tom_mai78101 (57 views)
2014-04-10 04:04:31

BurntPizza (114 views)
2014-04-08 23:06:04

tom_mai78101 (214 views)
2014-04-05 13:34:39

trollwarrior1 (182 views)
2014-04-04 12:06:45

CJLetsGame (189 views)
2014-04-01 02:16:10
List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:05:20
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!