Print

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

[Silverionmox]

Wouldn't it be possible to improve the FPS hit that water gives, by averaging out the height of water over a larger area? Instead of a eg. 100 square area with 90 7's and 10 6's, the water level in those squares would be stored as 6,9 and displayed as either the same 90 7's and 10 6's, but static, or as all sevens, but once every ten frames a six.

This would make the water static, and I assume that it would improve the framerate. On the other hand, it would require a larger number to be stored and processed (though rounding to the nearest tenth would suffice).

Another suggestion to make water movement more fluid: let's assume water moves a certain distance per frame; effectively, it would be the size of the waves. Assume 3 for the example:
(X=empty)

666XXXXXXXXX
666XXXXXXXXX

333333XXXXXX
333333XXXXXX

222222222XXX
222222222XXX

222222222222
222222111111

Using averages and a wave size of 3, it averages out in 4 steps. Now it would take longer in game time, and keep sucking FPS forever after.

[Align]

to allow decimal values would take as much memory as just allowing values 0-65535
or is it 0-4 million and a bit?
either way, increases required memory by a fairly extreme factor

Then there's the rather important detail of how you define a body of water as being continuous enough for this to be applied.

[Silverionmox]

Rounding it down to a tenth would probably not cause unappropriately vanishing water (it evaporates, after all). So instead of a byte now, that's two bytes. A mere doubling. I have not sufficient programming knowledge to know whether that would be worth the trade, FPS-wise. I suspect it is, because averaging would allow stability, and eliminate a lot of pointless calculations.

A filler algoritm (similar to the way a bedroom is determined) would be used to determine the original body of water (every adjacent square on the same z-level) as well as the new space it fills (the original body of water, expanded n steps into the empty space).

So the bodies of water needn't be stored in memory.

[MagicJuggler]

I would like to see vectorized water flow so that when two separate flows collide with each other, the cause interference (either constructive or destructive). E.g. if we get a northeast current and a northwest current, their x-components would negate each other and the water would flow north. Doing this would allow me to build a half-adder with more ease (e.g. with less gates required).

[Random832]

I would like to see vectorized water flow so that when two separate flows collide with each other, the cause interference (either constructive or destructive). E.g. if we get a northeast current and a northwest current, their x-components would negate each other and the water would flow north. Doing this would allow me to build a half-adder with more ease (e.g. with less gates required).

Does this happen in real life? I've seen your diagram, and I'm pretty sure all three of the "outputs" would fill with water no matter which one or both of the "inputs" are supplying water.

[MagicJuggler]

Assuming the water were a pressurized jet, the amount of water that would go in a perpendicular gate would be minor compared to going straight foward; the computer in particular I would like to emulate is this one:

http://www.blikstein.com/paulo/projects/project_water.html

[Draco18s]

water jets work like that, sure, but not waves.
http://www.jasondoucette.com/graphics/interfrl.gif

[Grumman]

to allow decimal values would take as much memory as just allowing values 0-65535
or is it 0-4 million and a bit?
either way, increases required memory by a fairly extreme factor

No, it wouldn't. Even for blocks up to 256 squares in size, you'd only need 11 bits, while 0-65535 requires 16 bits. Also, you must remember that this is 11 bits for an area of 16*16 squares.

I think it could work. You'd have to be able to assign squares to blocks (which would remove the advantage of lower memory requirements), and you'd have to perform the same checks at the edges of the block that you currently do per square, but those per-block checks wouldn't take as much work.

[Silverionmox]

I don't think it is evennecessary to assign squares to blocks, if a filler algorithm is used. The filler algorithm would use clock cycles, that's the tradeoff of course.

Anyway, the greatest advantage probably lies in the ability to let a body of water stabilize at an average height and be able to stop the calculations at that point, until a breach appears.

[Veroule]

The only problems I have with how the flow mechanics are currently done is that a syphon won't function, and a vacuum supported column (straw effect) can't occur.  Both require some sort of pressure modeling and interaction between air and fluid.

If Toady did put in at least some pressure modeling then we would all have to start using designs that permitted air to escape from tunnels and chamber as we filled them.

Pressure, friction, and viscosity are all factors in fluid dynamics; and it would be nice to see more then just viscosity recognized.  The easiest way I see that happenning is to recognize air.  Currently Toady uses 3 bits for volume, and 1 bit for fluid type.

Air would have to have a seperate number, with actual outdoors tiles being set to some value.  The value should be determined during world creation for a specific z level, then adjusted for the z level of the fortress.  By having expansion and compression limit for materials the trapped air and fluid can create a vacuum or compressed air.  It doesn't require changing the existing flow data bits, but would be a huge overhaul in the code.

