www.jpct.net

jPCT-AE - a 3d engine for Android => Support => Topic started by: Darai on October 21, 2014, 01:25:06 pm

Title: Best practice for "Basic Physics"
Post by: Darai 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
this.theObject.translate(this.speed);
}
}

// And somewhere in the Renderer with FrameBuffer fb
public void onDrawFrame(GL10 gl) {
for(int i =0;i<objects.length;i++){objects[i].move();}
fb.clear(back);
world.renderScene(fb);
world.draw(fb);
fb.display();
try {
Thread.sleep(20);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
Thanks for every hint.
Darai.
Title: Re: Best practice for "Basic Physics"
Post by: EgonOlsen 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...
Title: So before the physics, maybe some remaking
Post by: Darai on October 22, 2014, 09:12:00 am
Hi,

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:
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:
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,
Thanks,

Darai.