Quote from: "raft"and when did you update the site, i must have missed it. it looks nice :wink:

Yesterday... :wink:

About the ID: I thought about that but isn't the result the same? I.e. you can't deserialize old stuff with a changed class. I'm asking because i've never used it. I just serialized all the required instances again after making a change. So where is the actual difference?

Quote from: "Anonymous"The enableGLCanvas method is not present on the java doc!

:?:  :?:  :?: It is. It's called enableGLCanvasRenderer(int) and can be found in the FrameBuffer docs.

I that case, you may either use Camera.getDirection() for this or get the rotation matrix directly from the camera like so:


Matrix pd=w.getCamera().getBack();
pd=pd.invert3x3();


However, i assume that movement should stay parallel to the floor even when looking slightly up or down to the object in question. Then you have to maintain the player's rotation matrix yourself, i'm afraid. That's what the fps example does too.

They are, but for Windows. You have to use native libs for Mac. They can be found here: https://sourceforge.net/project/showfiles.php?group_id=58488
You may either upgrade the whole LJWGL-stuff (including the jars) that comes with jPCT (from 0.97 to 0.98 ) or simply download the 0.97 version for Mac and use the libs in the native-folder instead.

Hope this helps.

I can't verify this. How exactly are you moving the camera, i.e. moveCamera(int mode, float speed) or moveCamera(SimpleVector direction, float speed)?

You have to include the native libs too. Either put them in the current directory (should work...) or use the -Djava.library.path=<your dir>-switch to tell the VM where to look for the native libs.

Ok, i've hopefully found the bug and fixed it. Corrected version should run on your machine. The problem was that i was initializing vertex arrays for non-present texture stages on lower end hardware.

Topic says it all.

Notification should work fine again.

Quote from: "MFJ"I believe JPCT is 1.1 compatible?

For the software renderer path, yes. But OpenGL support requires at least 1.4.

Ok, so only the "normal" GLRenderer seems to have a problem on your machine. I'll check it out on monday. I have a GF4MX somewhere...will try to track the problem down with that. Thanx for testing.

Strange...looks like i'm doing something in the renderer that isn't allowed in that state. Problem is, that this should be the case on every hardware/driver but i can't verify it. It's a damn case of "works for me".

Can you please (if time permits it):

1. Make sure that you have the latest version (i.e. download it again)
2. Try to run the example, press '1' to disable rgb scaling, switch to OpenGL and see if that works
3. Compile the example above and see if that works

Many thanx.

Quote from: "Raven"However, I'm wondering if there is a way to make the light one-directional? I can't find any documentation on that, so I guess not. In that case, is the simplest solution to position the lightsource inside a hollow cylinder object? Or would the light shine through that cylinder?

No, directional lighting is not possible with standard vertex lighting, which is what jPCT is using. There's no way to let other objects block the light either. jPCT is following OpenGL's specs when it comes to lighting.
For a spotlight, it may be possible to fake it by using a transparent object als light cone, but i'm not sure how good that will look...maybe not too good... :wink:

The forum currently has some problems with sending notification mails. The mail header is somehow corrupted and you may see (depending on your client) an encoded text instead of the correct mail.
I'll let you know, when it's fixed...

What do you mean by "awfull"? The software renderer can't do mip mapping let alone trilinear filtering, so you may see some aliasing artifacts. Maybe you don't like the effect the faked bilinear filter creates (disable it with Config.texelFilter). Usualy, software benefits from low contrast textures, because that will reduce the aliasing.