Maarten Baert's website

Game Maker / C++ projects
Home Model Creator ExtremePhysics Game Maker DLLs SimpleScreenRecorder AlterPCB Quadcopters   Recent comments Search
Navigation

• Main page • Tutorials • Reference • Polygon Creator • Feature comparison

• Offline version

Log in

No account yet? Register!

Valid HTML 4.01 Transitional

Valid CSS!

Last modified: Fri, 24 May 2013
Refresh

Feature comparison

Many people have asked whether they should use ExtremePhysics or the built-in physics engine in GM:Studio (which is actually Box2D, a popular open-source C++ physics engine). I can't really answer that question for you, but I can compare the two so you can decide which one is better for your project.

Platform support

The main reason to use the built-in physics engine in GM:Studio is that it works on all platforms. ExtremePhysics only works on Windows and Mac, and unfortunately there's nothing I can do about that because Yoyogames hasn't created a (real) extension mechanism for the other platforms.

Performance

I have never done a precise performance comparison between ExtremePhysics and GM:Studio's built-in physics engine. However, I have done comparisons between ExtremePhysics and Box2D in C++, completely separate from GM. The performance when used in GM may be different.

Image: ep-box2d-performance-screenshot-small.png

Test in progress. The blue boxes are simulated by ExtremePhysics, the brown boxes by Box2D.

Image: ep-box2d-performance-box.png

Image: ep-box2d-performance-circle.png

Image: ep-box2d-performance-poly.png

Relative performance of ExtremePhysics vs. Box2D for box shapes, circle shapes and polygon shapes. The horizonal axis show the number of shapes. The vertical axis shows the relative performance. A value of 1 means that ExtremePhysics and Box2D are equally fast. A value higher than 1 means that Box2D is faster, and a value lower than 1 means that ExtremePhysics is faster.

As you can see from the graphs, there's very little difference. ExtremePhysics seems to be a bit faster when there are less than 500-1000 shapes, after that Box2D is faster. Except for polygons (pentagons, in my test), for some reason ExtremePhysics performed better there. Overall, the difference is probably too small to be relevant, considering how much time is lost due to inefficiencies in GM. It is very unlikely that you will be able to simulate 2000 bodies in GM at a decent frame rate, like I did in C++.

This result is no surprise since ExtremePhysics and Box2D use the same underlying mathematics. The implementation is different, but similar. The biggest difference between ExtremePhysics and Box2D is probably the broad-phase collision detection algorithm. Box2D uses an algorithm called sweep and prune (SAP), whereas ExtremePhysics uses a variant called 'radix sweep and prune'. The key difference is that SAP is faster when there is very little movement, but extremely slow when there is a lot of fast movement. I never did performance comparisons between the two algorithms directly, but others have. This is what you get when you put the numbers from that website on a graph:

Image: radix-sap-performance.png

Note that this test was done in 3D, not 2D, and that the test results are very old. But you get the idea: SAP is most useful when there's little movement. Radix SAP always takes the same amount of time and is also simpler, so that's why I picked that algorithm instead.

Features

The goal of this table is to compare the feature set in GM:Studio's Box2D and ExtremePhysics. The list does not include features that are found in the upstream Box2D but not in GM:Studio nor ExtremePhysics. It also doesn't contain unofficial extensions to Box2D. Upstream Box2D has many more features that are not in this list.

Overall, Box2D has more features than ExtremePhysics, especially when combined with the unofficial extensions. However, the version in GM Studio doesn't expose most of them, which means you actually have less features compared to ExtremePhysics. Most of these features are relatively advanced though, so it is very well possible that you don't need them. It really depends on the type of game you're trying to create.

(Worlds)

Upstream Box2D

GM:Studio Box2D

ExtremePhysics

Notes

Multiple worlds

Image: state_yes.png

Image: state_no.png

Image: state_yes.png

Separate position/velocity iterations

Image: state_yes.png

Image: state_no.png

Image: state_yes.png

Serialize/unserialize (save/load, undo/redo)

Image: state_no.png

Image: state_no.png

Image: state_yes.png

Added to EP because it was a requirement for my game The Machine.

Advanced world settings

Image: state_yes.png

Image: state_no.png

Image: state_yes.png

Advanced sleeping settings

Image: state_yes.png

Image: state_no.png

Image: state_yes.png

Sleep by view

Image: state_no.png

Image: state_no.png

Image: state_yes.png

Substeps

Image: state_yes.png

Image: state_partial.png

Image: state_yes.png

