Trouble porting liquid simulation to Pascal - AARRGGHH!

[paul_nicholls]

LOL! ok, perhaps it doesn't work and is different that what is actually being used then

EDIT: hmm...I might try downloading the Java-Based Processing Programming Language mentioned, and try the supplied code to see if it is flawed or not

ZOIKS! It is ~85MBs in size...oh well, downloading...

cheers,
Paul

[paul_nicholls]

Ok, after a few minutes working out how to use Processing, I got the code as downloaded from the site to work just fine, so that is ok - it must be my port that is not working

Here is the direct link to the processing code that I ported if you hadn't already gotten that

http://1.shadowcdn.com/files/water_sim.zip

cheers,
Paul

[code_glitch]

Looking through it - gives me a break from modularization of prometheus so you're welcome for posting this... Plus thats a nice article - maybe making a pascal version of the tutorial would be nice for the PGD archives

[code_glitch]

paul: It wouldn't be a big nono if I wrote an equivalent bit of code to this since my port does not look too pretty in the IDE and gave you that instead? Trying to translate this C/C++ is not hard its just a tad annoying TBH. I wish we had a continue statement in pascal (not sure one does not exist actually ).

I'll get back to you guys with my equivalent code for this most soon... A fluid simulation engine would be quite nice for my games too.

[Dan]

I wish we had a continue statement in pascal (not sure one does not exist actually).

It does in fact exist.

[Ingemar]

EDIT: hmm...I might try downloading the Java-Based Processing Programming Language mentioned, and try the supplied code to see if it is flawed or not

The whole idea of making an interpreted language running with an interpreter written in Java, clinging to every design flaw of C from 1970 (even re-intruducing some flaws that were fixed in the 80's), it stinks so bad from start to end that I don't want to let more of it than the example source near my computer. But fluid simulation is nice, so freshing it up it by porting it to FPC could be useful.

One wish for the port: Portability! How about isolating all platform dependent stuff into one unit?

[code_glitch]

Ingemar: I very much like that idea. Unfortunately I made an attempt to get this working but it is an utter failure in many senses... See below:

I figured this might be easy so I wrote this up real quick: http://dl.dropbox.com/u/4853895/WaterSimF2.zip

Its my WaterSimF2 unit I had a crack at and a TestApp using prometheus for drawing the TMX background and updating the water etc... It behaves a bit like water with one exception: IN REVERSE!!! Oo I have o idea why but it does XD

So if anyone wants a fluid system that works in reverse until all the water is gone or just wants to mess around with it, see the link above

Edit:
Screenie:

http://dl.dropbox.com/u/4853895/WaterSimF2_Screenie.png

[paul_nicholls]

Ingemar: I very much like that idea. Unfortunately I made an attempt to get this working but it is an utter failure in many senses... See below:

I figured this might be easy so I wrote this up real quick: http://dl.dropbox.com/u/4853895/WaterSimF2.zip

Its my WaterSimF2 unit I had a crack at and a TestApp using prometheus for drawing the TMX background and updating the water etc... It behaves a bit like water with one exception: IN REVERSE!!! Oo I have o idea why but it does XD

So if anyone wants a fluid system that works in reverse until all the water is gone or just wants to mess around with it, see the link above

Edit:
Screenie:

http://dl.dropbox.com/u/4853895/WaterSimF2_Screenie.png

Hi code_glitch, I downloaded our port to have a look and found one thing - it doesn't compile using Delphi...

For example, in the Prometheus_Core.pas file:

{$Mode Delphi}

should probably be:

{$ifdef fpc}
{$Mode Delphi}
{$endif}

cheers,
Paul

[User137]

Water simulation on pixel/block map has been in my interest for long time. I did some experiments long ago, but they weren't that great. However that tutorial you linked (http://w-shadow.com/blog/2009/09/01/...id-simulation/) was quite good, only that it was explained way too complicated.

Lets say we do water for pixelmap. For performance and memory reasons we want to have running water in a separate array like particles, and still water (100% of pixel in water) drawn to pixelmap. The particles try to divide its water to different down, left and right, and if they can't move and go full 100% of water they solidify into pixel to that spot.

The particle could have the water amount represented as byte (0..255), where 255 is full. Down direction is first priority. It attempts to move down if there is no particle at that spot, but if is, it adds all its water to that particle at down. How do you know what particle is down and that pixel reserved, is 1 problem. I'd propably solve it with per-pixel word map, each 0..65k telling particle index in that spot. It's much faster than going the whole particle array through checking for position, but takes more memory and limiting amount of max particles.

Next there is left and right. They must be considered simultaneously so that the water is split evenly to all 3 positions, self, left and right. Well, here it doesn't propably even matter how you do the math, it will look cool anyway and spread the water in all cases. You can even split all water to left and right and leave current position empty, if they had room to take it all. Or you can calculate it so that water level in all 3 blocks is made as close to each other as possible, with water you have usable from the current particle.

Could add that it might look pretty nice if water that is falling down would split it to left and right about 20% of its amount. It will make little shower effect, because it may look boring to see water flow down 1 pixel wide line.

Oh, when doing for-loop for dynamic particles like this, you must go through it from ParticleCount-1 downto 0. It will otherwise act weird.

[code_glitch]

Paul: About the {$Mode Delphi} thing, I only use FPC and falsely make the assumption everyone else does. Sorry for that one - although if my code realy does not work in delphi, you could own your own copy of FPC for $0.00 extra!

I'm still trying to figure out what is making my sim go screwy but logically ( to me anyway ) it should work. In theory.