I discovered this quite some time ago and brought it to attention. I thought it was fixed a long time ago in newer versions.

Which version of Construct are you using?

Awesome stuff!

Here's an idea:

Part of the reason particles are quicker than sprites is because they do not rotate after they are created. Could you make a new sprite/particles object that is optimized for fluid? I'm not sure how much of a difference optimizations to the sprites themselves would make (compared to if the physics was faster), but I do wonder. Also, does having two sprites = one water drop slow anything down at all compared to having only one object and still using ellipse? The faster the better

I believe that is intentional.

Oh, I didn't realize what kind of save system you wanted. I didn't know you meant saving levels. The method I stated before is really easy for, say, saving the character's stats, which room he's in (like in Castlevania), and some other simple stuff which is stored in global variables and things. I see that you need something more than that, though and therefore, my response does not solve your problem.

BTW, I do believe there are some methods to encrypt files, though I have not yet looked into this very much myself. If you work on protection of save files (character stats and such, not levels), just keep in mind that everything can be hacked and therefore it is only worth adding so much protection and putting so much effort into it. If the person can't just open it with notepad and alter stats, that might be good enough. It's up to you.

Also, I agree with gammabeam that two people "coding" together in Construct does not work very well. You can get help from other people, but two people working on events for the same game at once is a bit...complex. You can't copy stuff between .caps.

Platform behavior has an action that inverts controls.

BTW, your game reminds me of VVVVVV.

Even if Save/Load worked perfectly, I wouldn't want to use it for actually saving a game. It is much better to use .ini. New users normally think Save/Load is a good feature, but then find it has bugs or doesn't work like they think. Other methods (like using .ini) are just plain better methods, whether Save/Load has bugs or not, at least as far as I understand how Save/Load works.

irbis needs no hugs. He needs slapped. *slaps irbis*

Now that that is out of the way. Making a save system is actually really really simple. You just take some global variables (like your character stats) and write them to a .ini using the .ini object.

1) Set ini file's path (remember to create a .txt in notepad and rename it .ini)

2) Write your variables

3) Done

...

4) Not done, put in something that loads the ini again when you start your layout or game or something via the below

5) Set your global variables to their counterparts in the .ini using "Set global variable to (INI object) "Get string" or "Get Value"

6) Actually done.

This is partly off the top of my head. It may vary a tiny bit.

Edit: The slap part was just humorous. Opposite of a hug/tough love kind of joke. Just adding this in case it was lost in the black abyss that is the limitations of text.

> Tulamide, your example looks pretty cool. I can't seem to find what the fps is after the simulation actually starts but it shows fps at 60 first when it measures and the max particles is 380.

>

It runs at v-synced rate the whole time. As soon as the frame rate (that was measured at the beginning) drops, the spawning of sprites is stopped until the frame rate is up again (normally just a few ticks) The physics use 10 simulation steps and there are some calculatons that are done in an "for each" loop on every spawned sprite on every tick (for testing purposes). I'd say, with less calculations and lower simulation steps you could reach 600-1000 sprites. But the physics object seems to have problems with too many sprites that use custom collisions. I ran into serious issues with a collision shape using more than 5 points when having more than ~500 sprites on screen.

I could send you the cap and the blob shader (that isn't very gpu heavy, it works on a layer not on every sprite) if you are interested.

I'd very much like to see it. I also didn't know you were using custom collision shapes. Is ellipse slower? I'm thinking for an actual game I'd probably set the simulation steps to 1. I'm not sure how much that effects how "real" the water looks, but in one of quazi's examples it seemed just as good as 10. I'm also wondering if the physics plugin does any other calculations that really aren't necessary liquid, or at least, don't make a big difference.

I posted a somewhat long reply after Arima posted, but I get signed out of the forums a lot (something with my internet) so it didn't post.

Summary: I'm looking for a faster way to do it than physics + shaders like with quaziblobs. I know it isn't complicated to do with blobs, but performance is my main concern. I'm also wondering if there's a way to do it with blobs that's faster than some of the examples I've seen. For example, with the demo of that fluid engine, if I set it to render points rather than metaballs (which I think may be slowing down on my IGP), it runs at over 120fps with 500 particles.

Tulamide, your example looks pretty cool. I can't seem to find what the fps is after the simulation actually starts but it shows fps at 60 first when it measures and the max particles is 380.

I'm wondering if this 2D fluid simulation engine could be ported or replicated for Construct:

I believe it is open source, but I'm not sure if it could actually be put into Construct as I'm not a programmer. It looks like it could run pretty fast, but I haven't tried the demo myself. Apparently the engine has already been ported to C++, Unity, and other things.

Are you choosing a random point (out of a few points) for the AI to go to? If so, look into using 'random()' which generates a random number for a variable. Then compare for each variable and if the variable equals this or that then tell the AI to go to a certain point. Something about it should be on the Construct wiki.

It also sounds like you're doing top-down view so you might try RTS Behavior to make the AI walk to where you want it to go. It is very useful.

That seems to solve it. Thanks.