GM:Studio doesn't allow any actions between substeps, which is required in some cases.

Collision tests

Image: state_yes.png

Image: state_partial.png

Image: state_yes.png

GM:Studio doesn't tell WHICH body/bodies caused the collision.

(Bodies)

Upstream Box2D

GM:Studio Box2D

ExtremePhysics

Notes

Per-body gravity

Image: state_no.png

Image: state_no.png

Image: state_yes.png

This can be emulated with forces instead.

Bodies separate from objects

n/a

Image: state_no.png

Image: state_yes.png

Whether this is good or bad is a matter of opinion. I prefer the flexibility of 'user variables' in EP.

Change sleeping settings

Image: state_yes.png

Image: state_no.png

Image: state_yes.png

Time of impact collision detection ('bullet' bodies)

Image: state_yes.png

Image: state_yes.png

Image: state_no.png

I prefer raycasting for bullets since it's more reliable and a LOT faster.

(Shapes)

Upstream Box2D

GM:Studio Box2D

ExtremePhysics

Notes

Shapes without bodies

Image: state_yes.png

Image: state_partial.png

Image: state_no.png

Supported in GM:Studio but useless because most functionality is missing.

Collision detection without bodies

Image: state_yes.png

Image: state_no.png

Image: state_yes.png

Collision detection in GM:Studio is only possible if the body already exists in a different place.

Sensors

Image: state_yes.png

Image: state_yes.png

Image: state_no.png

In many cases this can replace collision detection without bodies.

Advanced collision filtering (collision masks)

Image: state_yes.png

Image: state_no.png

Image: state_yes.png

GM:Studio hides this from the user to make things simpler, but loses some of the flexibility as a result.

Point and line shapes

Image: state_yes.png

Image: state_no.png

Image: state_yes.png

Normal and tangent velocity (conveyor belts and jump pads)

Image: state_no.png

Image: state_no.png

Image: state_yes.png

I can find some references to this idea on the Box2D forums, but no official implementation.

(Contacts)

Upstream Box2D

GM:Studio Box2D

ExtremePhysics

Notes

Iterate over contacts (advanced collision detection)

Image: state_yes.png

Image: state_no.png

Image: state_yes.png

Disable contacts (e.g. one-way platforms)

Image: state_yes.png

Image: state_no.png

Image: state_yes.png

In EP, this is done by deleting the contact between ep_world_update_contacts and ep_world_simulate_step.

Read back forces

Image: state_yes.png

Image: state_no.png

Image: state_yes.png

Disable contacts by joint

Image: state_yes.png

Image: state_yes.png

Image: state_no.png

Intentionally not supported in EP because it affects performance. Groups are faster and good enough IMO.

(Hinge joints)

Upstream Box2D

GM:Studio Box2D

ExtremePhysics

Notes

Hinge/revolute joint

Image: state_yes.png

Image: state_yes.png

Image: state_yes.png

Hinge joint limits

Image: state_yes.png

Image: state_yes.png

Image: state_yes.png

Hinge joint limit force

Image: state_yes.png

Image: state_no.png

Image: state_yes.png

Hinge joint springs

Image: state_no.png

Image: state_no.png

Image: state_yes.png

Hinge joint motors

Image: state_yes.png

Image: state_yes.png

Image: state_yes.png

(Distance joints)

Upstream Box2D

GM:Studio Box2D

ExtremePhysics

Notes

Distance joint

Image: state_yes.png

Image: state_yes.png

Image: state_yes.png

Distance joint limits (ropes)

Image: state_partial.png

Image: state_no.png

Image: state_yes.png

Upstream Box2D has ropes (upper limit) but not the opposite (lower limit).

Distance joint limit force

Image: state_no.png

Image: state_no.png

Image: state_yes.png

Distance joint springs

Image: state_partial.png

Image: state_no.png

Image: state_yes.png

Upstream Box2D has springs, but no separate lower and upper spring.

Distance joint motors

Image: state_no.png

Image: state_no.png

Image: state_yes.png

(Slider joints)

Upstream Box2D

GM:Studio Box2D

ExtremePhysics

Notes

Slider/prismatic joint

Image: state_yes.png

Image: state_yes.png

Image: state_yes.png

Slider joint limits

Image: state_yes.png

Image: state_yes.png

Image: state_yes.png

Slider joint limit force

Image: state_yes.png

Image: state_no.png

Image: state_yes.png

Slider joint springs

Image: state_no.png

Image: state_no.png

Image: state_yes.png

