Page 4 of 4 FirstFirst ... 234
Results 31 to 39 of 39

Thread: Trouble porting liquid simulation to Pascal - AARRGGHH!

  1. #31
    Quote Originally Posted by code_glitch View Post
    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?

  2. #32
    PGD Staff code_glitch's Avatar
    Join Date
    Oct 2009
    Location
    UK (England, the bigger bit)
    Posts
    933
    Blog Entries
    45
    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 once tried to change the world. But they wouldn't give me the source code. Damned evil cunning.

  3. #33
    Quote Originally Posted by Ingemar View Post
    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

    Quote Originally Posted by User137 View Post
    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.

    Quote Originally Posted by User137 View Post
    - 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

    Quote Originally Posted by User137 View Post
    - 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
    Last edited by paul_nicholls; 31-08-2011 at 06:46 AM.

  4. #34
    Quote Originally Posted by code_glitch View Post
    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

  5. #35
    Quote Originally Posted by paul_nicholls View Post
    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
    Correct, and += and -= are pretty useful. ++ and --, however, I'd rather live without, especially when used for throwing in side effects while doing other things.

    You even have << and >> in FPC. It is sensible, the few times where C syntax makes sense there is no reason not to incorporate it. But finding C-style "for" loops is something that was supposed to be working Pascal code, that was scary. One detail that makes me uncertain is the ability to spread variable declarations all over the place. Should variables be at one place or anywhere? Defining a variable locally within a for loop or inside a begin-end pair, well, not entirely unreasonable... or is it just a workaround for messy code, when C programmers write entirely too big functions?

    Anyway, now that I know what files to look for I can compare what we do.
    Last edited by Ingemar; 31-08-2011 at 08:55 AM.

  6. #36
    I managed to partially do my idea on the pixelmap demo, just that i haven't done the solidifying part yet. With tiles that would be simple but i have to optimize the visuals for rendering to texture... So in the end all that would remain as particles is water surface and falling water, rest would become solid blue.

    Cpu use was showing 0% at 3000, 12% at 5000 particles and going up from there. The solidifying would greatly reduce the amount of particles.

    And it was quite fun to do too, was pulling my hair almost when equasion was wrong and water was disappearing slowly

    Edit: Solidifying is working now in my dev version and it's awesome! Just 1 bug with some random particles leaving bubbling inside and doesn't fill their density up. After that's fixed i'll show again.
    Attached Images Attached Images
    Attached Files Attached Files
    Last edited by User137; 31-08-2011 at 09:15 AM. Reason: project with source added

  7. #37
    OK, now I have fixed a few glitches and my version of the water simulation runs quite well. No Mac dependencies, I am not even using the macpas mode. It should be pretty close to Paul's version. The problem was in the screen update, not the simulation. What is good about this conversion: Small, close to the original, uses OpenGL (so it is fast), isolates user interface stuff (GLUT) into a separate unit so you can change it easily. Mac binary included.

    http://www.computer-graphics.se/water_sim_fpc.zip




    The "continue" keyword seems to work just fine, and is equivalent to "cycle" in the macpas dialect.

    I fixed the mouse support, so you can edit the map by clicking, which toggles between water and ground.

  8. #38
    @Ingemar: Nice work
    @User137: Wow! this is very cool!

    cheers,
    Paul
    Last edited by paul_nicholls; 31-08-2011 at 09:31 AM.

  9. #39
    So my pixel version should now be working correctly. Uploaded the files in its thread:
    http://www.pascalgamedevelopment.com...4326#post64326

    Here's additional eye candy when i was still debugging the behaviour.
    Blue = solid water drawn in texture
    red = moving water with density<254
    yellow = moving water with density=254
    gray = moving water with density=255

    Another picture just added... First i piled up a massive amount of water. Then go middle of water, hold firing key down and do a full 360 turn and you get something like this:
    http://imageshack.us/photo/my-images/825/waterbig.png/
    I just love to see things huge, lol. 46000 living water particles waving the streams. Very soon after it stabilized to more normal number of 1300 moving, where cpu is happy at 0% use.
    Attached Images Attached Images
    Last edited by User137; 31-08-2011 at 01:59 PM.

Page 4 of 4 FirstFirst ... 234

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Comodo SSL