Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (780)
Games in Android Showcase (233)
games submitted by our members
Games in WIP (857)
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: Swing/JOGL integration demos on: 2005-12-04 17:53:06
Neat little demo you got there.

Wrt Java2D fonts, I wonder if there is going to be a way to grab the Java2D GL pipeline glyph cache and use it, instead of having to write into the buffered image, and pretty much recreate what Java2D GL pipeline already does quite well. Someone once requested this capability on a Java2D forum (IIRC), but aparently at the time no such capability was exposed.

In any event, good going for Swing with all these new developments, people are gonna go crazy with all this new stuff to do.
2  Java Game APIs & Engines / JOGL Development / Re: I'm so confused about the 3d technology, will you explain for me? on: 2005-12-04 12:08:10
I found this book to be worth its weight in gold:
3  Java Game APIs & Engines / JOGL Development / Re: Creating avi file from animation in GLJPanel on: 2005-12-03 17:52:46
Simplest approach would be to use JMF.

Here's a link that may be helpful:

I believe you can store motion JPEG in an AVI container, but you can certainly transcode to whichever format you wish using JMF.

EDIT: Looks like JMF supports MJPG into an AVI container.
4  Java Game APIs & Engines / JOGL Development / Re: JOGL JSR implementation performance with JNI on: 2005-12-02 05:16:51
Ok, while I appreciate the helpful comments, I will say that aside from Ken, nobody seems to have grasped the situation. No worries though, heh, initially I wasn't even going to spill anything since I'm doing quite allright when it comes to optimizations.

Anywho, thanks anyways.



No worries.


Again, 70 calls per object. Thas one, secondly, what you perceive to be a problem of "shifting a problem to native code" is not the case. As for thread synchronization, where it is required, it is in place, it goes without saying.

And finally, subset of this project's capabilities are targeted at low-end hardware, while dual CPU is one of the multiple arch on which this system is being developed/tested. Oh, one more thing ... there are places where producer/consumer paradigm is warranted, and used. There are places where synchronized version of this paradigm is not warranted, and there are many ways to perform synchronization without using explicit sync primitives. Doug Lea's book Concurrent Programming in Java 2nd Edition is a good read.
Also, as for blaming my tools? Heh, hardly, I brag about having the best tools in the industry.
5  Java Game APIs & Engines / JOGL Development / Re: JOGL JSR implementation performance with JNI on: 2005-12-01 03:59:42
I've done some preliminary state management, such as enabling the textures backwards, coalescing calls, among other minor things. Good suggestion, I will look into it more thouroughly for sure.

The gamma corrective op that runs on r200 seems kind of bloated, but its not. There was an "option" of packing RGB ramps into a single texture, (saving some tex bind, state calls) but in order to do a dependent texture fetch on radeon 9k, which doesn't support ARB fragment programs, but rather a semi-limited (instruction count wise, 8 per pass) ATI proprietary shader, I kept running out of instructions in the second pass to do a dependent texture fetch.  (first pass is maxed out for YUV & EQ)

So thats why I opted for using 6 textures, each of the textures (top 3) contains the R,G,B ramps while lower textures contain the YUV planes. I've also considered packing the YUV into interleaved format, but that would induce a hit on the CPU since data comes from source in a planar format, so things like that I've been mucking with. (cpu will be doing quite a bit of DCT, so no go) (also trying to minimize the amount of contenders for the branch prediction table, I hear even on modern CPUs its a limited resource, so with all those other things looping everywhere, cache coherency can be a problem)