Slider joint motors

Image: state_yes.png

Image: state_yes.png

Image: state_yes.png

(Other joints)

Upstream Box2D

GM:Studio Box2D

ExtremePhysics

Notes

Pulley joint

Image: state_yes.png

Image: state_yes.png

Image: state_no.png

Gear joint

Image: state_yes.png

Image: state_yes.png

Image: state_no.png

Rail joint

Image: state_no.png

Image: state_no.png

Image: state_yes.png

Box2D recommends a slider joint combined with a hinge joint with a dummy body in between, but this is less efficient and less stable.

(Miscellaneous)

Upstream Box2D

GM:Studio Box2D

ExtremePhysics

Notes

Iterate over all internal structures

Image: state_yes.png

Image: state_no.png

Image: state_yes.png

Raycasting

Image: state_yes.png

Image: state_no.png

Image: state_yes.png

Sleep by view

Image: state_no.png

Image: state_no.png

Image: state_yes.png

Convex decomposition (multipolygons)

Image: state_partial.png

Image: state_no.png

Image: state_yes.png

Code exists as extensions, but not part of the official Box2D.

Water

Image: state_partial.png

Image: state_no.png

Image: state_yes.png

Extensions for Box2D exist, but not part of the official Box2D AFAIK.

Coordinate and vector conversions

Image: state_yes.png

Image: state_no.png

Image: state_yes.png

Not hard to implement in GML though, just slower.

Note: I am pretty sure the feature list for ExtremePhysics is accurate, but I have less experience with Box2D and no experience with GM Studio. The table above is based on what I could find in the documentation. Please leave a comment if you find any mistakes.

Other GM physics engines

There have been other physics engines for Game Maker, but as far as I know none of them are still maintained, and none of them ever had features comparable to Box2D or ExtremePhysics. I have done some comparisons in the past, so I will upload them in case anyone cares. There tests were done almost three years ago, with an older version of ExtremePhysics.

I tested four physics engines:

  • ExtremePhysics

  • GMODE: Based on ODE, an open-source 3D physics engine, but restricted to 2D in this GM extension. Since this is actually a 3D engine, it is less efficient and far less stable than the other engines in this test.

  • PhysX: This is actually a Box2D port (and in no way related to NVIDIA's PhysX). I suspect the creator forgot to turn off debugging support though, since it is significantly slower than it should have been.

  • GMPhysics: This was probably the first serious GM physics engine, and it used to be very popular. However, there were some compatibility problems with GM7 and later which caused very frequent crashes, making it pretty much unusable. GMPhysics has been unmaintained for many years (technically it's still in beta), and since it's closed-source, there's no way to fix the issues. I had to restart my test a few times because of crashes caused by GMPhysics.

Image: physics-engine-comparison-boxes.png

Image: physics-engine-comparison-circles.png

Test results for boxes and circles respectively. The horizontal axis shows the number of shapes. The vertical axis is the processing time in microseconds.

If you want to run the test yourself, you can download it here. The test was done with Game Maker 7 and I have no idea whether it will still work with newer versions.

Comments

Fil

Comment #1: Thu, 21 Oct 2021, 0:30 (GMT+1, DST)

Quote

Hello Maarten, I have a bit of an odd comment for you. Regarding your chain fountain demonstration video I am curious if the simulation includes any fluid dynamics simulation. I find the chain fountain phenomenon curious and wonder if the medium through which it's moving plays any role in the phenomenon. I asked on a physics forum and one member suggested I put the question to you as you have simulated the effect.

Here is the link to the forum in which your video came up:

https://www.physicsforums.com/threads/a-request-regarding-newtons-beads-chain-fountain-phenomenon.1008119/#post-6554927
Maarten Baert

Administrator

Comment #2: Fri, 12 Nov 2021, 20:56 (GMT+1, DST)

Quote

Quote: Fil

Hello Maarten, I have a bit of an odd comment for you. Regarding your chain fountain demonstration video I am curious if the simulation includes any fluid dynamics simulation. I find the chain fountain phenomenon curious and wonder if the medium through which it's moving plays any role in the phenomenon. I asked on a physics forum and one member suggested I put the question to you as you have simulated the effect.

Here is the link to the forum in which your video came up:

https://www.physicsforums.com/threads/a-request-regarding-newtons-beads-chain-fountain-phenomenon.1008119/#post-6554927

I am not including any aerodynamic effects in my simulation, it is purely a rigid body simulation.

Write a comment

Copyright 2009-2024 Maarten Baert