Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (777)
Games in Android Showcase (231)
games submitted by our members
Games in WIP (856)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1]
1  Java Game APIs & Engines / JOGL Development / Re: Common GL Context Management Adapter on: 2004-02-24 06:11:56

I doubt very much that anyone will take my suggestions, but here they are nonetheless.

When I rewrote Magician, I eliminated the Java GLContext class.  GLComponent has 5 or 6 native methods (e.g. create, destroy, makecurrent, unmakecurrent, swap).  All the platform specific stuff is done on the native side.  My implementation is now trivial (read: even I can understand it).  

(In general, exposing native side stuff in Java is a huge mistake.  Those SWT folks are insane.)

My rewrite of Magician doesn't have a separate Animator class either.  Each GLComponent instance just creates its own thread.  It's fast and simple and never ever not once wrong.  In other words, in my design, all that makecurrent stuff cannot be wrong.

The autogenerated Java GL interfaces stuff is absolutely gonzo nuts.  Take a snapshot of the resulting GL interface and dump the scripts.  The rate of change for gl.h, glu.h, extensions, and so forth is glacial.  You guys spent a huge amount of time getting that auto stuff just so.  I can't imagine that investment will pay off.

I'm the guy to blame for both GLEventListener and the GL pipeline.  I'm still not pleased with the listener interface.  Though I did add a parameter for GLDrawable (the event source) which makes some things easier.

