54 replies to this topic

[ugriffin]

Usually, when GM games require 'advanced' physics, say, for a tower construction game (say, Mubbly Tower), people use GMPhysics, and similar engines.

I know for a fact that Extensions on iOS are impossible, since iOS doesn't support dynamic link libraries (for whatever reason). Since physic based games are pretty popular on iOS, and since that's something that a lot of us would like to use in mobile devices, there's a need, a gap if you will, for a decent physics engine that's GML based.

Sadly, I've never developed/dabbled in the mathematics required to do such a thing, nor do I know how GM would handle these computations.

So, my question/discussion topic is: why hasn't this been done properly ? Performance, lack of need for such a thing (until now), what?

I tried to look for stuff like this (and unearthed something that, adapted, could possibly be used for GML based physics), but there's nothing 'complete' or useful.

Any pointers?

[Desert Dog]

So, my question/discussion topic is: why hasn't this been done properly ? Performance, lack of need for such a thing (until now), what?

I don't think Katapeltis uses an DLL's or that:
http://www.yoyogames.com/games/149812-katapeltis

And sakisa did a fairly decent job on his physics engine, although you can definitely see it's a bit rough. Gameplay wise it's fine.

As to why it hasn't been 'done properly' well, it's just programming. If your going to make something, like sakisa did, for your game, then well and good. If you want it 'proper' then don't reinvent the wheel, use a DLL.

Edited by Desert Dog, 08 May 2011 - 08:06 AM.

[ani12321]

I don't think Katapeltis uses an DLL's or that:

It uses GMPhysics Dll

[paul23]

I've tried building a physics system in the past (one of my wips @ yoyogames had some quite advanced physical system under it), the problem is that a good physics engine requires a lot of "coding" to be done, and you're basically off to rewrite large parts that are cosidered a "given" in gamemaker (collision system, with a point-of collision etc).
Furthermore during all my work on those engines I often stumbled upon the problem of gamemaker's limited "fps", you need to build a system where object have a "velocity" and not based around points (especially important with small object flying through each other and handling collisions).

Those reasons make C++ (or any other language) a much neater choice, and programming within those language I found much more relaxing. The advantages of gamemaker were around 0, leaving you only with the disadvantages. Couple this with the fact that many people who CAN make a good physic simulation already got education for programming too (Programming is an often chosen extension to a physics course), and you get very little people interested into making this.

[snake5]

You'll probably need to DIY.
The math isn't that hard - you just have to read up on basic particle physics, separating axis theorem, integration stuff and collision handling.
Read only what's for games, academic stuff will give you only headache.

GM-specific: you can avoid integration with delta time if your game won't have different FPS in each room. Don't store vectors as instances, that will make your game crawl. Do use inheritance though - you can make basic shapes and inherit them in other objects, thus adding them to the simulation.
And be prepared to have lots of ...x, ...y variables (scalar components of vectors) by using a comfortable naming system for both variables and the scalar components. Avoid long variable names and avoid unreadable variable names. Try to separate the component part from vector name in a visible way, like this: lvelX (linear velocity X). It will make writing vector code much easier.
And avoid working with angles. They are completely unnecessary in game physics and can make things only worse.

GL & HF.

[chance]

So, my question/discussion topic is: why hasn't this been done properly ? Performance, lack of need for such a thing (until now), what?

But it has been done properly -- within the constraints of GML, and also with Dlls. I've seen a few good examples of rigid body collisions and constraints made in GM.

If you're interested in understanding how the mathematics works, it's worthwhile making some basic examples in GML yourself. The math isn't that difficult. But for lots of objects with complex interactions, GM isn't really the right tool. That's why you see various DLLs and extensions for this.

There's a topic in Advanced here dealing with this. Some of us have posted links to pages that describe the math involved. I recommend you have a look.

[ani12321]

I'm also quite interested in creating physics with GML so I made a google search and I've found an article explaining how to create a simple physics example in game maker and C++. The example is quite simple and it gives a good explanation on how to do physics in GM without using any Dll. Also in GM this example is very slow.
http://www.jalb.me/?p=19

[YellowAfterlife]

The thing is that YYG needs to do this.
Because if you DIY, your code is not compiled anyway, thus will be a lot slower than runner parts.

[TheMagicNumber]

YYG really should have at least Box2D in the runner.

[chance]

I'm also quite interested in creating physics with GML so I made a google search and I've found an article explaining how to create a simple physics example in game maker and C++. The example is quite simple and it gives a good explanation on how to do physics in GM without using any Dll. Also in GM this example is very slow.
http://www.jalb.me/?p=19

It's not slow in GM at all. What are you talking about? On my (modest) computer, your example will run at 580 frames/second.

[ani12321]

I'm also quite interested in creating physics with GML so I made a google search and I've found an article explaining how to create a simple physics example in game maker and C++. The example is quite simple and it gives a good explanation on how to do physics in GM without using any Dll. Also in GM this example is very slow.
http://www.jalb.me/?p=19

It's not slow in GM at all. What are you talking about? On my (modest) computer, your example will run at 580 frames/second.

Comparing with other physics engines for GM it is slower

[xshortguy]

Comparing with other physics engines for GM it is slower

And you base this on what tests? Let's see your data. Explain your method of testing, the equipment you are using to test this, etc.

[chance]

The example is quite simple and it gives a good explanation on how to do physics in GM without using any Dll. Also in GM this example is very slow.
http://www.jalb.me/?p=19

It's not slow in GM at all. What are you talking about? On my (modest) computer, your example will run at 580 frames/second.

Comparing with other physics engines for GM it is slower

