![[es]](/mwf/flags/es.png "Spain")
Matthes mentioned in the internal forum that the usage of a (2D) physics engine could really be a killer feature for OC. I looked around a bit and noticed that there are a couple of engines that are compatible with the ISC licence. Here are the interesting ones:- ODE - BSD license, since 2001, last update 01-2009
- Bullet - zlib license, since 2005, last update 03-2009
- Newton Game Dynamics - closed source but free available, since 2003, last update 04-2008
- Box2D - zlib license, since 2006, last update 04-2008
- Physics abstraction layer - not a physics engine but sth. like a wrapper, compatible to the above
What functionality we need especially for Clonk:
- 2D collision detection with shapes (Rigid body dynamics). Collision with the landscape must be easily implementable.
- Support for collision detection in different layers as objects do not collide with structures but objects with objects and Clonks, maybe vehicles with vehicles and structures with structures etc.
What it could replace:
- solid masks (no, really!) and climbing on ladders
- vertices, friction and rotation, vehicle physics
- lines
- wind, gravity, blastwaves etc.
Probably, these lists are not complete. Please correct me.
Here, I just want to provide first sources for engaging oneself in physics engines. I did not have a closer look at the engines, yet.
![[de]](/mwf/flags/de.png "Germany")
> Collision with the landscape must be easily implementable.
I fear we'll have to settle with "possible" instead of "easy" ;-) I actually tried to do this with box2d, and the naive approach of using one square for each landscape pixel doesn't work. I think we would have to create polygons to use box2d. But maybe the other options have something better.
![[us]](/mwf/flags/us.png "United States")
Collision detection is relatively easy to do. I'm not sure why we would need an engine for that. Wind, Gravity, Shockwaves, etc. are also easy to do and exist already in the Clonk code.Things that would be real work to do would be real Rigid Body Dynamics containing bodies attached to each other (think of ragdolls). Also, real lines (rope dynamics) could be hard.
In any case, the Physics engine would need to work completely predictable without using floating point math for synchronization reasons. Do any of the packages include that?
>Shockwaves [...] exist already in the Clonk code
Real waves, that travel around objects? Where did you hide that?
soldat.pl is a good example of what s good body simulation.
A realistic body-landscape-interaction do we have to implement by ourselves 'cause there is no physic engine for such precise imaginations
A realistic body-landscape-interaction do we have to implement by ourselves 'cause there is no physic engine for such precise imaginations
Oh, don't be so exact. Sure, it is predictable for one system. But it might differ between architectures or operating systems.
I lost count of the number of floating point desyncs we had to fix by replacing the calculations with C4Fixed.
There is a standard on float representation, but depending on the assembly the compiler generates, values may be truncated by storing them in the general purpose CPU registers at different points in program execution.
i wrote some code for gwx that tests float computation on different systems and generates an ID which represents a sort of processor floating point cumputation
[code]prozessor:='####'; //Zur Kompatibilität der Prozessoren!
{$O-}Psingle(@prozessor[1])^:=sin(sqr(pi)+sqrt(pi));{$O+}
prozessor:=inttohex(pinteger(@prozessor[1])^,8);
[/code]//By the way to show that pascal can be complicated, too
it just compares whether the expression sin(pi²+sqareroot(pi)) has the same result.
in truncating i suggest to use opcode "fistp" (float to integer store at pointer)
[code]prozessor:='####'; //Zur Kompatibilität der Prozessoren!
{$O-}Psingle(@prozessor[1])^:=sin(sqr(pi)+sqrt(pi));{$O+}
prozessor:=inttohex(pinteger(@prozessor[1])^,8);
[/code]//By the way to show that pascal can be complicated, too
it just compares whether the expression sin(pi²+sqareroot(pi)) has the same result.
in truncating i suggest to use opcode "fistp" (float to integer store at pointer)
> in truncating i suggest to use opcode "fistp"
I'd rather use fixpoint numbers than litter our code with inline assembly.
Which of course implies that if we can get every compiler to issue the same assembly, we can use floats. I have a slight hope that a bytecode interpreter might be able to do this because it forces the result after every single computation into memory, which means that there is less room for the compiler to juggle the truncation. But that'll require rigorous test cases.
We would have to test whether current processors, given the same bytecode, really do respect the spec. I could imagine, for example, a processor might work at a higher precision internally and cause differences in rounding at the last digit.
They do - at least the x86 uses 80 bit registers. Amd64 and SSE either use 32 or 64 bit. But if the spec is friendly, one calculation immediately followed by a truncation should lead to the same result as doing the math with that precision. But I'm kind of disappointed with floats, so I'm not betting on that...
![[ch]](/mwf/flags/ch.png "Switzerland")
Some games use only integer calculations in the synccode or even fixed-point. But those are 'small' games, so I don't know how the 'big games' do it ;)
Why don't we say, okay, the first 42 bits of an integer are before the dot, the rest is for some digits calculation accuracy? Is that possible?
Or, why would we need float point evaluations for advanced physics?
Or, why would we need float point evaluations for advanced physics?
Clonk uses a 16.16 split at the moment, which is good enough for the simple calculations done. More complex stuff might require more to be stable, I don't know.
Does any floating point or fixed point datatype exist in new c4scripts?
Without 'Emulation by Script' you can not use floats in C4Script. (Except there's hidden internal stuff)
emulation ^^ fixed point floats...yea but it could be also integrated in the engine.
(see bugtracker with those 10000000-numbers)
(see bugtracker with those 10000000-numbers)
Whats about the Chipmunk-2D-Engine? -> http://code.google.com/p/chipmunk-physics/
Newton Game Dynamics is for precise but slower calculation, so not very fitting for a game with potentially a lot of collisions.Stuff about Box2D - Box2D is not dead, as the date of the last stable release might suggest.
regarding network:
Problems have been discussed shortly here: http://www.box2d.org/forum/viewtopic.php?f=3&t=1719&hilit=network
And this - or will be - a game which uses Box2D and runs over network on multiple platforms: http://www.quadrivium.muistivuoto.net/
However, networking physics seems to be not such a trivial thing to do.
Chipmunk 2D: MIT-license, C interface, lightweight, in development, last end of 2008, a bunch of games (~20) use Chipmunk2d, none of which have a network mode (if I see it correctly)
There loads of games which use ODE, many of these support multiplayer (and many are racing games). There must be a only-2D-mode because World-of-Goo uses it.
Bullet seems to be the biggest one with the most features and is most widely used one, offering even Blender3D-plugin to build 3D-models linked to the engine. (oho, destroying structures the fun way...!). If there is an only-2D-mode, I don't know.
As I / we don't want to be (amongst) the first ones to try to use physics engines for network games, I won't look further into Box2D and Chipmunk as they look cool and lightweight but nobody* went that way before.
* well some are right now, see above
>, offering even Blender3D-plugin to build 3D-models linked to the engine.
Blender uses Bullet for its physics. In the Blendergameengine anyway.(By the way: there are some games with multiplayer made with the Blendergameengine)
> There loads of games which use ODE, many of these support multiplayer (and many are racing games). There must be a only-2D-mode because World-of-Goo uses it.
I've used ODE for a small game (university project, 3d, no network, heightmap-landscape) and was quite happy with it (after spending a lot of time tuning the parameters to get things stable).
Are the ODE developers still active? The website always seems a little outdated...but at least it's really widely used (and thus tested) in games (also 2d) and some scientific robot simulations (afaik).
Here is an small HowTo for constraining ODE to 2d:
http://opende.sourceforge.net/wiki/index.php/HOWTO_constrain_objects_to_2d
I don't know what the speed will be compared to real 2d engines though...
![[pl]](/mwf/flags/pl.png "Poland")
Check http://www.datarealms.com/
Developers of this game have got fully working 2D physics engine with pixel-based terrain, and also pixel-based objects! You could ask them what they are using.
Developers of this game have got fully working 2D physics engine with pixel-based terrain, and also pixel-based objects! You could ask them what they are using.
Check
I've found another one: StepCore. It is the physicsengine created to be used in the (2d) physicsimulationprogram step. It is very powerful (gas and liquid simulation, particles, springs and softbodies). Step is (afaik) Linuxonly but StepCore is OS independent. But the Problem could be that it is GPL and not LGPL.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
