Platform : Physic representation & Real Time

Today, I'm going to speak about the physic representation I chose to model movements in the 2D world, and which I spoke with John last meeting, and, following this, issues I met and choices I made about "Real Time" implementation.


Physic representation

On the platform, each element (including World elements like balls and robots) has different parameters to model its evolution in the world :

• Position : Two coordinates to place the element in the world.
• Direction angle : When moving, the element itself knows in which direction it is going to move. So, you only have to change this parameter to turn aside an element.
• Direction : An element not necessarily move forward. Currently, "1" is the default value for forward and "-1" the one for backward. But using this, you could model for example crab robots which would move on the side.
• Speed : Based on reality, this parameter enables movements when different from 0. ( I"ll explain after how it does works ).
• Rotation Speed : Similar to the speed, this parameter is for rotation of elements. Mainly used by robots, this could be used by spinning top or balls.
• Acceleration : For the moment, speed is enough to model constant speed movements. However, acceleration may be used later to vary speed automatically.

Using this, the ElementManager class refreshes the world regularly by using a Timer, with a specified value of refreshTime.
Each time, the system calls the updatePosition() method for each element.
This method checks the speed of the element, and, if it's not 0, moves it from its position to another calculated using a simple formula with direction, speed, and direction angle (combined with trigonometric functions). ( It works even more simple with rotationSpeed. )


So, commands like Move or Rotate only act on those speeds, this is actually the element which moves itself.

More explainations will be given it the following part.

Real Time

The code here is a bit more complex than the other parts, that's why I would like to develop it.

First solution - Issue

As I said before, the software refreshes regularly the world, using a specified interval. The first solution, suggested by some pool software, is to simply divide a movement by the number of intervals needed, to have a movement in real time.
However, this method involves approximations.
Let's suppose the refresh time is 1 second, and let's add an element which covers 5 meters in 6 seconds.
The movement will be divided into 6 parts, as the figure shows.

In this case, this would be correct using floats, but if you use non integer refreshTime, added to approximations using cosinus/sinus, and more complex divisons, this creates a lot of imperfection :
So, while testing, a slow rotation of 10° led to an actual rotation of 9°.

For the platform, which requires precise movements, this wasn't good, that's why I used a more complex solution.

Second solution 


Instead of dividing the movement, the choice I made was to recalculate the whole movement each refreshTime :

On the last example, this leads, at least, to the exact position.

So, to model this, elements have to know a few values: the distance they have to cover, but also the total number of updates needed (6 here), and the current update.
Moreover, the elements must stock their initial position to recalculate it each time.
Here are the new parameters :

• distanceToCover
• updatesMoveRequired
• currentMoveUpdate

• TmpPosition : Initial value, updated when the movement ends or is diverted.

Another version of these parameters is needed for rotation.

Can't we calculate these values apart from Element class ?
I searched a more simple way to code this. However, with this representation, the system only calls updateElement() method each refresh time without any parameters, so this is impossible to specify each time a value for each element.


-----
I'm stopping here for today. The collision part I'm working on will probably need some explanations as well.