CVS Check-in Feb. 5 2007

I'll be checking in a large chunk of changes today. There may be a period (1 hour or so) where the build is broken due to incomplete check-in. Please, be patient. There could be a few areas where code changes will be required on the application end. These areas will have their own topic created.

Check in is complete.



This includes:


  1. LWJGL 1.0 Release
  2. Collision System revamp
  3. TextureRenderer revamp
  4. many other misc. features.



    Please reply ASAP if the build is broken for you.

there should be a note somewhere that junit is needed for building jme now.

It should be in the lib now… let me check.

Sorry, didn't get added to checkin, fixed and committed.

Does this include the new sound system features?



Also, does the texture renderer revamp include what Renanse references here: http://www.jmonkeyengine.com/jmeforum/index.php?topic=4464.0?



I look forward to breaking my projects this evening when I update. :wink:

Does this include the new sound system features?


No.

Also, does the texture renderer revamp include what Renanse references here: http://www.jmonkeyengine.com/jmeforum/index.php?topic=4464.0?


Yes.

i'll try and go trough the tests as soon as i have some time.

mojomonk said:

Does this include the new sound system features?


No.


......but......but.......but........dang it!  :cry:

Okay, so when do I get sound?  :-o
mojomonk said:

2. Collision System revamp

interesting - what's new?  (didn't have a look at the code / diff)

Sounds like very good new features! However, both my own code that use render to texture and TestProjectedWater are broken on a Geforce6600 and Geforce6800 (both on Windows). TestRTTSideBySide, TestRenderToTexture and TestCameraMan work.



My own implementation produces the following exception:

java.lang.RuntimeException: FrameBuffer: 1, has caused a GL_FRAMEBUFFER_INCOMPLETE_READ_BUFFER_EXT exception

        at com.jme.renderer.lwjgl.LWJGLTextureRenderer.checkFBOComplete(Unknown Source)

        at com.jme.renderer.lwjgl.LWJGLTextureRenderer.render(Unknown Source)

        at com.jme.renderer.lwjgl.LWJGLTextureRenderer.render(Unknown Source)

org.lwjgl.opengl.OpenGLException: Invalid framebuffer operation (1286)

        at org.lwjgl.opengl.Util.checkGLError(Util.java:56)

        at org.lwjgl.opengl.Display.swapBuffers(Display.java:555)

        at org.lwjgl.opengl.Display.update(Display.java:571)

        at com.jme.renderer.lwjgl.LWJGLRenderer.displayBackBuffer(Unknown Source)

        at com.jme.app.BaseGame.start(Unknown Source)



TestProjectedWater produces:

org.lwjgl.opengl.OpenGLException: Invalid value (1281)

        at org.lwjgl.opengl.Util.checkGLError(Util.java:56)

        at org.lwjgl.opengl.Display.swapBuffers(Display.java:555)

        at org.lwjgl.opengl.Display.update(Display.java:571)

        at com.jme.renderer.lwjgl.LWJGLRenderer.displayBackBuffer(Unknown Source)

        at com.jme.app.BaseGame.start(Unknown Source)

        at jmetest.effects.water.TestProjectedWater.main(Unknown Source)

        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

        at java.lang.reflect.Method.invoke(Method.java:597)

        at jmetest.TestChooser.start(Unknown Source)

        at jmetest.TestChooser.main(Unknown Source)



Are there any things in particular that need to be kept in mind about the new RTT-functionality?

The new RTT functionality uses FBO which may require a driver update to ensure functionality.  That said, it is meant to "drop in" without needing code changes.  It's still new code and likely to have bugs, especially hardware specific ones, so help on weeding those out is always appreciated. 



In case anyone is wondering, readding Pbuffer support as a falllback is something I'd like to see.  There's probably a half dozen other things to do as well.

I tried updating to the most recent NVidia-drivers. but I still have the same problem I'm afraid.



Btw, as I mentioned in my previous post, RTT works, it just does not work in all situations (one of them is TestProjectedWater). This is just a blind guess, but both my own routines, which do not work, and the projected water access the rendered texture from a GLSL-shader. Do the FBO's work properly with the current GLSLShaderObjects?



Has anyone else tried running TestProjectedWater?

it just does not work in all situations (one of them is TestProjectedWater)


this could eventually be another problem i think as i got such gl exceptions
(org.lwjgl.opengl.OpenGLException: Invalid value (1281)
        at org.lwjgl.opengl.Util.checkGLError(Util.java:56)
when using the water examples with jdk 1.6 on linux (dont remember the exact jdk version) but not with jdk 1.5

edit: ah yes and this is on a geforceFX5900XT

Heh, yeah, what do you know. I have the same problem. I'll look into it soon.

Looks like it has something to do with the ProjectedGrid itself.  Switching the effect onto the skyBox or another part of the scene allows it to work ok.

Ah ha! So all the talk about texture errors was just a plot to distract darkfrog… when DO we get the sound stuff? I've got my .wav files all lined up and waiting so my planes can go "vroooooom dakka dakka dakka". But it seems there will be neither vrooming, nor in fact dakkaing :frowning:



Will the sound stuff support many sound nodes simultaneously without special handling? If not I might start looking at OpenAL again, I'm sure I had something going in puzzlebeans that would do lots of samples at the same time, so I can check to see if it does, then 3d-ise it.

The new sound code I wrote uses OpenAL and it of course handles multiple simultaneous sounds.  The reason it didn't go in yet is because permission was not asked for.  The other things that went in yesterday were largely improvements on existing features.  You could argue that the new sound stuff is simply an improvement on the old code (it probably even has a few sections of old code brought over)…  I'm hoping it can get in soon though because I want you all to immediately break my code in thousands of unexpected ways. :slight_smile:



One other thing I'd like to mention about sound is that lwjgl's OpenAL implementation is OpenAL 1.0 based.  As such, there are some things I feel are lacking from the sound system because they are only supported in OpenAL 1.1.  I've been told that 1.1 support is coming sometime, but any spontaneous promptings from other jme members might help that along…

renanse said:

I've been told that 1.1 support is coming sometime, but any spontaneous promptings from other jme members might help that along...
Any spontaneous patches from other jme members might help that along...  :D

Good, good, a nod's as good as a wink to a blind bat! Time to spontaneously hit the lwjgl forums  :roll:



By the way, just in case you were wondering if I was being completely stupid (and slightly insulting :wink: ), I did realise that the sound stuff would handle multiple sounds :slight_smile: I just recalled an earlier discussion of some kind of limit on the number of simultaneous sounds in OpenAL (16 I think) and creating one per sound-emitting node would hence be bad (I anticipate having at least 8 planes, each with two different guns and an engine, so I'm at 24 already). So I was just wondering if I could allocate say 50 sounds, and have them somehow all play, or at least be prioritised based on distance or volume.