Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Draco18s]

Quite true. I remember when world generation was cleaned up.

Actually I don't think it was cleaned up at all.  Old worlds used to take FOREVER because it had to generate at least 5 locations that had a river flowing north-south one tile due west of a north-south mountain range.

3D just opened up the rejection-checker to not care about river-mountain locations.

[profit]

This would actually work better if water height was stored as a 0-7000 integer and when the difference is less than 2 between squares computation stops.

Calculating 7-1 and 64000 - 11100 for a computer takes the same time because they are both an integer op... so shouldn't add burden and Should really help water to flow more naturally.

And when the water levels get to like 6687 and the squares next to it have 6686   no calculations are done.

Simple and effective.

water levels are still displayed as 1-7,  they are just rounded and the last 3 digits are dropped.

BTW THESE MUST REMAIN INT VALUES, Floating point operations *anythng using a decimal point* is very processor intensive.

[Fieari]

Fluids use 0-7 for memory usage considerations though, not CPU considerations.

[profit]

Oh? Memory usage? the smallest int programming variable is 0-255 if I recall correctly so, it could still use 1 to 70 easily.

But as for memory usage...  Say there are 5000 tiles of water... if they used 8 bits for 0-255  they would use 20k of memory.  if they used 0-65000 they would use 16 bit Int varibles which would use 40k of memory...

My machine currently has 2,000,0000k of memory.. so it could in theory hold 500,000 dwarf forts water usages in memory if each one had 5000 tiles of water.... my current fort has about 100 tiles of water so it would need 200 bytes of memory to store water depth information...

I cannot see memory use being a valid argument as the dwarf fortress process currently uses 185,492,000 bytes of memory I don't think  185,492,100 will hurt anything, but if for some reason it did, there is still plenty of room to do a 0 to 70 or 0 to 140 system.

[Random832]

Oh? Memory usage? the smallest int programming variable is 0-255 if I recall correctly so, it could still use 1 to 70 easily.

Yeah, but you can fit 0-7 in three bits and use the other five for something else. Every bit counts.

[Granite26]

tell me that's sarcasm...

[Random832]

tell me that's sarcasm...

You have over a million tiles (48x48x6x6x15 Z levels, and have to keep track of the amount of water or magma along with dozens of other things; damn right you're going to use bitfields. And, Yes, it _does_ only use three bits to store the water level. - how is that sarcasm? It takes up this space for every tile, not just tiles that have water - because dynamically allocating a structure for that would make things much more complicated.

[profit]

I suppose a packed 32 bit tile information (Double word?) would limit its ability to store anything over 3 bits worth of data.. I had never considered that it would store and calculate the water level tile for EVERY tile..  Not just the ones that have water on them.

so because of this even on a completely dry flat map about 500kbytes are purely dedicated to water usage. and the map is about 5mb in size, and 1,244,160 tiles have to be checked every update for water movement....

sounds like a recipe for lag.

[Granite26]

tell me that's sarcasm...

You have over a million tiles (48x48x6x6x15 Z levels, and have to keep track of the amount of water or magma along with dozens of other things; damn right you're going to use bitfields. And, Yes, it _does_ only use three bits to store the water level. - how is that sarcasm? It takes up this space for every tile, not just tiles that have water - because dynamically allocating a structure for that would make things much more complicated.

I guess I'm sitting pretty high on the hog with my computer, but a thousand bytes each for a million squares doesn't seem that unreasonable  (1/3 my system memory to store the map?  No problem).  That said, I can't imagine not using pointers for the contents of a square.  You are talking about something that's needed for a minute fraction of the squares that are loaded.  (Of course, the pointer space probably takes more room than the 3 bits, but that's beside the point...)

[Nesoo]

so because of this even on a completely dry flat map about 500kbytes are purely dedicated to water usage. and the map is about 5mb in size, and 1,244,160 tiles have to be checked every update for water movement....

sounds like a recipe for lag.

Not really. Toady has the map cut up in to square sections, and if the water is stabilized in a section (I think only for 7/7 and 0/7, but maybe for the in between values as well), it's skipped over for water calculations. It's only when there's dynamic water in the section that the tiles in it need to be checked. In this way, the vast majority of the map is skipped when calculating flows. (Unless you've unleashed a river all throughout your fortress or something...)