Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (726)
Games in Android Showcase (217)
games submitted by our members
Games in WIP (796)
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] 2
1  Discussions / General Discussions / Re: Programmer jokes on: 2014-03-20 19:08:36
The two hardest problems facing computer programmers:

1. cache invalidation
2. naming things, and
3. off-by-one errors

(e.g. from
2  Discussions / General Discussions / Re: Garbage collector tuning on: 2012-07-31 17:58:21
I ripped a smaller test case out of a 3d demo to see if scalar replacement works. In my case it did an amazing job. Here's the link to my blog entry:
3  Discussions / General Discussions / Re: JVMs other than HotSpot? on: 2012-06-24 12:48:43
I can confirm that JET is pretty fast. I published a benchmark four years ago where some JVMs were compared:

For interactive applications I'd recommend to compare GC pause times as well. Last time I checked JET had significantly larger pause times than Oracle's Hotspot VM.
4  Game Development / Performance Tuning / Re: HotSpot optimization list on: 2012-05-17 07:39:43
Cool list.

I'd like to add scalar replacement (since ~2008) which depends on escape analysis (see Found it amazingly effective in the context of typical 3d math (detail in my blog entry

I'd really like to see more articles testing the effectiveness and limitations of those optimizations (e.g. range check elimination, inlining).

As for devirtualization I found two nice articles:
5  Game Development / Performance Tuning / Re: How to check whether scalar replacement worked? on: 2012-01-16 21:21:52
Very cool - thanks. A debug VM used to be available for pre-release JDKs, but I don't find it anymore for JDK 8 or JDK 7u4. Do you build it yourself or is it still available for download?
6  Game Development / Performance Tuning / How to check whether scalar replacement worked? on: 2012-01-16 19:17:18
Scalar replacement in the jvm is pretty cool, but my problem is that I don't know an easy way to check if and where it works. Does anyone have an idea how to check whether an allocation has been replaced?
So far the only way I found is to run a stress test for the method in question with "-verbose:gc" and see if the gc runs less often.
Any better ideas?

7  Discussions / General Discussions / Re: double d = 2.2250738585072012e-308; on: 2011-02-09 12:07:42
Really? It was made public on 01/31 here:

(and yes - it should never have been disclosed that way...)
8  Discussions / General Discussions / Re: Goso - new JVM language on: 2010-11-10 19:29:25
Well, Scala is fairly fast. I wonder how Gosu compares. (I probably won't use either though.)

Unless you use a simple for-loop ( ). Must that good old for (int i=0;i<10;i++) really be deprecated?

And what strikes me most is that I'm afraid I'll never fully grasp the scala type system - take a look at
Maybe then the Gosu approach to accept an inconsistent type system isn't that bad as long as your team understands the restrictions (and java arrays definitely caused less trouble than java generics for the teams I've worked with)
9  Java Game APIs & Engines / JOGL Development / Some background for JOGL2? on: 2009-09-17 21:09:31
I managed to migrate to JOGL2 (and killed all that fixed function pipeline stuff). It works, but I don't really understand what I'm doing. The only source I found so far is .

Is there some information available:
* What's the packing strategy? What JARs, LIBs have to be or should be in the classpath? (There are quite a lot of them and some time ago the *.all.jar meant all but DebugGL etc.)
* What's nativewindow and newt? When would you use it? Is active rendering the preferred way to render then? What's the event threading model used...

Thanks for any insights!
10  Java Game APIs & Engines / JOGL Development / Re: JOGL2: EXT_DIRECT_STATE_ACCESS and OpenGL 3.1 on: 2009-08-09 17:59:33
@sgoethel: Do you consider adding NV_vertex_buffer_unified_memory and NV_shader_buffer_load as well?
(Though I consider that doing so might be hard work, cause they don't fit the OpenGL 3.1 deprecation model well.)

11  Java Game APIs & Engines / JOGL Development / Re: JOGL2: EXT_DIRECT_STATE_ACCESS and OpenGL 3.1 on: 2009-08-02 17:46:56
Thanks - great to see JOGL2 is alive and kicking.
12  Java Game APIs & Engines / JOGL Development / JOGL2: EXT_DIRECT_STATE_ACCESS and OpenGL 3.1 on: 2009-08-01 19:41:24
First let me say I'm very happy to see that JOGL has a future (even if quite an incompatible one...)

The current version of JOGL2 doesn't have support for EXT_DIRECT_STATE_ACCESS. Do you plan to add this extension?

How are you going to support OpenGL 3.1? Create a new interface (GL3_1) with the deprecated functions removed?

13  Java Game APIs & Engines / JOGL Development / OpenGL 3.1 on: 2009-03-25 19:18:54
Now that OpenGL 3.1 is released and (beta) driver support is also already there from day one (nvidia even released a linux version!) I'm excited to see if JOGL and when lwjgl will support OpenGL 3.1 and how the removal/deprecation of functions shows up in the java api.
14  Game Development / Performance Tuning / Re: high cpu usage with JOGL on: 2009-02-24 19:10:25
Do not use nor Animator neither FPSAnimator.
@gouessej: I think it hasn't been answered yet. Could you please tell us why not? (Would you suggest using active rendering instead?)
15  Java Game APIs & Engines / JOGL Development / Re: Official OpenGL 3.0 support / How dead is JOGL? on: 2008-12-30 18:57:18
Personally I don't know why JOGL exists. It tries to have object oriented approach on too low level and imposes arbitrary limits that OpenGL doesn't have.

Can you please explain what limits JOGL imposes? I don't know any GL feature that LWJGL supports and JOGL does not (except GL3 of course). And I'm the greatest fan of DebugGL (and it's the object oriented approach that makes that decorator easily possible) - if I had had that with C++ it would have saved me much frustration. Is there something like that in LWJGL?

Another question: Do you LWJGL users really know to which GL revision or extension a specific function belongs (I don't) or do you have static import blocks that you simply copy each time?
16  Java Game APIs & Engines / JOGL Development / Re: Official OpenGL 3.0 support / How dead is JOGL? on: 2008-12-28 20:48:20
But I really wonder if it is enough to switch to LWJGL just for a particular feature. Is it really a "must-have" feature?
It depends - from a OpenGL user's view it isn't, but from a OpenGL programmer's view it is.
Anyways JOGL's promise (at least my view of it) was to be the Sun endorsed OpenGL API. That's what I'm looking for (I was sick of all the short lived OpenGL extensions C++ wrappers), but if JOGL fails to support OpenGL 3 now (though as we've seen it shouldn't be too difficult - just a bunch of extensions and maybe some initialization stuff) then I lose confidence that JOGL will support the next revisions of OpenGL in time.
17  Java Game APIs & Engines / JOGL Development / Re: Official OpenGL 3.0 support / How dead is JOGL? on: 2008-12-19 19:32:56
Thanks for your answers - at least the community seems to be alive ;-)

Good to see that there is a momentum for JOGL (even if it's seem to be focused on OpenGL ES), but still a bit disappointing that there seem to be no GL 3 features in the JOGL_2_SANDBOX branch.
I really hoped that the official binding would keep up with current versions. I think I'll switch to LWJGL, since I want to play with the GL_EXT_direct_state_access extension.
18  Java Game APIs & Engines / JOGL Development / Official OpenGL 3.0 support / How dead is JOGL? on: 2008-12-19 12:58:10
Now that nvidia offers official opengl 3.0 support and JOGL offers no opengl 3 support I start to wonder whether JOGL is actually as dead as it currently seems. Is there any hope that after JavaFX has been pushed out we'll see opengl 3.0 support and new nightly builds?
19  Game Development / Performance Tuning / Re: Programming to the cache on: 2008-07-01 18:39:15
Last, your have that giant method that runs all the benchmarks. The JIT stops moptimising methods that are longer than a certain amount of instructions. That 'magic amount' is rather low, and your method will certainly not be turned into the most efficient native code. You can take a look at the output of the Debug VMs (release candidates with debug commandline options, IIRC) from Sun, which will tell you when the JIT gives up.
Can you tell more about that? Is there a -XX switch to adjust that limit? What options have to be set in the debug commandline  (Does -XX:PrintCompilation also show that effect)?
20  Java Game APIs & Engines / JOGL Development / Re: Optimisation problem with terrain rendering. on: 2007-11-01 21:16:02
You could try to set the materials just once.
You're passing a java array to glTexCoordPointer (and I guess the same is true for all other glXPointer calls). You should see a much better performance when you switch to vertex buffer objects (VBO) with direct buffers instead.
21  Game Development / Performance Tuning / Re: immutable, cloned, or mix? on: 2007-07-09 16:13:03
I "solved" this problem by having Vector2f (etc) implement two interfaces, ReadableVector2f and WriteableVector2f. When I don't want people to think they can edit the vector directly I return a ReadableVector or pass a ReadableVector in and copy it into an existing Vector2f. I use this consistently throughout nearly all of my code.

The technique is not foolproof (a cast will thwart it) but it avoids cloning and avoids garbage, and so it's good and fast.

Cas Smiley
I used that too, but in comparison to immutable types I think it's still too mutable. It works fine for types you create and return (which shouldn't be changed by clients), but it doesn't free you completely from making defensive copies and it doesn't make those objects threadsafe.
22  Game Development / Performance Tuning / Re: performance of many method calls on: 2007-05-04 19:37:49
Yes, it can definitely make a (sometimes even huge) difference to manually inline, but will it be worth it? (i.e. does your profiler say this code is your bottleneck?).
OTOH I have also seen cases where manual inlining caused *massive* slow downs.

Does someone have facts under what conditions the c1 or c2 hotspot compilers are able to inline methods?
23  Java Game APIs & Engines / JOGL Development / Re: Performance of JNI with lots of OpenGL calls on: 2007-04-10 19:18:44
My guess would be either that inefficiencies were introduced during your translation of the benchmark,
Ken, you were absolutely right. I took the Java GLUT code and ported it back to c and got different results:

Java (1st iteration)
FBO Texture Rendering FPS: 237.485172
Teapot Shader FPS: 164.152181
Frame overhead secs/frame: 0.000020
OS/GLUT overhead secs/frame: 0.000587
Overall FPS: 91.658273

Java (2nd iteration)
FBO Texture Rendering FPS: 240.625000
Teapot Shader FPS: 165.317919
Frame overhead secs/frame: 0.000024
OS/GLUT overhead secs/frame: 0.000356
Overall FPS: 94.478528

FBO Texture Rendering FPS: 244.326587
Teapot Shader FPS: 162.869442
Frame overhead secs/frame: 0.000023
OS/GLUT overhead secs/frame: 0.000012
Overall FPS: 97.392490

Actually these results are quite impressive! Although the code is creating incredibly many OpenGL calls it's very close to the C version.
It's just too strange that the teapot function made the difference - I even compared your GLUT version with some version found on google code. Apparently my installed version of GLUT uses a simpler method to render the teapot.
24  Java Game APIs & Engines / JOGL Development / Re: Jogl using swt on: 2007-04-10 19:03:39
           I am a new user of Jogl using swt  , I want to get information abt JOGL using swt and any books related to them .
It would be a Great  help If some one can refer to some useful material as well some links refering to code samples .
Did you check snippet #209 on ?
25  Java Game APIs & Engines / JOGL Development / Performance of JNI with lots of OpenGL calls on: 2007-04-02 20:46:04
Recently there was a small benchmark on
I thought that it might be fun do a quick conversion to java, but if I had known the results before I maybe wouldn't have.
The c version prints something like:

FBO Texture Rendering FPS: 239.646497
Teapot Shader FPS: 570.048602
Frame overhead secs/frame: 0.000044
OS/GLUT overhead secs/frame: 0.000011
Overall FPS: 167.167671

The JOGL (JOGL 1.1 rc 3, JDK 6) version returns:
FBO Texture Rendering FPS: 208.672087
Teapot Shader FPS: 153.128346
Frame overhead secs/frame: 0.000035
OS/GLUT overhead secs/frame: 0.000584
Overall FPS: 83.737661

Obviously using GLUT functions and using immediate mode isn't the best performing way of woking with OpenGL today, but I think the benchmark might have a purpose for showing the overhead on JNI. Is that expected that JNI adds that much overhead (I had expected something like 10-20% overhead)?
Would you have expected such a large difference?
If you want to run the benchmark or check my conversion (after all - maybe there's a bug somewhere) see the attached file.

26  Game Development / Performance Tuning / Re: Quiet in here these days... on: 2007-02-07 21:19:38
Let me add two questions:
Is it just me who is waiting every week for the next JDK 7 build, hoping it'll come with tiered compilation?
Anyone tried the IBM 6 pre-release? It has a not yet documented but nonetheless mentioned feature called "Data sharing between JVMs: Ahead Of Time (AOT) compiled code" - sounds interesting...
27  Java Game APIs & Engines / JOGL Development / Re: SWT/OpenGL Bindings v0.7.0 released - now with lightweight Draw2D support on: 2007-01-12 17:52:05
I have a very strange problem when I render with JOGL on a SWT Shell both for the JOGL RI and your JOGL SWT lib (that I also posted on the swt newsgroup but without reply). When I try to use FBOs with SWT I'm getting a black screen on windows as soons as I bind the fbo and an occasional flickering on linux (both with current nvidia drivers). Using the same FBO code for rendering works fine with AWT. If I don't use FBO all rendering works perfectly for both AWT and SWT.
Do you have any idea what could cause that?  (Something like special caps for FBO or so?)

28  Game Development / Performance Tuning / Re: System.nanoTime() very slow on linux on: 2006-05-12 08:16:10
but when your going to run the actual algorithm, your not going to be keeping those nanoTime calls there are you?
I actually consider removing the profiling functions once it's done ;-)

Currently I'm profiling the time per object and there are about 130 objects in the scene and thus 260 calls to System.nanoTime. 
29  Game Development / Performance Tuning / System.nanoTime() very slow on linux on: 2006-05-11 19:18:56
System.nanoTime() is a great way to find performance problems when System.currentTimeMillis's resolution isn't sufficient.

But I had to discover the drawback of System.nanoTime when I compared the runtime of a benchmark on windows and linux.
To my surprise it turned out that windows took something like 1.23 msec and linux took 1.67 msec for the same algorithm (computing the silhouette of a 3d object) on the same jdk version(1.5.0_06). It turned out that actually the operating system doesn't influence the duration of the algorithm, but that System.nanoTime() is so much slower on linux than on windows!

Is this a known effect (Maybe this is a notebook specific effect due to CPU power saving)? I think it's particularly bad that the longer duration of System.nanoTime influences the measurement itself!

As a workaround: What high precision, low impact timer that runs on both windows and linux can you recommend (that also works on notebooks - where simple RTDSC based timers appear to fail)?

30  Java Game APIs & Engines / JOGL Development / Re: JOGL and Opengl version on: 2006-05-07 12:40:19
I am using ATI Radeon 9250
I'm not 100% sure, but I do think that the 9250 is feature-wise identical with the radeon 9000, wich is a DX8 class card lacking hardware support for GLSL and OpenGL 2.0. I think that you need at least a radeon 9500 to have GLSL / OpenGL 2.0 support.
Is there someone who knows exactly?
Pages: [1] 2
Archive (292 views)
2017-04-27 17:45:51

buddyBro (481 views)
2017-04-05 03:38:00

CopyableCougar4 (925 views)
2017-03-24 15:39:42

theagentd (939 views)
2017-03-24 15:32:08

Rule (950 views)
2017-03-19 12:43:22

Rule (918 views)
2017-03-19 12:42:17

Rule (920 views)
2017-03-19 12:36:21

theagentd (981 views)
2017-03-16 05:07:07

theagentd (892 views)
2017-03-15 22:37:06

theagentd (690 views)
2017-03-15 22:32:18
List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05

SF/X Libraries
by SkyAphid
2017-03-02 06:38:56

SF/X Libraries
by SkyAphid
2017-03-02 06:38:32

SF/X Libraries
by SkyAphid
2017-03-02 06:38:05

SF/X Libraries
by SkyAphid
2017-03-02 06:37:51 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!