About Stuntcar Racer...i just discovered this one. Have a look:

http://www.flipcode.com/cgi-bin/msg.cgi?showThread=02-10-2003&forum=iotd&id=-1

Yes...it's looking fine now. Is there a way to show the framerate or am i just blind?

A question though... I would like my landscape to be sun-lit (i.e from a distance and static) what would be the way to do this?

I can imagine three different solutions to this problem:
1.) Code the lighting information into the texture. This may produce nice results in some cases, but to be honest i doubt that will in your case.
2.) Use the normal lighting jPCT offers. Place the "sun" in the distance and play with the lightMul, linearDiv and fadeOutLight parameters in Config. Maybe it's possible to produce the desired effect this way.
3.) (and this is NOT possible at the moment but something i'm still thinking about)...use a kind of simple VertexShader-Interface to implement some things on a vertex-level for yourself. Problem with this is, that i have to find a logical, convenient and fast way of doing this and that isn't that easy. Anyway, it won't help you much hear me talking about features that may come in the future...

So i suggest to go with the dynamic lighting jPCT offers. If it really doesn't work, please let me know where the problem is...maybe i can do something about it.

Also how is texture repeating set so it isn't streched over the whole landscape?

That's not possible, because that would hurt the software-renderers performance too much. If you really need it, do the modulo-calculation by yourself on the texture-coords (before calling addTriangle()). But that will require that you build the object by yourself (i.e. not using one of the loaders in Loader). IF the vertex-shader-stuff mentioned above would be in jPCT, it should be possible to do such things in a more convenient way...IF.... :wink:

BTW: I loved stuntcar racer. It was a great game to be played via a (null-)modem connection.

I don't know, because i don't know this program nor do i know what it does exactly. I don't see a problem in byte-code obfuscation alone, but maybe when classes are being renamed!? I'm not sure how an obfuscator handles dynamic class-loading. I have to do this for the FrameBuffer and the Renderers, which are only loaded on demand. If the obfuscator can somehow handle this: fine! If it doesn't, than at least changing class names won't work.

I've made some textures from photos that i've taken at the abandoned EXPO-2000 ground in Hannover/Germany. The textures are seamless and can be used in any way you like. Because this is my first real try to make textures, i'm not sure if they are good or bad...but at least they are free...

http://www.jpct.net/download/texturepack1.zip

Code for picking will look like this:


SimpleVector td=Interact2D.reproject2D3D(camera, framebuffer, mouseX, mouseY);
int[] res = Interact2D.pickPolygon(theWorld.getVisibilityList(),td);

Well, have a look at the Bounce-example and replace


if (zoomin) {theWorld.getCamera().moveCamera(Camera.CAMERA_MOVEIN, zoomSpeed);}
if (zoomout) {theWorld.getCamera().moveCamera(Camera.CAMERA_MOVEOUT, zoomSpeed);}
if (shiftleft) {theWorld.getCamera().moveCamera(Camera.CAMERA_MOVELEFT, zoomSpeed);}
if (shiftright) {theWorld.getCamera().moveCamera(Camera.CAMERA_MOVERIGHT, zoomSpeed);}
if (shiftdown) {theWorld.getCamera().moveCamera(Camera.CAMERA_MOVEDOWN, zoomSpeed);}
if (shiftup) {theWorld.getCamera().moveCamera(Camera.CAMERA_MOVEUP, zoomSpeed);}


with this:


if (zoomin) {theWorld.checkCameraCollision(Camera.CAMERA_MOVEIN, zoomSpeed, Camera.DONT_SLIDE);}
if (zoomout) {theWorld.checkCameraCollision(Camera.CAMERA_MOVEOUT, zoomSpeed, Camera.DONT_SLIDE);}
if (shiftleft) {theWorld.checkCameraCollision(Camera.CAMERA_MOVELEFT, zoomSpeed, Camera.DONT_SLIDE);}
if (shiftright) {theWorld.checkCameraCollision(Camera.CAMERA_MOVERIGHT, zoomSpeed, Camera.DONT_SLIDE);}
if (shiftdown) {theWorld.checkCameraCollision(Camera.CAMERA_MOVEDOWN, zoomSpeed, Camera.DONT_SLIDE);}
if (shiftup) {theWorld.checkCameraCollision(Camera.CAMERA_MOVEUP, zoomSpeed, Camera.DONT_SLIDE);}


and remove the


cube.rotateZ(0.005f);


some lines above (to prevent the cube from spinning). This should show the basic usage of the camera collision (you can navigate using the num-pad in this example btw). The Camera.SLIDE option doesn't really work as it should...i'll have to fix this in a later version, but anyway...

I hope this helps. If it doesn't, feel free to ask again. Keep in mind that jPCT uses a ray/triangle-collision scheme for camera-collisions.
Depending on the scale of your world, you may have to adjust Config.collideOffset accordingly, but for Bounce, it should work fine the way it is.