@Conzar said:
Do you think there is a performance benefit for calculating the distance between objects verses using a GhostControl + PhysicsListener?
Performing a distance check yourself should far lighter weight then using the physics, and since your pick-up mechanic doesn't require any actual physical interactions, you're better off saving that performance hit to use elsewhere later on. Optimising a custom distance check will also be a breeze, eg rather than check the distance to every object on every tick, you could check them in sequence, one object per tick and slightly increase the trigger proximity (distance required to pick-up).
@thetoucher said:
Performing a distance check yourself should far lighter weight then using the physics, and since your pick-up mechanic doesn't require any actual physical interactions, you're better off saving that performance hit to use elsewhere later on. Optimising a custom distance check will also be a breeze, eg rather than check the distance to every object on every tick, you could check them in sequence, one object per tick and slightly increase the trigger proximity (distance required to pick-up).
Sorry, but the physic may be not lightweight, but it is faster anyway, since the extra load contains several highly optimized algorithms.
You would do a check from any update to the player or similar, or in other words a
O(n) complexity, while the broadphase (DBVT) has a O(log (n)) cost, with much objects the difference is quite visible. (If objects are not moving the actual costs are even a bit lower)
@EmpirePhoenix don’t get me worng, I wasn’t bashing the physics, just suggesting it’s use in thise case, for basic 2d circle collisions between a handful of objects, was not entirely necassary
You do raise a very valid point, in more complex situations the highly optimised nature of the physic engine make it an excellent solution.
I’m having a big problem. So I replaced my video card which was found to be faulty with a new Geforce 560 GTX. I’ve run some benchmarks and the computer system is functioning properly.
In JMP, I can use the scene editor without problems; however, the starting OpenGL window doesn’t show. When I launch our application, its very very choppy even though the FPS is over 3500. Any ideas why this is?
@Conzar said:
I'm having a big problem. So I replaced my video card which was found to be faulty with a new Geforce 560 GTX. I've run some benchmarks and the computer system is functioning properly.
In JMP, I can use the scene editor without problems; however, the starting OpenGL window doesn't show. When I launch our application, its very very choppy even though the FPS is over 3500. Any ideas why this is?
Thanks
Are you running plain beta JMP or one of the more recent stable versions? Beta had a known issue with chopiness... especially at high frame rates.
Edit: though it occurs to me that if that was the problem then FPS would never go above 999.
@Conzar said:
When I launch our application, its very very choppy even though the FPS is over 3500. Any ideas why this is?
I find my jme projects do get choppy at very high frame rates, just try using v-sync. I assume it's just some internal bus that just cant keep up with the volume of frames that are being pushed.
@thetoucher said:
I find my jme projects do get choppy at very high frame rates, just try using v-sync. I assume it's just some internal bus that just cant keep up with the volume of frames that are being pushed.
