Problem with displayBackBuffer

Troubleshooting General Help
1

I have a simple terrain which is created using


      tb = new TerrainBlock("Terrain", terrainSize, vector3f,terrainMap, new Vector3f(0, 0, 0), false);


But when I run the test I am keep getting:

INFO: Child (3D Scene Node) attached to this node (rootNode)
15-Aug-2004 11:37:52 com.jme.scene.Node attachChild

INFO: Child (Camera Node) attached to this node (3D Scene Node)

org.lwjgl.opengl.OpenGLException: Invalid value (1281)
at org.lwjgl.opengl.Util.checkGLError(Unknown Source)
at org.lwjgl.opengl.Window.update(Unknown Source)
at com.jme.renderer.lwjgl.LWJGLRenderer.displayBackBuffer(Unknown Source)
at com.jme.app.VariableTimestepGame.start(Unknown Source)
at HandTrain.main(HandTrain.java:62)

15-Aug-2004 11:37:53 com.jme.app.VariableTimestepGame start
INFO: Application ending.

Having checked the code for displayBackBuffer(), it doesnt have any input arguments.(I am using the CVS version which I donwloaded on Aug 13). Does anybody know what is happening?
tomcat
2

I have tested the program with a previous jme built and the program works. The difference between the old build and new one is:



Old build


    public void displayBackBuffer()
    {
        GL11.glFlush();
        Window.update();
    }



New build


    public void displayBackBuffer()
    {
      processingQueue = true;
      queue.renderBuckets();
      processingQueue = false;

      GL11.glFlush();
      Window.update();
    }



What is causing this problem?
tomcat
3

Let me repeat myself and expound a bit on this topic.



GL errors are automatically checked every frame by LWJGL. This happens in ONE place and that is Window.update(); So no matter where the openGL call is that is causing your program error, it is going to generate a stack trace at that point in the code. Thus, the differences in the two methods you point out is likely not the cause of the exception.



A stack trace like yours means that some openGL code called by jME is invalid for your card. It may also be invalid for everyone’s card, however it is more likely that your card needs a driver update or just can’t support the given code. The reason the old jME lib worked is likely because jME did not previously contain feature X or optimization X that is now causing your card to choke. If you can find out what the feature is (debugging and putting a watch on org.lwjgl.opengl.Util.checkGLError or similar for example) and it’s just incompatible with a large array of cards, we could put in an alternative path for those cards. (Honestly, I don’t think the 9600 should have any problems because others on this forum use that card.)



If you want to be absolutely positive that it is not the RenderQueue, you can always force off render queue on each of your scene objects.

4

I have the same problem… with an ATI 9600 Pro.

5

Update your graphics card drivers, and try again

6

BTW anyone know what was added between 0.6 and 0.7 that is causing this?

7

One possibility is Aniso filtering. I noticed it was not checking for support before setting the level, this was fixed a few days after the .7 cut. I WAS a bit more certain it was that when people were just complaining about old laptop cards, but now I’m not sure given the 9600 mentioned above.

8

I just updated the drivers and there is no difference.

I tested with a terrain test (based on the examples) and while fooling around

with the code, everything runs fine as soon as the terrain doesn’t use multi texturing…



Since OpenGL is complaining about an invalid value, could it be that one of the static constants have been modified by mistake and sending, of course, a wrong value?



BTW, i saw the problem first at my friend’s house a couple of hours ago, and he has a GeForce 4 440 MX with the very latest drivers.

9

So you’re saying it’s your own test, not one of the tests from cvs (pure and unmodified?)

10

I just tried strait with the TestTerrainPage class in jME, and i have updated from the cvs about 2 hours ago. Same result.



They are the same, for the terrain, i just copy/paste the terrain code so i could fool around with it without playing the original code. I haven’t had much time to play with jME lately.

11

Hmm, testing here… GF4 ti 4600, no probs… Radeon 9800 XT, no probs… Does the webstart version of that test work?

12

Hi.

My webstart version also does not want to work!

I’m really getting sick of this…

I would really like to finish jMEditorV0.2… Still using jME0.6.

13

Well, i never used webstart, never had to. How do i test that?

And i use Eclipse if that helps…

14

the webstart demos are here:



http://mojomonkeycoding.com/index.php?option=content&task=view&id=10&Itemid=33



Find the TestTerrainPage one near the bottom and click on it.



Edit: Oops, TestTerrainPage is not linked, but you can try TestTerrain instead as it also does multi texture.

15
"tGiantLabs" wrote:
Hi.
My webstart version also does not want to work!
I'm really getting sick of this.........
I would really like to finish jMEditorV0.2.... Still using jME0.6.

When I spoke to you before by email, you said all tests even simple ones did not work, so it's a different issue than Spadz... Have you tried updating from cvs today and still find that's the case?
16

No I did not!

Will do now.

Actually I did not update for a while now, sorry. Maybe it will

work.



Thanks.

17

A few things have definitely been fixed recently, but those things may or may not solve your problem, so I’m not saying it will definitely fix it, but worth a shot. :slight_smile:

18

Well, now i’m happy and pissed at the same time!



It works. When i said i tested with the Terrain in Jme… it didn’t. Long story.



My own test screws up, but webstart and the the test in jME work.

I’m going to figure out what the hell is the problem with my code.

What pisses me off is that my code worked just fine a while ago…



I’ll keep you posted, now i’m going to sleep…



Thanks alot.

19

Yeaaaa…

Mine is working!!!

20

Hi,



I found the difference between my code and jME’s code for the terrain that

generates the exception.



the method textureX.setCombineScaleRGB(1.0f) won’t take 0 as value. As i have wrote before, my code used to work before 0.7 from CVS with 0 as value. But as long as it works now…



Anyways, by setting to 1.0f, like the example, it works perfectly.

I hope this helps you get an idea what changes were made that made it crash.

I’m not an OpenGl guru, but i’ll look into it.