Trouble porting liquid simulation to Pascal - AARRGGHH!

[User137]

I got it compiled and running (buggily like mentioned) but MacOSAll had to be commented out from uses list. You could add something like {$IFDEF mac}MacOSAll,{$ENDIF} if there is such. This on Win7-32bit.

[paul_nicholls]

Woo Hoo!!

After some fiddling around, I have now gotten my fluid sim working just like the online demo (I think! LOL)
http://w-shadow.com/blog/2009/09/01/...id-simulation/



I have attached the complete project, including .exe and source code
xeEngine - liquid sim.zip

Escape = exit program
R = randomize map
C = clear map
right mouse button = water (+ shift = air)
left mouse button = wall (+ shift = air)

Enjoy!

It would be nice to know if anyone manages to use this in a project

cheers,
Paul

[User137]

After some fiddling around, I have now gotten my fluid sim working just like the online demo (I think! LOL)

It would be nice to know if anyone manages to use this in a project

It seems to be working somewhat, but there are 3 issues i can come up with
- The timer is very heavy on cpu, using full capacity of 1 core.
- Air pockets are filled with water coming from below. The pressure should in physical world limit water flow to only down and sideways, as it is implemented in many games too.
- The simulation goes through every tile on screen per game tick. It may work with small mapsizes but when it comes to larger and pixelmap, it would hog all resources. This is why i suggested particle based approach earlier in this thread, which would be very high performance.

[Ingemar]

Woo Hoo!!

After some fiddling around, I have now gotten my fluid sim working just like the online demo (I think! LOL)

I thought I should have a look at your code to see what I did wrong, but I am looking at your code and I don't get it. What code is working? I am looking in SimCompression_pde.pas, and it looks like... well, I must be looking at the wrong place because this can't be Pascal code:

if ( blocks[x][y] := GROUND) then continue;

That can NOT be a conversion of

if ( blocks[x][y] == GROUND) continue;

No, I must be looking in the wrong place. Is your archive really your working version? If it is, where is the code for the simulation?

I also note that if I change "continue" to "cycle" in my code, my code seem to get slightly closer to correct, so is really "continue" the same in both languages?

[code_glitch]

Theres a small mistake there in the first if statement, you use := wich is to assign, a c/c++ family == is the same as = without the :

Just my 2 pence.

[Ingemar]

Theres a small mistake there in the first if statement, you use := wich is to assign, a c/c++ family == is the same as = without the :

Just my 2 pence.

Yes, that is what I am saying. And there are such things all over that code so it can't be the working file. It looks more like a first step of conversion. The "for" loops are even worse:

for (integer x := 1; x <= map_width; x++)begin
for(integer y := 1; y <= map_height; y++)begin

Please don't tell me this is legal Pascal code. So is there a working conversion in there too?

[code_glitch]

Wait, I'd be over the moon if you could x++ in pascal - as far as I know its either the INC() way or x := x + 1 and declaration on the fly could be nice also mind you

Although when porting from one language to another - I have to admit a lot of my code can look like this or worse - but hey, if it compiles/compiled then please tell me how - I'd love those features

[paul_nicholls]

Wait, I'd be over the moon if you could x++ in pascal - as far as I know its either the INC() way or x := x + 1 and declaration on the fly could be nice also mind you

Although when porting from one language to another - I have to admit a lot of my code can look like this or worse - but hey, if it compiles/compiled then please tell me how - I'd love those features

I believe there is a setting in Lazarus (and I guess freepascal too) where you can use +=, -=, etc. operators, but I don't know about ++ and --

cheers,
Paul

[paul_nicholls]

I thought I should have a look at your code to see what I did wrong, but I am looking at your code and I don't get it. What code is working? I am looking in SimCompression_pde.pas, and it looks like... well, I must be looking at the wrong place because this can't be Pascal code:

if ( blocks[x][y] := GROUND) then continue;

That can NOT be a conversion of

if ( blocks[x][y] == GROUND) continue;

No, I must be looking in the wrong place. Is your archive really your working version? If it is, where is the code for the simulation?

I also note that if I change "continue" to "cycle" in my code, my code seem to get slightly closer to correct, so is really "continue" the same in both languages?

Ah! I know what is going on...the SimCompression_pde.pas file is a partially converted version which I forgot to delete - it is not used, sorry about that!!

The files you need to look at are the units\unit_liquidsimulator.pas file, and of course the xeEngineTest.dpr file too

Continue I think works the same in both languages, at least my code gives the same visible results...what does cycle do? I haven't heard of that one

It seems to be working somewhat, but there are 3 issues i can come up with
- The timer is very heavy on cpu, using full capacity of 1 core.

hmm...interesting, I just ran it on my machine here (Win XP, Intel(R) Core(TM) 2 Quad CPU (@2.83GHz, 3.48GB RAM) and it does't come close to hogging one core.

- Air pockets are filled with water coming from below. The pressure should in physical world limit water flow to only down and sideways, as it is implemented in many games too.

LOL The only game I remember playing with fluids is Terraria, and ok that does work only down and sideways as you said...but I quite like the way the 'pressure' pushes liquid up again as that is what I would expect to happen

It could easily be changed though

- The simulation goes through every tile on screen per game tick. It may work with small mapsizes but when it comes to larger and pixelmap, it would hog all resources. This is why i suggested particle based approach earlier in this thread, which would be very high performance.

Ok, it could definitely be made more efficient. Perhaps I could use a particle (pixel) based approach that you mentioned earlier, but that would be harder to draw wouldn't it? With the current version, you just draw some tiles (which also fits in with how a game I am writing is done too)...

Other ideas would be to have a separate list of tiles with pressures in them which you process instead of the whole map, and only process their neighbours too in the map when needed...that should be much quicker.

Hmm...I could also convert the current version to use fixed-point math too, that might may things quicker too

cheers,
Paul

[Ingemar]

I got it compiled and running (buggily like mentioned) but MacOSAll had to be commented out from uses list. You could add something like {$IFDEF mac}MacOSAll,{$ENDIF} if there is such. This on Win7-32bit.

MacOSAll isn't even used, it just popped in because I usually use it, but it has no place in portable code. But if that was the only difference, then portability is quite good.