next »

[Sean A.]

So I have this falling sand engine I whipped up today and it works great but I can only have maybe 700 particles before it goes below 30fps and 700 doesn't really fill up much so I can't have any decent sized bodies of water. I am including source code and I didn't really name sprites properly yet so don't mind that, but I'm looking to see if there is a way to maybe deactivate particles that aren't in use. The controls are left-click for water, right click for oil and middle mouse button to delete a wall object.

Also it was made in GM7 although I don't think it uses any registered functions, I could be wrong though.

Edit: New Version in the 3rd post.

[imaginationac]

I get about the same performance you reported, a little under 700 particles and the frame rate drops below 30. For some reason after holding down the left mouse button for a while caused oil to fall after a while. It only a happened the first time I ran the program, so I wasn't able to reproduce it.

A few tips:
If you can avoid putting everything in the step event. Only put what should be update every step.

Particles should eventually lose momentum, assuming you're modelling even close to Newtonian physics.
 
You're not removing particles if they're out of the view/room. This could help if appropriate.

I'm using GM 8 Pro, so if for some reason any of what I said does not apply, that's probably why.

[Sean A.]

While momentum seems like a good idea in theory, when I added it and it produced some unsavoury results. The first being that it would stack up on certain sides and some would be taller than others, which is doesn't happen with real water, and second it slows it down greatly. I came up with a simple solution, if a particle stays in the same spot for 5 "turns" then we stop calculating for that one. This works very well and I can easily fill a room with over 2000 particles and keep the fps above 30. The only downside is that when destroy a block it fills in the gap because I set all of the particles to calculate when I destroy a block, this makes it run very slow when that happens and it still leaves unrealistic stuff on the surface. Here is the new source you can try it out for yourself. I removed oil to keep it simple and I reduced the window size to what the game I'm making will be in. So left click is pour water, right click to remove a block.

[Skofo]

If I remember correctly, Game Maker objects are not very efficient because there are built-in variables and processes behind every object, regardless of whether you use them (like the built-in movement system). Perhaps you could try making one controller object which holds the particles in an array and see if that speeds things up any.

So it could be kinda like this:

Code:

 // first particle
particle[0, 0] = 0; // type (0 = water, 1 = oil, etc)
particle[0, 1] = 5; // x coordinate
particle[0, 2] = 10; // y coordinate

// second particle
particle[1, 0] = 1;
particle[1, 1] = 5;
particle[1, 2] = 11;

// etc

And then you could use a for loop in the step event to process each one.

I have no clue if this would help at all. Just throwing the idea out there.

It's worth mentioning that if you find yourself requiring to do these types of hacks for your games and knowing how to do them, you may be happier working with a programming language that is more concerned about performance than ease of use.

[Sean A.]

Thanks for the post, an array such as that could be slower but I'll try it out anyway. Also I have tried branching out to different programming languages but I find them very overwhelming whereas I'm pretty comfortable with GM. If you can recommend any languages that are similar that would be good too.

[Skofo]

It is indeed fairly difficult to cross the bridge from Game Maker to more conventional languages. I just thought that perhaps you might be ready to since you're working with something that is pushing Game Maker to its technical limits. If you feel comfortable with it, though, don't feel the need to be dragged anywhere else.

However, if you're feelin' wild, I would recommend trying out Processing, especially for this particular project. The language was designed to let people get things on the screen as quick and easily as possible, and the tutorials assume that you're a total beginner to computers, so you shouldn't worry about being overwhelmed. It is geared for visual effects, so it's meant to handle things like complex particles well. It also works pretty decently for games.  The main drawback is that you'd have to implement game-specific things like sprite animations and masks yourself, which is a fairly large drawback.

[Sean A.]

Hmmm, I'll take a look at Processing. The thing is that this engine isn't just a falling sand engine it will be the fluid engine for a game. I've also been looking into Java which from what I've seen is more powerful than Game Maker and I also hear it has similar syntax.

[voidSkipper]

In a program like this, you're going to be doing most of the legwork anyway. You're going to be (and already are) fighting GM to make it do what you want, so why not switch to a language which gives you more control?

[Sean A.]

Because I am comfortable with this one and I know the ropes. If you can suggest a language that would be an easy transition I would be open to taking a look at it.

[raigan]

I would say that Processing is probably a good suggestion; it can definitely handle this sort of simulation at any rate, and it's designed to be easy to pick up:

http://www.escapemotions.com/experiments/fluid_water_2/index.html
http://www.escapemotions.com/experiments/fluid_fire_3/index.html

[Sean A.]

Well in the future it's going to be much more than a tech demo kinda thing and skofo said that you have to do a lot of the leg work for animations and sprite masks.

[Pineapple]

Don't use a game engine for technical things like this. I created QuickSand, an FSG variation, and quickly learned how difficult it can be to optimize something like this. My recommendation is to take as many shortcuts as you can and keep particle interactions beyond simple slip, density, and gravity to a bare minimum.

[ஒழுக்கின்மை (Paul Eres)]

the code is somewhat inefficient. try this:

make a main object. port the code in the step event of water and oil into 'water1' and 'oil1' scripts. in the step event of the main object, do

with(water) water1();
with(oil) oil1();

also remember to put the main object into the room.

i got 20 fps with 1000 water objects in your example, with my changes that went up to 23 fps. not a big change, but noticeable.

more importantly, you don't need to check the movement of each object every step if it's stable. in other words, once an object's position is stable -- hasn't moved in a while -- surrounded by objects on all sides -- you can set a variable to 'stable' and simply not check its neighbors anymore.

there are a variety of other tricks you could use to increase frame rate (i've sort of become an expert at optimizing gm due to working on my current gm game's optimization for so long) but checking for stability is probably the biggest one.

but yeah, i wouldn't even use objects at all for this, it's terribly wasteful, using a data structure (not an array; arrays are slower in gml) would help a lot too, but that'd require recoding the entire thing, whereas the changes i suggest wouldn't require recoding it.

[Sean A.]

Funny thing you mention the stable thing Paul because I used that in the revamped one I made in the third post, already  I was thinking of recoding it with a data structure but I haven't had the time lately. Also please read my previous posts, I have said 3 times now I think that this will become a game it is just the water engine for a game and that is why I am using game maker. Thanks for all the input, I'll modify my engine with your suggestion tomorrow paul.

[ஒழுக்கின்மை (Paul Eres)]

ah, didn't see the latter posts -- it's probably a good idea to update the first post with the newest version, since not everyone (such as me) reads the whole thread before attempting to solve your problem / answer your question