After air pressure is actually modeled then maybe we can discuss wind and waves.

[Align]

No, it wouldn't. Even for blocks up to 256 squares in size, you'd only need 11 bits, while 0-65535 requires 16 bits. Also, you must remember that this is 11 bits for an area of 16*16 squares.

I think it could work. You'd have to be able to assign squares to blocks (which would remove the advantage of lower memory requirements), and you'd have to perform the same checks at the edges of the block that you currently do per square, but those per-block checks wouldn't take as much work.

Either way, decimal is unnecessary. Just make it 0-255 (or whatever) rather than 0-7.

[Granite26]

No, it wouldn't. Even for blocks up to 256 squares in size, you'd only need 11 bits, while 0-65535 requires 16 bits. Also, you must remember that this is 11 bits for an area of 16*16 squares.

I think it could work. You'd have to be able to assign squares to blocks (which would remove the advantage of lower memory requirements), and you'd have to perform the same checks at the edges of the block that you currently do per square, but those per-block checks wouldn't take as much work.

Either way, decimal is unnecessary. Just make it 0-255 (or whatever) rather than 0-7.

Making it 255 could be a way to align drinks-barrels-flows.. just let a barrel hold 16 drinks...

[Captain Failmore]

A less reasonable but more effective method of taking a load off of the CPU is to make the fluid simulation reliant on hardware better suited for it. Unfortunately, it would be a bit of a stretch for Toady to suddenly rewrite a major part of the engine to take advantage of a user's GPU for this sort of thing. (No, I'm not joking, skip to the bottom of my post if you want to know more.)

It would certainly be nice, though. Imagine, being able to run the game on a modern computer and have flowing water proceed at more than about ten FPS. I mean, the fluid simulation is a major feature of the game. Fluid simulations can be used to roughly model more than just water too. (Assorted liquid and gaseous entities, temperature, stress in solids for advanced cave-in code, etc.) Not that those bells and whistles are necessary for the game to be enjoyable, but they're very interesting and would make the game act quite differently than it does. As it stands, we have to choose between those features and being able to have more than a few dozen units in the game at a time if we want a decent frame rate.

If the various fluids were stored as a series of textures in the GPU and were acted upon by a simulation code running on the GPU's processors and memory, and the final result of the computation was piped back over to the CPU and stored in normal memory, the CPU and system RAM wouldn't have to touch the simulation at all, freeing them up for other tasks. This is both possible and hypothetically preferable, as the GPU has its own memory and is vastly more suited to the type of programming typically associated with the kind of fluid simulation that Dwarf Fortress runs. (Compare the arithmetic centric and highly parallel processing that the GPU employs for high speed number crunching, and the more complex serial processing the CPU employs for more general purpose work.)

But, again, it's unlikely that Toady would want to delve that far into what I'm assuming is unexplored territory for him. It could also be that the game's long development cycle is designed in part to ensure that by the time the game is finished, computers will actually be able to run it unhindered.

http://www.gpgpu.org/w/index.php/Main_Page

[Milskidasith]

Also, with the FPS hit problems, Dwarf Fortress, though it does use a ton of CPU cycles, is still horribly, horribly optimized (if you could call it that). By the time it's finished, not only do I expect the development of out of the box PC's to have outstripped the increased CPU cycles per second it is using, but I assume he would also optimize it. A lot. I can seriously see DF using about half of it's current cycles just with some good optimization, and that is a major FPS boost to most people.

[Captain Failmore]

Also, with the FPS hit problems, Dwarf Fortress, though it does use a ton of CPU cycles, is still horribly, horribly optimized (if you could call it that). By the time it's finished, not only do I expect the development of out of the box PC's to have outstripped the increased CPU cycles per second it is using, but I assume he would also optimize it. A lot. I can seriously see DF using about half of it's current cycles just with some good optimization, and that is a major FPS boost to most people.

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

Everybody... Everybody remembers old world generation.

On an older computer it could literally take up to an hour for the game to spit out a single world, and it would ordinarily take minutes for it to build an acceptable world from start to finish. At the very least, you were looking at a good five minutes of world generation, and that's without any rejections. Then the major 3-D release came with a much improved world generator. On the same computer I was using at the time, world generation would conclude in less than a minute.

There's no doubt in my mind that a lot of things can be spruced up in the game. We can't be certain what, but just polishing up the software could make it run a lot better as we've seen. Things like path-finding have already gotten a lot of attention, and I'd imagine that with the coming Army Arc releases we're going to see needed improvements and expansions of the artificial intelligence components of the game. (Path-finding being just one of them.)