I have a branch (Src Control) which does most of this stuff using ARB programs where you have the POW instruction, so gamma correction does not require dependent fetch into separate ramps ... and its so much nicer, I must say. (as well as other optimizations which I couldn't pull on such ancient HW, but its a requirement)

I figured if r200 has 6 tex units, why not use them. So with those 6 units, I must enable each, setup pixel alignment & unpack modes, ...then setup VBO, send some geomertry and restore states.

All in all, I want to minimize amount of time that gets spent in GL overall, but its inevitable (feature creep made me add features I wouldn't of otherwise opted for myself) so I'm spinning wheels looking for ways. But, I'll be doing some thorough profiling to iron out the remaining hotspots, currently few preliminary profiler passes have been done.

There was a good quote about time or lack thereof, can't remember now. So much to do, so little time.
6  Java Game APIs & Engines / JOGL Development / Re: JOGL JSR implementation performance with JNI on: 2005-12-01 02:34:26
Somehow the premise got skewed here...

I've never said that overhead was _tremendous_. However, it is my job to sqeeze every ounce of performance out of the CPU (since the CPU is going to be doing a heck of alot more than simply pushing verts to the GPU, infact one of the reasons I went GL is to avoid the rendering hit), and since I've ported ton of native code to Java already, for reasons which I won't even begin to list, I'm going to stick to it, making appropriate adjustments where necessary. (Its been a hybrid all along, heh, politics play no role in development of this project)

I think earlier attempt , or should I say jab, was coarse;  I couldn't care less.
I've already said that my task is rather specific, and without being in position to know what I must accomplish, simply throwing out baseless assumptions is kind of silly.

I joined these forums when I started out with JOGL, to report a bug. Forums like these shouldn't have a barrier to entry.

Auf Wiedersehen
7  Java Game APIs & Engines / JOGL Development / Re: JOGL JSR implementation performance with JNI on: 2005-11-30 19:26:56

See if I care whether or not you believe me. Here I think I'm having an intelling discussion, only to be accused of lying for (insert your reason).

8  Java Game APIs & Engines / JOGL Development / Re: JOGL JSR implementation performance with JNI on: 2005-11-30 18:11:08
> How many OpenGL calls are you making per stream?

Worst case scenario (Using all 6 texture units on the R200 class hardware) I'm making on the order 70 GL calls per stream.
3 of the textures are planar YUV data, the other 3 textures are RGB gamma ramps. Shader does all the conversion.

Then I have to send some geometry, not to mention setup state (6 texture units), render, teardown. So, if using gamma correction ~70 calls, per stream, per frame.

Additionally, there is world setup, render, teardown (shadows, etc). So all in all, quite a few GL calls. Although I've only moved the stream-based GL invocations into the native world, rest is still done from Java. Its important to underline my dedication to doing as much as I can from Java, but sometimes I just have to do what I must.

As for circular buffer, yep using it. And as for synchronization, trust me where it really counts, I'm using all proper threading techniques. I can skimp on the native buffers since the behaviour seems to be defined, and is thouroughly tested (at least wrt JOGL 1.1.1) over a period of time. As of premature, I guess it can be considered, although some parts are mature in terms of features and I'm doing optimizations on those parts in band with development of other elements of the system, which overall is quite diverse.

Also, I've made a simple testcase about the JDesktopPane behaviour, if you want to take a look at it. I'm going to look at it this weekend, as its the only time I get to fix bugs. fun fun.



As for loop in native code, yes I have a version which does JAWT acquisition/release from native code. But so far I've found this method to be very unstable, so as of now I'm letting JOGL manage GL context. I intend to do more research into this when time allows, but this I do consider to be a premature optimization as overall the performance (with all latest developments) is acceptable.
9  Java Game APIs & Engines / JOGL Development / Re: JOGL JSR implementation performance with JNI on: 2005-11-30 16:16:07
Although moving bulk of GL invocations down to native on a P3 @ 500 didn't yield a very signifant improvement, I'm still persuing this path namely due to the scenario in which I'm in:

Basically with JSR-231 I have to synchronize two threads, and although lack of synchronization in general ca be considered dangerous, it works very well and is stable in JOGL 1.1.1. I have one thread which is a filler, and it pipes into a direct ByteBuffer new texture data every frame. Another thread is a renderer, which actually sends this ByteBuffer to GL.

I must disclaim that this problem is very domain-specific, so don't take my writing as sour grapes, rather as an experience.
In JOGL 1.1.1, at worst you can get some garbled data which in itself is very unlikely, but the application is stable.

In JSR-231, due to the pointer significance (sorry if sounds like dead record by now) the app crashes indeterministically. (Especially pronounced on my dual test machine)

By adding synchronization to this process, I'm sure the stability problem can be eliminated; with a good bit of performance. Although I'm mostly speaking from experience, and haven't actually taken the sync route in this case, what I did was, basically move GL invocations that were required to native layer.

This has removed the pointer signifance problem and even yielded an improvement, albeit slight one (not too many invocations, and not FP-intensive). Although I said that performance improvement was slight, this is only when dealing with a single stream; I have to process multiple streams, so improvement adds up quickly. Overall, I'm happy with this development.

So basically Java end of things handles all the management of textures, shaders, and other data ... and establishes the GL context on the EDT, then I call into native and do the actual scene invocations from there.

Anyway, 15% JNI overhead if it is correct, IMO is still quite significant. I guess part of me still feels that I should sqeeze out as much as I can, since I'm targeting lowish-end hardware (CPU/GPU) (I'm developing on a 500P3 using Radeon 9k)

Good to know your statistics though.
10  Java Game APIs & Engines / JOGL Development / Re: Trouble getting jogl.jar imported into Eclipse on: 2005-11-30 00:45:25
1) Select Menu "Run", item "Run"
2) On the left pane "Configurations" press "New".

(Configuration named "New_configuration" will be created)

