54 replies to this topic

[TheMagicNumber]

So if Box2D isn't compiled into the runner, than an extension wouldn't be able to access it via gml directly.

Not what I said, but okay. Having the ability to have native functions outside of the runner would be nice.

As mentioned, iOS doesn't support dylibs. So getting plugins would be hard without some major hacking, which would render such plugins useless since Apple would probably reject such stuff.

You don't need to use dylibs, as long as everything needed to implement dynamic linking yourself is there.

How? The OS itself doesn't support it. Maybe if Frameworks are permitted... but they're not on Mac OS X App Store apps.

You can't dynamically link stuff when the OS doesn't support it. Again, major hacking required. It's not a GM issue... it's an issue on how iOS works.

It is possible. It doesn't really need hacking, just a linker for the format it would use.

[kburkhart84]

Here's the catch guys. Assuming you could get Dylibs to work on iOS, how would that benefit other ports, specifically windows and android. Don't forget html5 too.

The best(although too slow still) way to get something to work on all platforms is to do it in gml, because that is the only thing(at least so far) that is guaranteed to pretty much just work on all given platforms. The only things that so far won't work on all platforms are certain windows functions, among a couple of other things.

[TheMagicNumber]

Here's the catch guys. Assuming you could get Dylibs to work on iOS, how would that benefit other ports, specifically windows and android. Don't forget html5 too.

The best(although too slow still) way to get something to work on all platforms is to do it in gml, because that is the only thing(at least so far) that is guaranteed to pretty much just work on all given platforms. The only things that so far won't work on all platforms are certain windows functions, among a couple of other things.

It's an extension for the runner, which would be developed by YoYoGames.

You could do it in GML, or you could have V8 support in the runner, giving you faster execution which is actually practical for a physics system (Box2D JS exists, too!).

Edited by TheMagicNumber, 20 May 2011 - 02:16 AM.

[kburkhart84]

Here's the catch guys. Assuming you could get Dylibs to work on iOS, how would that benefit other ports, specifically windows and android. Don't forget html5 too.

The best(although too slow still) way to get something to work on all platforms is to do it in gml, because that is the only thing(at least so far) that is guaranteed to pretty much just work on all given platforms. The only things that so far won't work on all platforms are certain windows functions, among a couple of other things.

It's an extension for the runner, which would be developed by YoYoGames.

You could do it in GML, or you could have V8 support in the runner, giving you faster execution which is actually practical for a physics system (Box2D JS exists, too!).

Would V8 work on all of the current platforms that GM supports?? I'm sure it works for the majority, but remember, whatever they use has to pretty much work in some form on all of them, hence the gml suggestion. I think the best bet for GM devs right now would be making gml that much faster. If we had the necessary speed with gml scripting(calling scripts too, not just execution) we very well could code our own physics engine, and put in extension form too. But, at gml's current speed, any physics you code pretty much have to be game specific, or at least genre specific to get enough speed.

[TheMagicNumber]

Would V8 work on all of the current platforms that GM supports??

Yes, all.

[kburkhart84]

Would V8 work on all of the current platforms that GM supports??

Yes, all.

Then in my books it would be feasible to include as part of the package, even if it is only in extension form.

[paul23]

Uhm what is the discussion value of discussing wether certain features should or should not be in gamemaker.. We have a specific topic for this.


In my opinion it would be much more interesting to discuss how gamemaker could handle this. As I said the actual physics calculations behind rigid bodies are very simple, and GML should be able to handle those with ease. I think the most difficult point would be to get the exact position of collision, I've tried reading some tutorials, but they all seem either above my level or very innefficient/not geared towards this problem.
The other problem you'll fall into is the lack of language features, having to store 2 variables for "vectors", lacking member functions (and the necessary data hiding) all make programming such an engine a bigger pain than it should be.
I personally experienced that learnig C++ to the necessary level needed to write this was easier than actually writing this is GML.

[kburkhart84]

I personally experienced that learnig C++ to the necessary level needed to write this was easier than actually writing this is GML.

I agree here, due mostly to the reasons you mentioned.

I think if you are using actual rigid body collision (as in not GM's version) then the point of collision can be calculated at the same time as you calculate the results of said collision. I haven't coded a physics engine, so I can't be completely sure, but I think that is how it works.

I'm also sure gml can handle such a physics engine, but I'm not sure how complex it can get, as in how many bodies and joints it can handle at once.

[paul23]

I personally experienced that learnig C++ to the necessary level needed to write this was easier than actually writing this is GML.

I agree here, due mostly to the reasons you mentioned.

I think if you are using actual rigid body collision (as in not GM's version) then the point of collision can be calculated at the same time as you calculate the results of said collision. I haven't coded a physics engine, so I can't be completely sure, but I think that is how it works.

I'm also sure gml can handle such a physics engine, but I'm not sure how complex it can get, as in how many bodies and joints it can handle at once.

Well, the physics part needs to "know" the angle of the surfaces from the colliding objects (so the normals to the collision line). If you have those you can transform those force vectors into a vector pointing towards the center of mass of the object(s) and a vector tangent to this. And you continue from there.

But all those things are straight forward calculations, computally difficult is simply getting the "time" at which collisions occur. (you want to use sub-step timing, as otherwise very many round-off errors occur)

[bvande]

You should try verlet integration. I have done a bit of work on it, but end up having trouble with walls and collisions. http://en.wikipedia....let_integration
http://www.gotoandpl...CharPhysics.php

Edited by bvande, 08 June 2011 - 11:53 PM.

[Rani_sputnik]

bvande -

This is a link to an engine that integrates collisions between dynamic->static
This is a link to a question on Gamestura asking about dynamic-dynamic collisions

The second is unfortunately in C++ but I hope these help

[Revel]

I had a friend integrate Verlet physics into GM which worked great and it was smooth for simple simulations.

Porting Box2D however I think would not work with GM. GM fails the most at performing iteration intensive operations. Considering box2D uses constraint solving, it requires many iterations for fixing/simulating all the constraints, it simply would not run smoothly at all in GM.

[KygonsCube]

I think I can make a pretty simple physics engine, although it would be limited. I can think of a way to make any basic polygon shape, (pentagons, triangles etc.) using mostly vectors and collision_line. This would take forever to tweak perfectly though, I CAN do it, but I really don't wan't to, who made GMPhysics anyways?

[bvande]

Box2d could work in GM, though. For c++, you could just write some code so GM could understand it(Box2d is written in c++). Since it would be a .dll or .gex, it would be compiled code, rather than interpreted, which is what GM does. This means that as long as you aren't doing GM statements for constraint solving or collision, and let Box2d do that, all GM would have to do would be drawing. So, Box2d could work with GM, but you would need to understand c++ (or another compatible language) to port it over.

[bovey]

There should be some 2D physics engine that's capable of some rigid bodies, ropes, collision detection, friction, etc.