I'm thinking of dumping TraceGL, DebugGL, ProfileGL, etc.  Now that we have stuff like aspects, profilers, and interactive debuggers, those classes are largely moot.  Though I might keep TraceGL a bit longer, because I beefed it up to emit compilable code and I haven't learned that aspect nonsense (think metaobject protocol from Smalltalk and you'll have the rough idea) well enough to replace TraceGL yet.

Inspired by extGL, I made my own faux_gl.h and faux_glu.h.   I made up some spiffy macros for declaring function pointers and probing extensions, such that the native code still looks like 'C' OpenGL code and there's no dispatch overhead after a function pointer has been resolved.  I can't remember how JOGL does this, but I think it was pretty involved.

I'm thinking of dumping all the gl* methods.  There used to be a reason for keeping them.  Now it's moot.

Well.  Good luck.

Cheers, Jason Aaron Osgood / Seattle WA
2  Java Game APIs & Engines / JOGL Development / Re: Is this about JOGL or something else? on: 2003-07-28 18:04:59
I'm grumpy that it took Sun and SGI SEVEN years to get with it.  I'm pleased that they'll being using the JCP.
3  Java Game APIs & Engines / JOGL Development / Re: GLException: Error Swapping Buffers on: 2003-07-25 15:51:53
As for exiting, have you tried setting a shutdown hook to exit cleanly regardless of how the JVM goes down?

As I've said elsewhere, I've been updating the Magician bindings.  I've really struggled with the "proper shutdown" problem (WinXP, Sun JDK 1.4.x).  I had thought my implementation was working, but it was failing silently.

Running the registered shutdown Runnables is the last thing the JVM does, meaning the AWT stuff has already gone bye-bye.  So my GLComponent's destoy() method, which deletes the GL context then unlocks AWT, fails.  Sometimes with an error 170 (resource not ready), sometimes with an ABEND.

There's probably a simple solution, but I haven't been clever enough to find it.
4  Java Game APIs & Engines / JOGL Development / Re: More API Feedback on: 2003-07-20 16:47:20

Trying to make it impossible to make mistakes is only going to create the following impressions:

* you're limiting my abilities
* you believe you have all the answers to MY problems
* you're letting your personal experience dictate my development
* you don't value my input


And your point is?

Haha, I'm just pulling your leg.

I have to comment on this one.  Be careful of what you wish for.  JOGL's (nee Jungle) GLComponent, Animator, et al are complicated, tightly coupled, and the desired (proper) behavior isn't explicit.  I spent quite a while figuring out how it worked, and I already knew what was supposed to happen.

Philosophy aside, I just don't think it's practicle to extend (subclass) JOGL's GLComponent.  I think Ken Russell mentioned that OpenMind just did their own GLComponent.  Sounds about right.

Cheers, Jason
5  Java Game APIs & Engines / JOGL Development / Re: Profile information on: 2003-07-20 16:39:01
I just profiled the current rev of the xith3d engine running on top of logl.

It has some interesting results.  The breakdown is somthing like this:


3% in WindowsGLContext.makeCurrent


Thanks for posting your findings.  It's good to keep an eye on this stuff.

Is your code using the Animator class?  

The makeCurrent stat is curious.  I'm not claiming I'm an expert on JOGL (nee Jungle), but I thought it invoked makeCurrent just once for each thread switch.  That would mean once when an Animator is started than once again when it's stopped (e.g. makeCurrent( NULL, NULL ) ).

I know, I should just look at your code.  My excuse is I'm prepping my house to be painted. Smiley
6  Java Game APIs & Engines / JOGL Development / Re: jogl vs. lwjgl speed test on: 2003-07-20 16:08:04

With the actual bindings both using native byte buffers to pass large byte arrays to the actual opengl calls, the biggest bottleneck in an OpenGL binding is already out of the way.

I'm sorry for being thick on this issue.  But I'm still not grokking the advantage of using direct buffers.  I must be missing something.

I was asked to add support for direct buffers to Magician.  The goal was to avoid the penalty of the copying data arrays across the Java/JNI boundary.  So I did some benchmarking and could not measure a difference between normal Java arrays and using a ByteBuffer.

It turns out that Sun's 1.4.x JVM doesn't copy the array at all.  Further, from what I gathered on BugParade and some newsgroups, using ByteBuffers (in 1.4.x) wasn't efficient for many small blocks.  So I backed out my ByteBuffer experiments.

The only advantage I can think of is allocating memory natively (e.g. textures in VRAM).  I peeked at LWJGL earlier this year and I think that's what's happening for everything.

That approach puts a lot of responsibility on the programmer vs within the library/API.  Ugh.
7  Java Game APIs & Engines / JOGL Development / Re: jogl vs. lwjgl speed test on: 2003-07-20 15:55:48
The point is that the decision to make it multithreaded should be mine to make. There's no point at all in Jogl not exposing the swapBuffers() call.

Buffer behavior and multithreading are completely different issues.  

The JOGL (nee Jungle) API gives you control over multithreading via the Animator class.  

Hiding the swapBuffer behavior is A Good Thing, ensuring that either swapbuffer or a simple glFlush is correctly called at the end of the 'display' event.
8  Java Game APIs & Engines / JOGL Development / Re: jogl vs. lwjgl speed test on: 2003-07-20 15:49:53

We'll think about exposing swapBuffers(); please feel free to file an RFE on the JOGL Issues page.

I can't think of any reason whatsoever to expose the buffer handling behavior.  My biggest complaint of Magician's API was that it had too many sharp edges.  From various postings, I gather the same was true of GL4Java.

I removed the GLContext class in my rewrite of Magician.  Further, all of the WGL, GLX, etc, calls are completely hidden.  I figure the rare person who needs that stuff can subclass GLComponent.

9  Java Game APIs & Engines / JOGL Development / Re: High resolution Timers on: 2003-06-24 03:47:43
jbanes et al-

I just looked at GAGE's AdvancedTimer.  It's the exact right solution.

In defense of moorej's request, sometimes it's fun for benchmarking/profiling, like with a ProfileGL.

Cheers, Jason
10  Java Game APIs & Engines / JOGL Development / ABEND on Shutdown on: 2003-06-23 20:56:45
JOGL Team (Chris, Ken, etc)-

[I'm still an open source plebe, so I don't know what the customs are.  Please forgive.]

JOGL's issues a Windows application error when I close the app.  Something about memory location 0x0020 being unreadable.

I had the same problem with Magician.  It happens when the JVM exits before the rendering thread terminates gracefully (e.g. no cleanup, might be in the middle of a frame update, whatever).

My fix was to register a system shutdown thread that would shutdown all the rendering threads.  The code snippet from Magician's is
      static ShutdownThread _reaper = null;
            Runtime runtime = Runtime.getRuntime();
            _reaper = new ShutdownThread();
            runtime.addShutdownHook( _reaper );
      // Package visible only.
      static void shutMeDown( GLDrawable drawable )
            _reaper.addDrawable( drawable );

The is very straightforward.  It extends Runnable, has an addDrawable(...) method, a run() method which calls destroy() on each registered GLDrawable and that's about it.  It uses a WeakHashMap, so it won't prevent garbage collection.

Each GLDrawable in Magician registers itself from within the constructor.

I guess that's enough information to roll something into JOGL.

Cheers, Jason
11  Java Game APIs & Engines / JOGL Development / Re: JOGL Exposed on: 2003-06-23 17:50:55
Hi Chris-

...another pipeline which contained non-prefixed calls wrapping their prefixed base methods (e.g., color3f() calling glColor3f()).

Hey, thanks for listening! <grin>

In Magician, the type denoting suffixes were also dropped for the Java-ified names.   For example, color( float, float, float ) in place of color3f( float, float, float ).

Cheers, Jason
12  Java Game APIs & Engines / JOGL Development / Re: JOGL Exposed on: 2003-06-23 02:05:06
What's old is new again...

Alligator Descartes and I hashed thru the Java vs 'C' method names debate SEVEN years ago.  Alligator wanted backward compatibility to facilitate porting.  I wanted rational bindings for Java.

It was then covered again by the ARB in 1998.  

Our compromise was to have both.  Included in the bargain were convenience methods, for instance GL.color( java.awt.Color ).

And before anyone freaks about code bloat, that's what packagers like IBM's JAX are for.
13  Java Game APIs & Engines / JOGL Development / Re: Jogl - No explicit glSwapBuffers & glEnd o on: 2003-06-23 01:48:22

I'm unsure of how the Animator class is actually useful - it seems to perform some voodoo with    gldrawable.setNoAutoRedrawMode() to get a screen repaint, but I'm not sure.

Yea, I splunked thru JOGL to figure out how it worked.  The GLCanvas class has "autosense" threading technology so that it will always correctly use the underlying OpenGL context.  That means it'll behave correctly when driven by the main thread (e.g. when components are painted before the AWT thread kicks off), the AWT thread (e.g. a reshape event), or an outside thread like the Animator.

Pages: [1]
hadezbladez (335 views)
2018-11-16 13:46:03

hadezbladez (177 views)
2018-11-16 13:41:33

hadezbladez (336 views)
2018-11-16 13:35:35

hadezbladez (81 views)
2018-11-16 13:32:03

EgonOlsen (2175 views)
2018-06-10 19:43:48

EgonOlsen (2203 views)
2018-06-10 19:43:44

EgonOlsen (1376 views)
2018-06-10 19:43:20

DesertCoockie (2008 views)
2018-05-13 18:23:11

nelsongames (1646 views)
2018-04-24 18:15:36

nelsongames (2296 views)
2018-04-24 18:14:32
Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08

Deployment and Packaging
by gouessej
2018-08-22 08:03:45

Deployment and Packaging
by philfrei
2018-08-20 02:33:38

Deployment and Packaging
by philfrei
2018-08-20 02:29:55

Deployment and Packaging
by philfrei
2018-08-19 23:56:20

Deployment and Packaging
by philfrei
2018-08-19 23:54:46 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‑
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!