1138 replies to this topic

[Maarten Baert]

ExtremePhysics is a 2D physics simulation engine designed for Game Maker. It allows you to use complex physics in your games without having to worry about the math involved.

ExtremePhysics is written in C++, which is a lot faster than GML. You can easily add hundreds of objects that collide with each other to your game without slowing it down.

Screenshots:

1600 bodies at 40fps on my computer: Intel Core2 Duo 2.5Ghz - using only one core. Without drawing it's even faster (85-90 fps).


Fluid simulation example


Another example

Youtube: ExtremePhysics Fluid Simulation with 40.000 particles

Documentation and tutorials:
http://www.maartenba...extremephysics/

Download:
Download ExtremePhysics 2.2 release 15 (with source code)
Download executable examples

Download ExtremePhysics 2.1 release 14 (with source code)
Download ExtremePhysics 2.0 release 6 (with source code)

Thanks to SapperEngineer there's also a Mac version. His topic is here. The Mac version should be almost identical to the Windows version, however this zip file only contains the GEX and the fluid simulation example. If you want more examples, you can copy the GMKs from the Windows version.

I've also made a Python version as a proof of concept, more info is on my website.

License

ExtremePhysics is distributed under the terms of the GNU Lesser General Public License.

Polygon generator
GamerXP has made a program that generates code for ExtremePhysics polygons. You can use it to draw polygons for your sprites. You can download it here:
http://sprites.3dn.r...ygonCreator.rar

Edited by Maarten Baert, 24 February 2013 - 12:58 AM.

[13bgarli]

This is really good i like it i get about the same as you do with the 1003 objects, with a core i7 920 tho lol
I like this its cool lol and it works on Vista/Windows 7

[fluffalafagaus@gmail.com]

Awsome

[icuurd12b42]

Good, now we can talk about this right here
From other thread

Version 1.0 doesn't draw anything in the DLL. Version 2.0 does, but only for debugging. When using the extension (instead of the scripts), drawing objects in GM instead of in the DLL won't make a huge difference. The scripts and external_call function calls are slow, not GM's drawing functions. I am using the scripts instead of the extension in 2.0 for now, because it makes testing the DLL a lot easier.

shouldnt that be

