Print

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

[Sinergistic]

Request: An init setting that allows the user to define the fluid depth. Default/max = seven.

Problem: It would need a lower limit, because current fluid mechanics would start to break down around 4 or less depth, from what I can reason out.

For instance, if the scale of depth was 1-4; 1 = 'puddle'/evaporation, 2 = dangerous, 3 = over dwarf head and 4 = full tile.

Why: Well, this is kinda based on the belief that reducing the fluid depth system to something lower would improve FPS by reducing system load. If reducing the number of possible fluid levels wouldn't have an impact on, or if the impact would be to small to notice, this is kind of pointless.

(P.S. : [ARTDEFACE:YES/NO]

[Impaler[WrG]]

Fluid is probably measured with a single byte of memory, though it could theoretically go as high as 255 it would probably require a recompiled to take effect.  A system that could take an arbitrary max depth from the init would probably be slower regardless of what depth value was entered. 

Your assumption that a lower number would result in a faster game is fundamentally flawed, a computers Arithmetic and Logic Unit dose most operations in the same number of cycles regardless of the numbers size.  Computation is slowed down by having many many repeated steps, the complexity and number-crunching of each step is almost trivial compared to how many times it must be done.  Thus the system is designed to minimize the number of steps and 'hard-coding' the water depth to 7 allows us to skip steps that would otherwise have to be done if the depth were a variable.

[profit]

Fluid is probably measured with a single byte of memory, though it could theoretically go as high as 255 it would probably require a recompiled to take effect.  A system that could take an arbitrary max depth from the init would probably be slower regardless of what depth value was entered. 

Your assumption that a lower number would result in a faster game is fundamentally flawed, a computers Arithmetic and Logic Unit dose most operations in the same number of cycles regardless of the numbers size.  Computation is slowed down by having many many repeated steps, the complexity and number-crunching of each step is almost trivial compared to how many times it must be done.  Thus the system is designed to minimize the number of steps and 'hard-coding' the water depth to 7 allows us to skip steps that would otherwise have to be done if the depth were a variable.

Even worse...

Fluid depth is 3 bits in a 32 bit tile information variable.

Changing it in any way shape or form will require a massive code rewrite.

The only realistic possibility is offloading the fluid physics to a separate thread allowing multi-core processor usage.   I suppose you could also offload it to the PhysX physics engine or something like that but most people do not have PhysX cards or nvidia 9600+ cards yet.

[Shad0wyone]

I have nVidia 9650m GT 1 GB of win.

On my laptop!

[Sinergistic]

Ah, forget it then ^^

I'd just seen mention that it was set to 7 because of speed issues.

[Jay]

nvidia 9600+ cards yet.

Flaw.  All desktop Nvidia cards that are 8000-series or up are PhysX enabled.