Author Topic: Best practice for "Basic Physics"  (Read 1421 times)

Offline Darai

  • byte
  • *
  • Posts: 45
    • View Profile
Best practice for "Basic Physics"
« on: October 21, 2014, 01:25:06 pm »
Hi guys,

Imagine, you have some 50+ objects in JPCT world. You have the renderer, taking care for the onDrawFrame() method and some onTouchEvent() method switching on and off the switches according the user demands.

Now, every turn each object does something - let's say it moves by predefined vector. This is a very simple type of physics, where the objects have no interaction, but they have some behavior.

Up until now, when i wanted to do something like that, I used a temporary solution. A for cycle in the onDrawFrame() method to cycle through each object.

I expect that there is a better solution, like threadding or using Android Services or there is some onDraw listener for the Object3D simillar to onCollision listener or if I have to implement a real physics, like Bullet even for a simple example like this one... but I don't know which is the best one to use.

To demonstrate it in example:
Lets say I have this:

Code: [Select]
public ExtendedObject[] objects;

public class ExtendedObject{
public Object3D theObject;
public SimpleVector speed;
public void move(){
// Do something

// And somewhere in the Renderer with FrameBuffer fb
public void onDrawFrame(GL10 gl) {
for(int i =0;i<objects.length;i++){objects[i].move();}
try {
} catch (InterruptedException e) {
Thanks for every hint.

Offline EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 12256
    • View Profile
Re: Best practice for "Basic Physics"
« Reply #1 on: October 21, 2014, 10:02:12 pm »
Personally, i'm doing almost exactly that with the slight difference that my game logic depends on ticks (one ticks is some fraction of a second, like 1/50). I measure the ticks passed since the last call to the game logic and if it's larger 0, i execute the logic (based on the tick count of course) similar to what you do (just wrapped in some controller like classes and such). That gives you a time independent and deterministic game logic.
I would avoid threading here. It might help if you doing really complicates calculations on a large number of objects, but as long as this isn't the case, the additional overhead will eat up the gains. Apart from that, it can become troublesome to debug and eats more battery.
I wouldn't use any kind of listener for this. It's basically the same thing but with additional overhead. You can of course implement it yourself, but what else would you do but iterate over the  listener implementations instead of the objects directly. I do use listeners of that kind from some things in my rpg game but not for this kind of basic game logic.
However, this is just opinion on these topics. I'm sure that are many others out there...

Offline Darai

  • byte
  • *
  • Posts: 45
    • View Profile
So before the physics, maybe some remaking
« Reply #2 on: October 22, 2014, 09:12:00 am »

Thanks for the reply. I spend the last day going through your code and I was suprised that I really saw this simple linear approach there... actually I did some more precise calculations and the scale is as follows:
  • 200-300 objects, which I move and check if they are "out of the bounding box"
  • 50 objects which move, and check for collision
  • 100 objects which rotate, move, check for outOfBoundary and for collision and
  • 100 sleeping objects for some animation gadgets.
The game is having difficulty to hold the tick rate, that is why I am thinking about better than linear approach, but from what you said, maybe I can first think about improving some other gadgets, like:
  • Limit the tick rate of the onTouchEvent() method, because every time this runs, it drains some resources identifying where the touch on the screen was.
  • Remake the onTouchEvent() method, to move most of the math (Recalculation from 2D to 3D, switching on GUI, etc) to the onTick()
  • Remake all the methods in onTick to be on Lists not ArrayLists (most of them are, but not all)
  • Think more about the method which is doing the tick balance (I am also using some tick calculation, not fixed time)
Right now I focused on limiting the garbage collector, but I think I can still quite upgrade some of the calculations I am doing there.
Well, that is all for start.

I will report what I achieved with this ideas,