if(obj1.group & obj2.group) && (obj1.collide || obj2.collide){

No, group and collide are both 32-bit unsigned integers:
- 'group' defines the group(s) the component belongs to (for example, 0101 (binary) means "this component belongs to group 1<<0 and 1<<2")
- 'collide' defines the group(s) the component should collide with (for example, 0011 (binary) means "this component collides with components of group 1<<0 and 1<<1")

Oh I see the variable name confused me. And I get the bit method for grouping, that's what gmbullet does.

Actually, drawing from GML, you have to ask for the position and rotation of the instance via your get variable, I assume... That seriously limits the number of instances. In 2d, that's just x,y,image_abgle. but in 3d that's x,y,z,rx,ry,rz. Looks at the gmbullet topic. In short, calling APIs in gml is very slow. SO calling 3 apis for each instance reduces the number of possible instances drastically. Since you are drawing from the dll, you dont see that hapening right now (Using gmapi I assume)

In gmbullet, various methods have been tried...

The fastest that still involves GML is me passing you a ds_list which you fill up with
instance id
x
y
image_angle (in degrees because the extra rad to deg is also costly)

I can then ask for the positions in one sigle call

var thelist; thelist = ds_list_create();
getinstancesdata(thelist); //your dll api does the ds_list_add, you can exclude deactivated bodies
var i; i = 0;
var sz; sz = ds_list_size(thelist)/4;
repeat(sz)
{
with(ds_list_find_value(thelist,i))
{
x =ds_list_find_value(thelist,i+1)
y =ds_list_find_value(thelist,i+2)
image_angle =ds_list_find_value(thelist,i+4)
}
i+=4;
}
ds_list_destroy(thelist)

asking for ds_ elements is faster than calling api functions.

But the fastest way is you drawing for me. it looks like you are already setup to take over the drawing. I suggest you do that if possible. all you need is the sprite index of the instance and possibly how to draw it (image_blend, scales and blend mode)

Useful functions to add
associatebody(bodyid,instanceid)
if you can draw for me, meaning a hell of a lot of instances can have physics not impeded with me having to ask, in gml, for the position of the instance
setbodydrawinfo(bodyid,spriteindex,imageindex,imag
e_blend,image_xscale,image_yscale,image_alpha,blen
d
_mode)

which you can use in the dll via gmapi, to call draw_sprite_ext for each intances associated with a body
drawForMe() in the draw event.
I guaranty, this will beat the crap out of GMPhysics for the number of object you can handle.

Edited by icuurd12b42, 21 September 2009 - 12:09 AM.

[Maarten Baert]

I have thought about that problem but I couldn't find a good solution. I am using gmlib, and as far as I know there is no fast way to change the value of local variables. If it was possible, I could add something like this:

ep_object_set_localvars(global.world,object,id,"x","y","image_angle")

This would tell the DLL to write the new position to id.x, id.y and id.z. But I don't think this is possible.

The ds_list method is probably faster when using scripts, but I am not so sure if it will still be faster when using the extension. The downside is the code will waste a lot of time updating objects the player can't see anyway. Also I don't want to make the DLL dependent on gmlib because I am not sure it will be possible to use the same hack in GM8 (the runner was converted to C++). But I will test this method to see if it makes the dll faster.

I don't want to add the drawing code to the DLL because it will make drawing very limited. And I don't want to add 100 functions just to get reasonable drawing and a small performance boost. If this is still not fast enough, you should use the physics engine in C++ directly instead of using GM (it will be open source).

[icuurd12b42]

...

GM8 being the same core system as 6 and 7 (no it's not c++ yet), I'm pretty sure it wont take long for gmlib to have the gm8 interface defined.

Not sure about APIs being faster when using extentions. You can do the benchmark yourself or talk with andbna. But I'm pretty sure ds list is faster, extention or not. You can alway pass the view coords and size to the function so it does not populate the list with things out of view... That is if the user really wants to disable movement out of the view. Great idea, the view system BTW...

You can also play with script_execute... Initialising the system you can pass a script index you can then call from the dll (via script_execute(scriptindex,args)) and pass intanceid,x,y,image_angle. I tried it myself but not on a system that I could compare with multiple getxy API calls... In a private version of gm3dpartsys to do owner draw of particles if you ever want to draw the particle in a way not definable by the system...

script updateobjects (assumes you call associatebody and pass this script index to the dll)
//argument0 is id
//argument1 is x
//argument2 is y
//argument3 is image_angle

with(argument0)
{
x = argument1;
y = argument2;
image_angle = argument3;
}


BTW, drawing yourself is not a small performance boost... I can have 10 to 30 times the number of particles drawing in gm3dpartsys vs GML

Yep, being open source, I can see myself adding the features I want though so you dont have to take these suggestion on. Just be sure your class or struct allows adding user data easily (such as extra info to store instance id and sprites and such).

[Maarten Baert]

No problem, I am using normal C++ classes for the entire engine, the functions in GM are actually just wrapper functions. You could even rewrite all wrapper functions yourself if you want.

The callback-script method sounds interesting, I will try that too.

Do you know if a ds_map is slower/faster than a ds_list? I could use maps for all variables and use the (EP) id of the object as the key.

[MrOpposite]

I used the old version on the .nl forum... do you have a change-log of anything new? it would be fun to know

[Sindarin]

Is it me or are physics dlls, all the rage lately?

[icuurd12b42]

No problem, I am using normal C++ classes for the entire engine, the functions in GM are actually just wrapper functions. You could even rewrite all wrapper functions yourself if you want.

The callback-script method sounds interesting, I will try that too.

Do you know if a ds_map is slower/faster than a ds_list? I could use maps for all variables and use the (EP) id of the object as the key.

Maps are slower than lists. But faster if you access data non sequentialy. If I run through the entire list, list is what you need. With maps, youwould only be able to associate one variable data anyway.

ds_map_add(themap,thekey,thevalue). So you would need a 3 keys and use strings for making the key

ds_map_find_value(themap,string(id) + "_x",thevalue).
ds_map_find_value(themap,string(id) + "_y",thevalue).
ds_map_find_value(themap,string(id) + "_angle",thevalue).

calling a script has potential to be faster... Especially if you would pass a lot of arguments. In your case though, only id,x,y,angle, it may not be the optimal solution

from my implementation
inline void script_execute(int script, double inst,double x,double y,double z,double rx,double ry,double rz,double xscl,double yscl,double zscl,double alpha,double color)
{
gm::CGMVariable args[] = {inst, x, y, z, rx, ry, rz, xscl, yscl, zscl, alpha, color};
gm::script_execute( script, args, 12);
}

[Maarten Baert]

ds_map_find_value(themap,string(id) + "_x",thevalue).
ds_map_find_value(themap,string(id) + "_y",thevalue).
ds_map_find_value(themap,string(id) + "_angle",thevalue).

That's not what I mean, I mean this:

ds_map_find_value(themap_x,id,thevalue)
ds_map_find_value(themap_y,id,thevalue)
ds_map_find_value(themap_angle,id,thevalue)

[Postality]

Is it me or are physics dlls, all the rage lately?

That's because there isn't any easy / complete ones out there. GMPhysics was, but it was canceled... PhysX was looking good, but then that was canceled...
Most other ones are 3D that are good (GMNewton) that is now getting 2D scripts, but it still simulates the Z axis which makes it slightly slower.

I'm going to give this one a try now... but that's the issue with Physics DLL's in the GMC. all the good ones are canceled and don't work right / missing functionality...

That's why I asked if you could make one as you're active in the GM and seem to know what you're doing when it comes to quality DLL's (I use a few of your other ones =))

Personally I liked the way PhyzX worked, but alas, Revel isn't going to be continuing it...

Gonna look at this one for now...

Thanx for the GMC contribution with the Physics engine.

Edited by Postality, 22 September 2009 - 09:04 PM.

[Syynth]

In the room with all 1003 objects, I got 45 at the lowest, usually 50. Also, it's really really fun to set the vel. iterations to 1, then quickly move the slider way up, and watch all the balls go flying away. I like this though, keep up the good work.

[icuurd12b42]

ds_map_find_value(themap,string(id) + "_x",thevalue).
ds_map_find_value(themap,string(id) + "_y",thevalue).
ds_map_find_value(themap,string(id) + "_angle",thevalue).

That's not what I mean, I mean this:

ds_map_find_value(themap_x,id,thevalue)
ds_map_find_value(themap_y,id,thevalue)
ds_map_find_value(themap_angle,id,thevalue)

Oh yeah, good thinking... Possibly this would work too. but I did not benchmark ds_maps against API calls, only ds_list in one sequential run VS api getx/y/z/rx/ry/rz() calls in one sequentila run...


I compared ds_maps vs ds_lists a while ago and they are quite slower. It is possible that a ds_map call is as slow as an API call.

This to show you to be careful you dont waste time implementing stuff for nothing.

[cactus]

This seems awesome. I'm really looking forward to giving it a go once there's a more easily understandable example to work from. Great job, man!

[theludicrous]

Very nice stuff!

I was heartbroken when CoderChris abandon GMphysics and its nice to see someone create a physics engine that rivals GMphysics. Since GMphysics dosent work for vista I have been searching for a decent 2D engine and this one makes the cut. I look forward to see future development and I cant wait until its stable enough for me to create a game.

Keep it coming

[theludicrous]

to show my appreciation for extreme physics, I've whipped up a quick banner for you:



EDIT: whoops, double post

Edited by theludicrous, 02 October 2009 - 05:20 PM.

[MrOpposite]

to show my appreciation for extreme physics, I've whipped up a quick banner for you:



EDIT: whoops, double post

Nice, but could you add something physics-ish to it? it seems not that physics-ish right now

[theludicrous]

to show my appreciation for extreme physics, I've whipped up a quick banner for you:



EDIT: whoops, double post

Nice, but could you add something physics-ish to it? it seems not that physics-ish right now

hmm, I have an idea

Edited by theludicrous, 04 October 2009 - 06:51 PM.

[Maarten Baert]

to show my appreciation for extreme physics, I've whipped up a quick banner for you:

<...>

WOW, great! If you could change the background color from green to gray/silver it would be perfect! The green doesn't go very well with my color scheme .