I am new to the jMonkey Engine. I set up jME 2.0 with Eclipse and currently I am taking a look at the tests in the package jmetest.
All run fine, but choosing JOGL as renderer and hitting the F4 button for stats causes crashes with this message (I attached the complete log):
SCHWERWIEGEND: Exception in game loop
java.nio.BufferOverflowException
at java.nio.Buffer.nextPutIndex(Buffer.java:495)
at java.nio.DirectFloatBufferU.put(DirectFloatBufferU.java:245)
at com.jme.util.stat.graph.LineGrapher.createVLines(LineGrapher.java:291)
at com.jme.util.stat.graph.LineGrapher.statsUpdated(LineGrapher.java:135)
at com.jme.util.stat.StatCollector.fireActionEvent(StatCollector.java:328)
at com.jme.util.stat.StatCollector.update(StatCollector.java:255)
at com.jme.app.BaseSimpleGame.update(BaseSimpleGame.java:222)
at com.jme.app.SimpleGame.update(SimpleGame.java:56)
at com.jme.app.BaseGame.start(BaseGame.java:84)
at jmetest.effects.TestParticleSystem.main(TestParticleSystem.java:61)
06.01.2009 23:07:48 com.jme.app.BaseSimpleGame cleanup
INFO: Cleaning up resources.
06.01.2009 23:07:48 com.jme.app.BaseGame start
INFO: Application ending.
Is there any incompatibility with jogl in jME or maybe did I something wrong building the jME 2.0 jars?
Ok, I debugged the TestTeapot example and found out that the crashes relate to my card. The Hardware Compatibility List notes for Radeon Mobility 7500:
Pretty slow, shader passes & cloth don't work. Render to Texture does some strange things.
JOGLDisplaySystem tries to create a JOGLTextureRenderer. In com.jme.renderer.jogl.JOGLTextureRenderer I get until the message "FBO not supported.". Then the program returns at line 119, so that the width of the JOGLTextureRenderer is not set at line 168. :( The width remains 0 and this causes problems in further calculations.
Well, considering that video chipset was developed almost 10 years ago I would say that its pretty amazing that its running jME at all :)
(remember that was around the 1GHZ processors time frame...)
My laptop is from 2002 and showing stats with lwjgl works fine.
So are you planning any workaround (how does it work in lwjgl?) for showing stats in connection with jogl and cards that don't support FBOs or is the only answer "Tough luck!"?
Download latest drivers? Doing that allowed my RIVA TNT to have FBO support and GeForce 2 to have vertex shader support.
I guess Pbuffer support wasn't added for JOGL as Pbuffers are a platform specific thing. That means each OpenGL binding must implement it's own platform independent interface for accessing Pbuffers. Differences in that interface between JOGL & LWJGL could hinder the porting process of the Pbuffer TextureRenderer from LWJGL into JOGL.
lol, no I didn't mean "Tough Luck" what I mean was that it is an older v-card (ok maybe not Riva-TNT old :P) and the fact that it runs a lot of those tests is pretty cool (image how those peeps feel that just went out got a new lappy w/ SiS and try to launch the 'cool' jME tests…)
So are you planning any workaround (how does it work in lwjgl?) for showing stats in connection with jogl and cards that don't support FBOs
I was thinking, after I read your first post, that their should be a 'fall-back' method (maybe just the old-skool FPS stats again). Maybe thats something you could help with :)
Differences in that interface between JOGL & LWJGL could hinder the porting process of the Pbuffer TextureRenderer from LWJGL into JOGL.
That is definetly a concern, would we have to go through each of the bindings source to determine what if any differences exist? Or maybe we can just do some research/troubleshooting and talk to the folks at JOGL about it?
Momoko_Fan: do you think this is related to the JOGL water 'issues'?
Well, it is a difficulty with this card. There are no recent drivers for Mobility 7500, as it is no longer supported by ATI (and I heard there are some license issues with notebook manufacturers). I tried the omega drivers (though I had previously several hangups with them) but they don't help :(
@basixs: OK :)
basixs said:
I was thinking, after I read your first post, that their should be a 'fall-back' method (maybe just the old-skool FPS stats again). Maybe thats something you could help with :)
Yes, this would be great (at least it would be ok, if there was no crash).
Well, yes and no; because of the way the new community is I like 'poking' people just to say "hey, if thats something you can do, then help jME help you :)". Too often I assume that people have more confidence in their skills than what they really do, but then again as my favorite professor used to say "If you don't push yourself, how can you ever find you limits?".
So, if you feel like you can try to tackle something like that then GREAT! (hint: the rendering is the only problem, so is there a way test for the the problem, then to tap into the already accumulating rendering stats and print them as simple text?) If not then it basically will go on the (metaphorical) list of things that should be done for a better user experience...
Since I don't know much about how jME works, it would be a motivation for learning it.