Quote from: WilliamLie2 on July 08, 2014, 06:27:54 PM

Quote from: HunterMinerCrafter on July 08, 2014, 05:14:16 PM

If anyone knows of any reason why these patches should not be deployed, speak now or forever hold your peace!

Yes, is there are anyone who is against these patches?

Quote from: HunterMinerCrafter on July 08, 2014, 05:46:47 PM

Quote from: kuchitsu on July 08, 2014, 05:26:14 PM

Quote from: HunterMinerCrafter on July 05, 2014, 04:36:31 PM

improving the game physics

pls make them like in elastomania:D

Elastomania proper is closed source and uses a proprietary physics engine. This would make it difficult to replicate those physics. There is the open source XMoto clone which we could draw from.

I think the biggest "low hanging fruit" limiting factor in realism of the physics right now is probably the rotation time constraint. I don't think reducing this constraint would be problematic.

There are several differences between Elma and Motogame physics:

Are you a developer on Elastomania as well, or is there some existing reverse of the physics engine? If so, could you point me to it?

Quote

1. Head position calculation. In Motogame it is computed in almost the same way as wheel positions while in Elma it is more complicated.

I assume it is more similar to XMoto, where the body is segmented, and not just a set of spring forces, yes?

Quote

2. Brake. I think this is caused by the way collision between wheels and ground is computed. It uses linear approximation of perlin noise in wheel position and that causes some artifacts. Or maybe I just screwed up somewhere.

I've noticed that when breaking on ground the bike will often tend to "slide" much more than it seems that it should.

Quote

3. Rotation. Elma has some strange logic for rotation that is a little bit different from Moogame but I think this is almost unnoticeable.

I think the simple force addition that moto does is fine. Obviously the most noticeable thing is the rotation time limit being a little short. Do you anticipate any problems if we simply reduce this time constraint?

Quote

4. Wheel rotation doesn't affect whole bike rotation. There were some problems in converting it from floating point to fixed precisions so I just removed it.

In general, I think there is a bit of loss in the move to integer physics. There are various approaches to precise real precision arithmetic without floating point portability woes. Should we consider moving to that sort of a solution?

Quote

5. Time speed. Default time speed is probably different in Motogame.

I think at 250 fps resolution the motogame physics are likely much more finely calculated than in most games!