3) On the resulting right pane, tab "Main", enter main class of your application.
4) Select tab "Environment" on the resulting right pane, press "New"  to add new environment variable.
5) In the "Name" field, enter "Path"
6) In the "Value" field, enter _directory_ containing native library.
7) Ensure that checkbox "Append to native environment is selected".

This will create new launch configuration which you can then launch by either using the dropdown menu in the toolbar, or by accessing it through the "Run" menu.

Eclipse allows creation of multiple launch configurations, each of which can maintain its own set of environment variables, VM with which to launch, as well as other parameters.
11  Java Game APIs & Engines / JOGL Development / Re: Trouble getting jogl.jar imported into Eclipse on: 2005-11-29 05:26:54
1) Right-click on your project in the workspace ... select Properties.
2) Select "Java Build Path" item in the list on the left pane.
3) Select "Libraries" tab on the resulting right pane.
4) Press "Add External JARS..."
5) Navigate to JOGL installation directory and select "jogl.jar"


This will accomplish the build process, when you run it, you must also specify your Eclipse launcher configuration such that it can find the required native library as well. To do this, create Java launch configuration.

1) In the "Environment" tab of the launch configuration, add "New" environment variable named "Path"
2) Add the directory containing native library as the value for this new variable.
3) Ensure that checkbox "Append to native environment is selected".

12  Java Game APIs & Engines / JOGL Development / Re: JOGL & JAWT Surface Change Semantics on: 2005-11-28 09:12:30
Attached is the test case source.

Tested: 1.4.2_08, 1.5.0_05, 1.6.0-rc (b61).
13  Java Game APIs & Engines / JOGL Development / Re: JOGL & JAWT Surface Change Semantics on: 2005-11-28 04:20:14
Since I've encountered this problem, and due to time constraints, instead of investigating further just yet, I went ahead and did re-initialize every time GLContext gets destroyed. As I've moved on to other things, again, due to time constraints, I've de-prioritized this  issue as its not a show-stopper just yet.

I'm definitely not done with it however, and as soon as I get another chance (hopefully next weekend), I will dig deeper and see if I can override some of the JDesktopPane behaviour to prevent this from happening. (I kind guessed it had to do with revalidation of the container, but currently can't check it out further)

As for extracting small test case,  I can do it, but I would rather just post an entire solution once I get the time to take a look at it.

Thanks for info.
14  Java Game APIs & Engines / JOGL Development / Re: JOGL JSR implementation performance with JNI on: 2005-11-23 09:04:38
Recent change in JOGL (JSR-231), the one which made all NIO Buffer pointers significant made me recode good chunk of GL invocations from within a tight context, to C++.

In the process, I was also wondering myself if a noticeable performance improvement would result of this change.

Suprisingly, the performance angle of this change was insignificant. (I always was wondering how JNI affects performance lately; it appears JNI has improved)

On a quick note, if not secret, what is this radically new native calling interface of which you speak, Ken?
I have looked at CNI briefly, but after determining for myself that improvement from coding GL invocations in tight loops to C++ results were almost negligible, I pretty much left with impression that JNI does the job.
15  Java Game APIs & Engines / JOGL Development / JOGL & JAWT Surface Change Semantics on: 2005-11-23 08:46:38

Recent testing within an MDI environment (JDesktopPane) brought to light one interesting fact. GLEventListener.init gets called every time the JInternalFrame which contains a GLCanvas loses focus to another JInternalFrame. Upon regaining the focus, previous JInternalFrame aparently has changed its surface since JOGL reissues GLEventListener.init for said GLCanvas. From reading other threads, initially I understood this only being the case with GLJPanel, however it appears to affect GLCanvas as well.