Even if that's true (and it probably is), your statement is misleading and it gives a false impression. Ultimately, these demos get clamped at 60 Hz anyway. So if the GM example runs at 500 Hz, and the C++ example runs at 1000 Hz, who cares? The point is that in many cases, GM is fast enough.

I'm not saying you can do everything you want in GM. But let's not give the impression you can't do anything worthwhile.

[ani12321]

Comparing with other physics engines for GM it is slower

And you base this on what tests? Let's see your data. Explain your method of testing, the equipment you are using to test this, etc.

We all know that C++ is extremely faster than GameMaker so this does not need explanation but anyway look at this:
http://postimage.org/image/2cbp7aoqs/ I made a test in my very slow pc and created 500 objects to GML physics example. The result: 6 fps
http://postimage.org/image/2cdrmhays/ Look the Extremephysics dll. It has 1602 simulated bodies running more faster then the previous one.
Also as has been said in the article C++ code of this example has one if statement and no loops while GM has a lot

[xshortguy]

I don't doubt that a compiled language can run faster than an interpreted. However one can have comparable physics systems without a loss of speed for a reasonable number of objects. Furthermore, making many calls to the physics DLL can cause slowdowns as well. Saying that a compiled language will always be faster is not always true.

[chance]

We all know that C++ is extremely faster than GameMaker so this does not need explanation but anyway look at this
<etc>

That's often true. But xshortguy makes a good point about calling times.

Either way, that's not interesting. I'd rather talk about coding techniques for various physics effects. I thought that's what this topic was about.

[kburkhart84]

I just wanted to add that the reason physics can get used on the iPhone(non GM games) is that they are compiled, often with physics libraries as part of the package. This is in a "normal" coding environment though, or often in something like Unity3d or Shiva, which also have physics engines integrated into their code.

But, I'm going to have to agree that gml is "fast enough" for realistic physics. Of course there are limits, but most actual games are likely not to pass the limits, with a few exceptions. Really, how many games really need to manage the physics of 500 blocks at a time?? I know demos do it, to show speed, and for comparison purposes, but how many games actually need to do it. I'm sure there are a few that do, but not that many.

Speaking of gml physics, are there any currently supported extension that do it with only gml?? I know several of the extension do it, but they have "hidden" dlls as part of the package, and wouldn't work with other platforms. But, extension with only gml should work on all of GM's available platforms. It would be interesting to have such an extension, if none exist, in order to re-use code.

[Tepi]

I miss KC LC

Also, beware people, many act like they know much about coding physics simulations but in fact, don't even know numerical integration (or how it's relevant).

[ugriffin]

YYG really should have at least Box2D in the runner.

Yup, that would be ideal. However, until they do, something needs to be done.

I just wanted to add that the reason physics can get used on the iPhone(non GM games) is that they are compiled, often with physics libraries as part of the package. This is in a "normal" coding environment though, or often in something like Unity3d or Shiva, which also have physics engines integrated into their code.

The reason why there's so much physic based games on the iPhone is because the touch interface is ideal for this kind of stuff. And usually, people use Box2D when doing iPhone physics. It's in pretty much every single iOS game I've played.

But, I'm going to have to agree that gml is "fast enough" for realistic physics. Of course there are limits, but most actual games are likely not to pass the limits, with a few exceptions. Really, how many games really need to manage the physics of 500 blocks at a time?? I know demos do it, to show speed, and for comparison purposes, but how many games actually need to do it. I'm sure there are a few that do, but not that many.

When you actually start doing practical stuff a-la Angry Birds, compiled code can get pretty slow on pretty advanced mobile devices. A 400MHZ ARM11 processor has problems with Box2D.



I actually unearthed something pretty close to what I'm looking for. I'm going to try and adapt it and cook a little example of something "Physics-sy", it will be interesting how this works once we stop looking at simple bleak lines and start pushing full fledged objects and real graphics into the mix. Ideally, GM would include Box2D, but meanwhile this is a problem I percieve GM devs will start running into, when all the precious DLL's are removed and they have to switch to native GML code for stuff. Should be interesting.

[kburkhart84]

A 400Mhz ARM11 processor is pretty slow for a physics simulation. I'm sure it can be done, but not easily. The catch with integrating something like Box2d into GM is making sure it works the same on all platforms. No longer can yoyo make random changes without planning for html5, iDevices, Android, Mac, etc... For the most part, anything they add needs to work pretty much universally. I understand that Box2D is multi-platform, so that isn't so much the issue, rather making sure that when projects are compiled(with the new GMStudio) the Box2D has to work the same all around. You(ugriffin) seem to know enough about programming to understand what programming for multiple platforms really means. In C++, it tends to involve lots of pre-processor statements(mostly if/else constructs). For GM, I would think it involves each runner understanding all of the gml/d&d it can get fed. So when implementing Box2D, they have to implement it more than once, and test it more than once.

I honestly would be all for it. I'm starting to shy away from using any extensions that are dll based so that when GMStudio does come out, I won't have too much trouble getting used to the ways GM does things. For example, I'm no longer using my IrrKlang wrapper dll/extension. I'm instead using vanilla GM sound functions, because I know that when/if I decide to produce games for other platforms that aren't windows, I won't have to redo all of my sound code. I would think the same way for a physics API/library. It is getting to the point that if you want compatibility with all of the available platforms, you have to do it internal to GM, if nothing else for the reason that only windows can understand dlls. Other platforms have the alternatives(Mac with DyLibs for example), but it is much more difficult to create an alternative for each platform(and sometimes impossible if an API isn't multi-platform in the first place). But using GM's internal code, you should be guaranteed usage on all platforms(within speed limits among other things), so if an extension for physics exists(using only gml) then it would work on all platforms.