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.
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.
I once tried to change the world. But they wouldn't give me the source code. Damned evil cunning.
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?
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.
Games:
Seafox
Pages:
Syntax Error Software
itch.io page
Online Chess
http://gameknot.com/#paul_nicholls
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.
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.
Last edited by User137; 31-08-2011 at 09:15 AM. Reason: project with source added
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.
@Ingemar: Nice work
@User137: Wow! this is very cool!
cheers,
Paul
Last edited by paul_nicholls; 31-08-2011 at 09:31 AM.
Games:
Seafox
Pages:
Syntax Error Software
itch.io page
Online Chess
http://gameknot.com/#paul_nicholls
Bookmarks