Since surface change semantics (JAWT_LOCK_SURFACE_CHANGED) forces JOGL to recreate the GL context, it also forces all associated listeners to reinitialize. (and although its possible to keep state and reinitialize when its done, I'm looking at only doing initializaiton once)

Is there any way to avoid this, or is this even the correct behaviour wrt JDesktopPane?

If the JDesktopPane has only one JInternalFrame present, consequently said internal frame does not lose focus, surface does not change. However, as soon as another JInternalFrame is added, previous JInternalFrame can no longer maintain its current surface.

I've looked at the way JOGL handles this scenario, and it appears that JOGL basically gets the information about surface change from JAWT during context activation, and recreates the GL context when surface has changed.

Is there any way, native or otherwise I can work around this problem? Such as forcing native peer to hold on to the current surface.

Bug-ID [4347021] (JAWT : Multi-threading issues with changing state) indicates that some state tracking bug exists wrt JAWT surfaces, and is only being fixed in Mustang. I'm using build 61 currently, and although I'm not entirely sure as to the root of this problem, before I investigate further, I was wondering if anyone has came across this.

Thank you, for any insight.
16  Java Game APIs & Engines / JOGL Development / Re: NIO Buffer Pointer Semantics & Performance on: 2005-11-03 21:05:43
Ok well in that case, attribute this to lack of sleep (and/or other misdeed on my part) that I did notice a minor difference in CPU usage between the two test runs of a program based on JOGL 1.1.1 and one based on JSR-231 (beta1). I will continue all conversion to JSR-231 as all other improvements outweigh this (aparently misconceived on my part detriment) and if I do indeed solidify substantial performance degradation, I will post for further discussion.

Test machine: P3 @ 500Mhz, Radeon 9k
JOGL 1.1.1 test run consumed on average about ~2%.
JSR-231 beta1 consumed on average about ~9%.

In my efforts to sqeeze out most of the CPU for other tasks, I may have overstepped common sense and forgotten that premature optimizations are root of all evil.
17  Java Game APIs & Engines / JOGL Development / Re: NIO Buffer Pointer Semantics & Performance on: 2005-11-03 19:45:20
Thanks for clarification.

As far as VBO is concerned, and general (VBO) usage guidelines never raised much question.

I was mainly probing to see what kind of improment/degradation occured in those programs which have one or more tight loops per-frame where dynamic textures are downloaded. i.e: if in a certain context I have to download 3 textures per-frame, lets assume for example 3 planes of a YUV frame, then thats 3 additional JNI calls one would have to make to rewind the buffer twice, once before and once after filling it up. One could make all sorts of arguments about packing textures, but truth of the matter is, everyone will always have some argument to be made.

Anyways, I must be the only one who sees issue with additional JNI overhead, so without further ado, its all clear.
18  Java Game APIs & Engines / JOGL Development / NIO Buffer Pointer Semantics & Performance on: 2005-11-03 06:11:21
First I'd like to say that overall JSR-231 looks good.

After spending about an hour+ converting nicely sized project, I must add that generally speaking I see no big issues with it, infact quite the opposite, some longstanding problems have been addressed and its certainly nice to see the API making its way into the core.

However, on the other side of this coin I've began to wonder (backed by some preliminary testing) whether or not the new NIO buffer semantics would adversely affect performance for bandwith intensive (particularly dynamic textures) applications. Fact of the matter is, with advent of  "pointer significance" when passing NIO buffers to OpenGL, extra JNI overhead is inevitable. Easing VBO usage (which is stated as one of the goals of this change) is certainly welcome, however I wonder if in the process of making VBO usage less verbose one would introduce more overhead in general through all the newly-required flips/rewinds, per frame, which in a tight loop may indeed be quite noticeable.

I can't speak for everyone, and ofcourse I'm not privy to all the rationale for instituting this new policy, and whether or not improvements in security model have played a role in this decision, but it would be nice to hear from the rest of you what kind of performance improvement/degradation occured as a result of this change. Albeit its quite early to speak of performance per-se, IMO its healthy to get a bearing since it is after all in review.

I understand that LWJGL uses this method, and aparently most people who use it are happy with it. Please let me know your thoughts on this matter and ... clearly I must be missing some advantages besides easing VBO semantics (among other related methods) whereby slicing is perceived to be an issue.

Thanks for all the hard work, and thank to all who contribute.
19  Java Game APIs & Engines / JOGL Development / Re: JOGL 1.1.1 PBuffer ATI setOffscreenRenderToTexture on: 2005-09-14 21:04:15
Thanks for clarification Ken. I'll check the latest from CVS.
20  Java Game APIs & Engines / JOGL Development / JOGL 1.1.1 PBuffer ATI setOffscreenRenderToTexture on: 2005-09-14 06:32:56

Upon upgrading to JOGL 1.1.1 from JOGL 1.0, creating a pbuffer no longer works. During, GLException is thrown requesting that render-to-texture-rectangle is enabled. Enabling this property on an ATI Radeon 9000 is fruitless since the card does not support non-power-of-two textures.

By searching the forums, only other thread that mentioned similar problem (ATI card) was due to improper use of texture coordinates, however in this case nothing was changed from fully working to not working; the only changes being replacement of the libraries (jar, dll) with the latest version (1.1.1).

Some info:

GLEventListener.init  {

GLCapabilities c = ...


pBuffer = canvas.createOffscreenDrawable(c, 512, 512);


// I then prime the pbuffer as per requirement, due to a bug in 1.0 which failed
// to call GLEventListener.init of the instance attached to the pbuffer.
} {



// render geometry


What stumped me is the fact that this code works perfectly on JOGL 1.0, and also works "perfectly" provided pbuffer
support is not used on JOGL 1.1.1.

Win2k, Catalyst 5.8

If anyone has experienced this problem, please let me know.
Thanks for all the help you can offer.

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

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

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

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

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

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

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

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

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

nelsongames (2614 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!