[Note: I’ve updated this thread with a more descriptive subject. -Mike]
I’m not sure if it’s too early to report bugs on the TestTerrainPage example, but here’s what I’m seeing from this evening’s cvs (pulled in a few minutes ago):
jmetest.terrain.TestTerrainPage:
INFO: Child (scene) attached to this node (Root node)
Apr 20, 2004 8:52:50 PM com.jme.scene.Node attachChild
INFO: Child (FPS counter) attached to this node (Root node)
org.lwjgl.opengl.OpenGLException: Invalid enum (1280)
at org.lwjgl.opengl.Util.checkGLError(Unknown Source)
at org.lwjgl.opengl.Window.update(Unknown Source)
at com.jme.renderer.lwjgl.LWJGLRenderer.displayBackBuffer(LWJGLRenderer.java:404)
at com.jme.app.BaseGame.start(BaseGame.java:74)
at jmetest.terrain.TestTerrainPage.main(TestTerrainPage.java:78)
Apr 20, 2004 8:52:51 PM com.jme.app.BaseGame start
I’m getting the same bug for jmetest.terrain.TestTerrain and TestTerrainLighting, both of which used to work earlier this weke.
-Mike
url: file:/E:/Programming/jme/bin/jmetest/data/images/Monkey.jpg
Stats are true
16384
org.lwjgl.opengl.OpenGLException: Invalid enum (1280)
at org.lwjgl.opengl.Util.checkGLError(Unknown Source)
at org.lwjgl.opengl.Window.update(Unknown Source)
at com.jme.renderer.lwjgl.LWJGLRenderer.displayBackBuffer(LWJGLRenderer.java:404)
at com.jme.app.BaseGame.start(BaseGame.java:74)
at jmetest.terrain.TestTerrainLighting.main(TestTerrainLighting.java:73)
Looks like this bug is not specific to Terrain. Everything, including my own code, breaks with the same error. Here’s a dump from TestSimpleGame.
org.lwjgl.opengl.OpenGLException: Invalid enum (1280)
at org.lwjgl.opengl.Util.checkGLError(Unknown Source)
at org.lwjgl.opengl.Window.update(Unknown Source)
at com.jme.renderer.lwjgl.LWJGLRenderer.displayBackBuffer(LWJGLRenderer.java:404)
at com.jme.app.BaseGame.start(BaseGame.java:74)
at jmetest.base.TestSimpleGame.main(TestSimpleGame.java:13)
Going back to my pre-upgraded jar file makes my own code work again, so I'm guessing it's not just something specific to my system.
Mike,
I don’t see this bug at all here, nor have others I’ve asked to look into it. Basically, .9 lwjgl includes a fail point in the display back buffer call which will throw an exception if the card has reported an OpenGL error since the last display back buffer call.
That said, it sounds like it could be an issue that may only affect your particular card or setup. Please list out your specs. I know you say an older version of jME fixes the issue, how old are we talking about? Also, what changes have you made in your local version?
The reason I haven’t updated the thread yet is that I’m tracking down exactly when the problem started happening in cvs. I’m using unmodified cvs with TestMilestone2 as the testing program.
So far I’ve narrowed it between -D “2004-04-16 14:30” and -D “2004-04-17:00” in cvs. (Actually, at 14:30, I no longer see the monkey image being textured onto the cube for TestMilestone2 while it was there on 12:00, but it’s at least still running.)
My hardware on this machine is an on-board NVIDIA RIVA TNT2 Model 64 Pro.
Ok. I’ve narrowed it down to this timeframe:
Milestone2 2004-04-16 15:02 works albeit without texturing on the cube face (pure white).
Milestone2 2004-04-16 15:05 generates the error.
The only difference I see between the 15:02 code and the 15:05 code is that several classes, including TestMilestone2, were updated to include this line:
scene.updateRenderState();
Hopefully this helps.
That just means that renderstates are making some kind of problem on your system. You didn’t see it before the move to lwjgl.9 b/c it wasn’t throwing all errors until then. Try going into initGame and setting enabled on these to false:
as1
buf
state
They all have .setEnabled(true) right now, so find that line and turn it to false. (this should be on the current copy of the code) Now, milestone 2 should run without textures, etc. (similar to 15:02) If it doesn’t run, the default states are somehow making a mess on your system.
Assuming it does run ok though, try turning on as1, buf and state individually and seeing if you can narrow down the problem there.
You have a fairly old card, so it’s possible we are assuming support of some feature that is not supported on your card. Unfortunately, GeForce2 MX is the oldest card I have here…
If the above doesn’t help, you can narrow the problem down further by commenting out apply methods in the various LWJGL state classes until you figure out which class is throwing you off.
Does TNT2 support multi-texturing?
For what it’s worth, the TestMilestone2 monkey textures went away between 13:12 and 13:15.
Unfortunately, the diffs between those two times changed too many things for me to say what might have changed.
Here’s a partial list of what files were changed (the ones most likely):
Files jme/src/com/jme/image/Texture.java and jme-2004-04-16_13-15/src/com/jme/image/Texture.java differ
Files jme/src/com/jme/renderer/Renderer.java and jme-2004-04-16_13-15/src/com/jme/renderer/Renderer.java differ
Files jme/src/com/jme/renderer/lwjgl/LWJGLRenderer.java and jme-2004-04-16_13-15/src/com/jme/renderer/lwjgl/LWJGLRenderer.java differ
Files jme/src/com/jme/scene/CloneNode.java and jme-2004-04-16_13-15/src/com/jme/scene/CloneNode.java differ
Files jme/src/com/jme/scene/Geometry.java and jme-2004-04-16_13-15/src/com/jme/scene/Geometry.java differ
Files jme/src/com/jme/scene/Node.java and jme-2004-04-16_13-15/src/com/jme/scene/Node.java differ
Files jme/src/com/jme/scene/Spatial.java and jme-2004-04-16_13-15/src/com/jme/scene/Spatial.java differ
Files jme/src/com/jme/scene/state/AttributeState.java and jme-2004-04-16_13-15/src/com/jme/scene/state/AttributeState.java differ
Files jme/src/com/jme/scene/state/LightState.java and jme-2004-04-16_13-15/src/com/jme/scene/state/LightState.java differ
Files jme/src/com/jme/scene/state/RenderState.java and jme-2004-04-16_13-15/src/com/jme/scene/state/RenderState.java differ
Files jme/src/com/jme/scene/state/TextureState.java and jme-2004-04-16_13-15/src/com/jme/scene/state/TextureState.java differ
Files jme/src/com/jme/scene/state/lwjgl/LWJGLAlphaState.java and jme-2004-04-16_13-15/src/com/jme/scene/state/lwjgl/LWJGLAlphaState.java differ
Files jme/src/com/jme/scene/state/lwjgl/LWJGLAttributeState.java and jme-2004-04-16_13-15/src/com/jme/scene/state/lwjgl/LWJGLAttributeState.java differ
Files jme/src/com/jme/scene/state/lwjgl/LWJGLCullState.java and jme-2004-04-16_13-15/src/com/jme/scene/state/lwjgl/LWJGLCullState.java differ
Files jme/src/com/jme/scene/state/lwjgl/LWJGLDitherState.java and jme-2004-04-16_13-15/src/com/jme/scene/state/lwjgl/LWJGLDitherState.java differ
Files jme/src/com/jme/scene/state/lwjgl/LWJGLFogState.java and jme-2004-04-16_13-15/src/com/jme/scene/state/lwjgl/LWJGLFogState.java differ
Files jme/src/com/jme/scene/state/lwjgl/LWJGLLightState.java and jme-2004-04-16_13-15/src/com/jme/scene/state/lwjgl/LWJGLLightState.java differ
Files jme/src/com/jme/scene/state/lwjgl/LWJGLMaterialState.java and jme-2004-04-16_13-15/src/com/jme/scene/state/lwjgl/LWJGLMaterialState.java differ
Files jme/src/com/jme/scene/state/lwjgl/LWJGLShadeState.java and jme-2004-04-16_13-15/src/com/jme/scene/state/lwjgl/LWJGLShadeState.java differ
Files jme/src/com/jme/scene/state/lwjgl/LWJGLTextureState.java and jme-2004-04-16_13-15/src/com/jme/scene/state/lwjgl/LWJGLTextureState.java differ
Files jme/src/com/jme/scene/state/lwjgl/LWJGLVertexProgramState.java and jme-2004-04-16_13-15/src/com/jme/scene/state/lwjgl/LWJGLVertexProgramState.java differ
Files jme/src/com/jme/scene/state/lwjgl/LWJGLWireframeState.java and jme-2004-04-16_13-15/src/com/jme/scene/state/lwjgl/LWJGLWireframeState.java differ
Files jme/src/com/jme/scene/state/lwjgl/LWJGLZBufferState.java and jme-2004-04-16_13-15/src/com/jme/scene/state/lwjgl/LWJGLZBufferState.java differ
Files jme/src/com/jme/system/DisplaySystem.java and jme-2004-04-16_13-15/src/com/jme/system/DisplaySystem.java differ
Files jme/src/com/jme/system/lwjgl/LWJGLDisplaySystem.java and jme-2004-04-16_13-15/src/com/jme/system/lwjgl/LWJGLDisplaySystem.java differ
Files jme/src/com/jme/widget/WidgetAbstractImpl.java and jme-2004-04-16_13-15/src/com/jme/widget/WidgetAbstractImpl.java differ
Files jme/src/com/jme/widget/impl/lwjgl/WidgetLWJGLAbstractRenderer.java and jme-2004-04-16_13-15/src/com/jme/widget/impl/lwjgl/WidgetLWJGLAbstractRenderer.java differ
Files jme/src/com/jme/widget/impl/lwjgl/WidgetLWJGLSliderThumbRenderer.java and jme-2004-04-16_13-15/src/com/jme/widget/impl/lwjgl/WidgetLWJGLSliderThumbRenderer.java differ
Files jme/src/com/jme/widget/text/WidgetText.java and jme-2004-04-16_13-15/src/com/jme/widget/text/WidgetText.java differ
Does TNT2 support multi-texturing?
Answering my own question… it appears to from what I’ve read.
"renanse" wrote:
That just means that renderstates are making some kind of problem on your system. You didn't see it before the move to lwjgl.9 b/c it wasn't throwing all errors until then.
Actually, I started working with jME after your move to lwjgl.9.
Thanks for the suggestions. I'll give them a try.
Unfortunately, my only other system has a RADEON 7200 which doesn't appear to be supported at all. [Cannot create window: Could not choose ARB pixel formats.]
-Mike
Unfortunately, my only other system has a RADEON 7200 which doesn't appear to be supported at all. [Cannot create window: Could not choose ARB pixel formats.]
Make sure you let LWJGL know this. That's an LWJGL issue.
Actually, I’m betting it’s LWJGLVertexProgramState. I’ll fix that up and see what you get from that.
committed… please try again
I’ve reported the ARB error.
Have you considered preserving the original exception rather than just generating a new one in these cases? Perhaps a chained exception? I had to go back into the source to generate a stack trace of the actual problematic code.
-Mike
"renanse" wrote:
Actually, I'm betting it's LWJGLVertexProgramState. I'll fix that up and see what you get from that.
Yes, whatever you did has fixed both problems.
No more error, and the textures have returned.
Thanks!
-Mike
org.lwjgl.opengl.OpenGLException is thrown by LWJGL. And I’m with you, finding the location of the problem is very difficult. The trouble lies in that OpenGL errors aren’t generated until the card tries to process the current data with the current state. So, when (in this case) set the vertex program state enabled in GL, it didn’t know that there was a problem until the buffer was swapped and it tried to render it.
"mojomonk" wrote:
org.lwjgl.opengl.OpenGLException is thrown by LWJGL. And I'm with you, finding the location of the problem is very difficult. The trouble lies in that OpenGL errors aren't generated until the card tries to process the current data with the current state. So, when (in this case) set the vertex program state enabled in GL, it didn't know that there was a problem until the buffer was swapped and it tried to render it.
Actually, I was speaking of the Window.create error.
The code catches the LWJGLException and rethrows a generic Error, saving only the original message. (LWJGLDisplaySystem.java)
Another thing that might be helpful is to provide debugging info in the built jars. I can understand why it might not be desirable for the jme.jar, but the test code at least seems like it should be built with the debug="true" option.
As long as I'm now WAY off topic....
One thing we've done in the cayenne database project is to compile in the build-date and version number into the custom Exception classes.
This makes it far easier to tell when the problem is caused by a user running an old version.
-Mike
good advice, thanks. Also means that the error post sent to LWJGL is our fault. ://
No, as I said, I went in, and rewrote the code to expose the real error.
It’s really an LWJGL problem. At least, that’s what it looked like to me.
See the following url for details:
http://puppygames.net/forums/viewtopic.php?t=543&sid=2123994bb8cc7aceea14699975c744fd
-Mike