Bay 12 Games Forum

Check out those transitions from smooth to rough walls.
Pretty freaking epic, right? I am enormously pleased with them.

That's pretty amazing stuff, cool idea Iranhand... I just wonder how that will look like blending with other kinds of rock.

Quote from: keda on June 24, 2010, 06:01:36 am

Apparently it doesn't work with the Windows Legacy version (becomes a tiny window), the SDL Windoiws version works however. What's the difference between the two anyways? Maybe it screws up some settings in the init file, you only need to change the bitmaps there to keda.png.

SDL has .png support. Legacy does not.

Well that explains it then. Thanks. Should work then unless its the mac version.

Ironhand: That's weird. Just to test it, I downloaded and extracted it on a newly extracted copy of df 31.08 and it works out of the box. Maybe its different with legacy or windows versions, going to try them all. Screenies should show up unless the server happened to be down when you checked, maybe I'll just upload them in a more reliable place.

Shaostoul: Thanks, I'll probably change the ramps, and add some more screenies. I like the small ramps better, but maybe that's just me.

Posting in the sand physics thread gave me an idea about how fluid mechanics could be sped up to reduce cpu load, for even large fluid masses to next to nothing. This idea would also support having multiple fluids per tile.

A fluid level is a z-position in a tile of fluid(s) ranging from 1-7. Any fluid connected with the same fluid on the same level compose a fluid layer. A fluid layer has an external border and any number of internal borders (holes), consisting of the tiles that do not have fluid on all 8 adjacent tiles on the same z-level. A sub border is a border that lies in a layer directly beneath to which there is a path consisting of fluid with no same fluid in an upper layer. Each external border has one sub-border in the layer below, while each internal border can have any number of sub-borders below. All fluids move from a border to one of its sub borders. Air has borders as well, but only in relation to fluid bodies.

Fluid displacement will work as follows:
Horizontal displacement:
For each body of fluid,
   For each layer border x
      sum the lengths of adjacent borders of any displacable material (or keep this number for each layer border) including air, to each sub border.
      If greater than the length of border x, all tiles displace 1/7 to the adjacent borders, spaced out evenly using something like Bresenham's line algorithm (may require some tweaking to handle irregular border problem, such as exclusion of already displaced border tiles until all have been displaced)
      otherwise, displace only the number of tiles that fit into the borders using same algorithm to pick out which to move.
      Update the borders.
Vertical displacement: If fluid is displaced, fluid of another type in the same tile drops, and creates a gap for potential fluid in the next z-level to drop into. this coordinate is put on an event vector. This also happens if fluid is displaced to a tile which has displaceable material below it.
The event vector is processed, by swapping fluids, which counts as displacement, thus allows bubbles to float up to its proper place after which they are removed from the event vector.

A note about displacability. If two fluids of different kind meet, one has the potential to displace the other if it does not react with it and has higher density, and there is space to displace it to, which is pushing it up, creating a new layer. This might need some resistance so that not all fluids of this kind are immediately displacable, but are sometimes not displacable.
Fluids can also destroy another fluid e.g. magma destroys sand, in which the above complication is not needed.
Fluid can also react with another to create either a third type of fluid or a solid natural rock of some kind.
If two fluids meet of the same kind, they will merge into one single body, and the external border of one will merge with the external or an internal border of the other.
Evaporation can cause bodies to split, and so perhaps the best way to handle it is not to count 1/7 tiles as fluid bodies, and fluid bodies are removed from memory if they reduce to a 1/7 layer (unless it is sandwiched with another kind of fluid on top) and is then treated as slowly evaporating fluid unless it comes in contact with a fluid that prevents this.
Cave ins, channeling, bridge retraction, hatch opening etc that cause two adjacent z tiles to be exposed to another, creates an event (pushes coordinate on event vector)
Pressurized fluids can move across different layers in the same body, in the same z level in an upper fluid level (U-teleportation) to one of its borders, or create a new layer on top if all borders are surrounded by solids.
There are probably more complications to it, but can't think of any at the moment, the basic (and major) improvement lies in how large masses of fluids move.

Well, I was not thinking of an arbitrary number of fluids, I guess you have a point there if that would have to be moddable, it would be very complicated, but if we keep to sand, magma, and water, I don't see much problem there. Magma melts or turn sand into glass, while water occupies the remaining space in the sand square. If water would be able to seep through sand, that would be more complicated though. Nothing a decent programmer couldn't handle though. I would think the CPU criticism is much more problematic, if it was true. But yeah if you want modding fluids that might be a lot of work.

Uploading in a moment. Got disconnected all of a sudden...

I don't know if this is just me, but when I use the mouse to designate digging or whatever, I can only designate in the upper part of the window, which happens to coincide with how big the window was originally. I'm using the linux SDL version.