I have just joined JavaGaming.org, so I'll briefly introduce myself. My name is Grzegorz Holdys. I run a small company called Insight Machines, that creates simulation games mainly for education and training purposes. Some time ago I started developing a physics engine for 3D car games. The engine is not complete, but in my opinion it works well enough to show it to the World :-). You can find the demo here. It requires Java 6.0 to work. Please take a look at it a tell me what you think. I have tested the demo on three different machines running Windows XP, Linux and Windows Vista, so it should work, but if it doesn't please let me know.

However the FPS is alot lower than I would like at 21FPS on Intel Q6600, Geforce 8800GTS, WindowsXP. You seem to be using JOGL so is it the physics slowing it down?

Can you check your CPU usage? The demo does not use continues rendering - it uses a special Animator thing from JOGL to keep FPS at around 25. On Linux, this is 25, but on WindowsXP it's a little less (thanks to the precision of the system timer on Windows)

It seems to run at below 2% CPU when driving around and about 6% when I push a cylinder around by driving into it continuously. I managed to get it to 11% when trying to hit all 4 cylinders at the same time.

I have increased the target FPS to 30, so it should run a little smoother now. I can't increase it much more, because I won't be able to play - I have a 2.1GHz AthlonX2 CPU and an integrated GeForce 6150.

FPSAnimatuor usually does not produce smooth framerates try to switch to the normal Animator and enable vsynch (gl.setSwapInterval(1)). This should produce much better results on most systems (except old intel cards).

FPSAnimatuor usually does not produce smooth framerates try to switch to the normal Animator and enable vsynch (gl.setSwapInterval(1)). This should produce much better results on most systems (except old intel cards).

Ok, that was very nice. Thats one of the best demos I've seen so far. I am very impressed. I've been working with Visual Basic, DarkBasic, Blitz3d and recently went to Java due to deployment issues. I have looked at alot demos and purchased a few physics engines and I will say that this worked a heck of alot smoother that the engines I purchased. Thank you for the view.

Ok, that was very nice. Thats one of the best demos I've seen so far. I am very impressed. I've been working with Visual Basic, DarkBasic, Blitz3d and recently went to Java due to deployment issues. I have looked at alot demos and purchased a few physics engines and I will say that this worked a heck of alot smoother that the engines I purchased. Thank you for the view.

Well done.

Well then. Next time, you will consider buying a physics engine for a Java game, leave me a note

Excellent!!! It works fine under Linux. I like this demo very much. You have made a very good job. I think I will quote your demo But why is the frame rate so low on my machine? Only 11 FPS. It is not very important as it is quite playable. I'm under Mandriva Linux 2007, AMD Sempron 2600+, ATI Radeon 9250 Pro, open source driver. Other 3D Java games using JOGL rarely get a frame rate lower than 20 FPS on my machine. What do you use for your physics engine?

Excellent!!! It works fine under Linux. I like this demo very much. You have made a very good job. I think I will quote your demo But why is the frame rate so low on my machine? Only 11 FPS. It is not very important as it is quite playable. I'm under Mandriva Linux 2007, AMD Sempron 2600+, ATI Radeon 9250 Pro, open source driver. Other 3D Java games using JOGL rarely get a frame rate lower than 20 FPS on my machine. What do you use for your physics engine?

I have written the physics engine myself basing on the Marco Monster's tutorial of vehicle dynamics. I've also used some equations from "Physics for game developers" by David M. Bourg.I'm a little disappointed that you get only 11 FPS. Can you check your CPU usage?

I have written the physics engine myself basing on the Marco Monster's tutorial of vehicle dynamics. I've also used some equations from "Physics for game developers" by David M. Bourg.I'm a little disappointed that you get only 11 FPS. Can you check your CPU usage?

You use almost 100% of my CPU. Do you use VBO? How do you draw your car? Do you use NURBS?

You use almost 100% of my CPU. Do you use VBO? How do you draw your car? Do you use NURBS?

I use the good old display lists, no VBO. The reason why rendering takes so much time, is that the car model is quite detailed. Too detailed for this kind of demo, but that was the only model I could use.Nevertheless I have found a small bug that has quite significantly increased the CPU load during rendering. I have removed it, so the demo should work a little faster now.

It's still on 21FPS for me on WindowsXP. I think im playing the latest version as the shape of the grey block has changed.

It's a shame that the FPS is locked to the same on every computer regardless of it's power. There has to be a way of letting the engine work out what is acceptable in terms of balancing physics and rendering.

Just out of interest, is the rendering's FPS independant of the physics' FPS?

works fine here, nice physics. I got ~16 fps on my intel E8400 with integrated graphic card. It seems you are performing some really accurate shadow mapping here, it might be the reasonthat i got such low frame rate.

1. I have recompiled the code to work with JRE 1.5 using JDK 1.5. Simply changing "target" to 1.5 is not enough. This does not check for API compatibility, but only marks the code as compatible with Java 1.5

2. I have removed the FPS limit, so it should run smoother on Windows.

3. I have included a simple profiler type of thing. When you run the demo with the console open and press ESC to restart, you will see a printout in the console similar to the one below. This is an analysis of an average simulation time step, that tells you how much time was required to complete each phase of a time step. There are four phases: physics, shapes, shadows and overlay. There is also an entry for the whole time step. The "Potential FPS" value means, that if some phase were processed alone (without other phases) it should reach such a frame-rate.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org