I would consider banning implicit casting of floats to ints from the codebase: Nobody would have intentionally truncated in this HP conversion; they would’ve rounded.
[dead]
Aztec monks with 1/55 HP no longer die when picking up or dropping a relic
141–150 of 267 posts
Re: Aztec monks with 1/55 HP no longer die when picking up or dropping a relic
#142Earlier quoted context omitted.
Not exactly complex, but you posted too quickly to have found the best solution. A better solution is to kill the unit when it drops below zero HP, not when it drops below 1.0; scaling will never move the current HP past zero in either direction. Having 0.9999994 HP instead of 1.0 HP would not cause any problems then; the unit is still one hit away from death in either case. The best solution is probably to store the…
> The best solution is probably to store the current HP as a percentage of the max, because then you never have to rescale it in the first place. Doesn't this solution make the more common calculations more expensive, complicated, and error-prone to make one rare calculation easier? It seems like far more of the operations on the unit's current HP will be "gets damaged by X hp" or "gets healed by X hp", both of which…
If you’ve changed HP to a percentage, why wouldn’t you also change the damage and other related numbers (such as damage reduction and so on) to percentages as well? Nobody would be dumb enough to store them in different units and then convert every time they manipulate them.
Re: Aztec monks with 1/55 HP no longer die when picking up or dropping a relic
#143Earlier quoted context omitted.
In addition to the infantry gradual bufs, full-walling in Feudal using a mix of palisades and houses became ubiquitous. Pallisades, buildings-as-walls etc were gradually nerfed. Still popular, but now there's a higher associated cost. I wonder if they're done with those nerfs, or if there's another coming. (Since this technique is still very strong... Or maybe it's that scout rushes are strong!)
How was walling with housing nerfed? I remember doing that a lot.
In-progress buildings are easier to destroy IIRC. Palisades cost more and are slower to build.
Re: Aztec monks with 1/55 HP no longer die when picking up or dropping a relic
#144Earlier quoted context omitted.
> Seems all that could have been avoided by using rationals in general It's 2023: I'm still surprised that so many new languages/platforms still only provide only basic integer and IEEE-754 types for numerics: Rust, C#, Java, Swift and others still lack built-in, runtime-provided, nor even standard-library-provided rational types, which I assume really should be the preferred type for most business/domain/application…
> It's 2023: I'm still surprised that so many new languages/platforms […] still lack built-in, runtime-provided, nor even standard-library-provided rational types Because numerators and denominators can blow up easily, rational types effectively require storing them as bigints. That makes them bad from a performance viewpoint. Assuming your application will work fine with fixed-size rationals (which, IMO, is highly u…
I'm (vaguely) surprised there hasn't been a hardware type for rationals. Then the GCD operation could be done in hardware and everything would be fast (at least as fast as floats). Not surprising, because adding new hardware data types is hard, but the financial institutions would benefit from something like that.
A rat64 could be:
- 1 sign bit
- 3 format bits. Determines where the decimal is located, e.g. 30.30 vs 52.8.
- 60 bits of numerator and denominator. The split is determined by the format bit. 50.10 would be handy for any percent/ppt operations (e.g. Most USD operations)
Might need an error bit, but that's my 5 minute gist.
Re: Aztec monks with 1/55 HP no longer die when picking up or dropping a relic
#145Earlier quoted context omitted.
Seems all that could have been avoided by using rationals in general and the condition for living being >0 instead of dying The more I write code, the more I notice how rarely one truly should want floats in most kinds of programs and how they almost always carry a whole bag of problems with them.
> The more I write code, the more I notice how rarely one truly should want floats in most kinds of programs and how they almost always carry a whole bag of problems with them. This! Imho you more or less never want floats under "normal" conditions. Also in most application domains it makes exactly no difference that floats have HW support, as the bottlenecks are there usually elsewhere. And in case you really need r…
Floats are a computer representation of scientific notation, used for scientific computation. Coincidentally, hardware support is extremely important for scientific computation. (A bit less now than in the 90's but still a showstopper.)
Hardware support is also extremely important for games, but floats are not a good representation for most of it. IMO, game data should be composed exclusively of integral numbers, but it is natural to want a little bit more of precision some times.
Re: Aztec monks with 1/55 HP no longer die when picking up or dropping a relic
#146I would consider banning implicit casting of floats to ints from the codebase: Nobody would have intentionally truncated in this HP conversion; they would’ve rounded.
It's an unfortunate consequence of compatibility with C.
I'm pretty sure you could get the compiler to warn you about this stuff though.
Re: Aztec monks with 1/55 HP no longer die when picking up or dropping a relic
#147Is Age of Empires playable in MacOS? I’d like to remember my childhood years but going back to windows after 15 years of Ubuntu and MacOS gives me headaches.
Re: Aztec monks with 1/55 HP no longer die when picking up or dropping a relic
#148Earlier quoted context omitted.
The difference is, that with rationals you do not lose any precision on the way. I doubt, that 99^k is part of AoE2 code. For the simple calculations in AoE2 regarding unit health, rationals will do a fine job. With rationals the rounding does not happen during the precise calculation. It happens explicitly, only once, at the end of the calculation, at the programmer's wish and conscious decision, thereby avoiding th…
It's a very common pattern, in its more general forms. Sure, you can abstract away the naive re-implementation of exp() loop { x ← a*x } as one function call x(t) = exp(-k*t), so that one looks pointless. But moving-average [0] type expressions loop { x ← a*x + f(t) } are more interesting. You can't generally refactor those into exp() calls, like x(t) = sum[ f(t_i) * exp(-k*(t - t_i)) ], since that introduces a memor…
In a simulation nobody is calculating n x m^k. They’re calculating n X m in k loops spread over k ticks. And given that fact, if you round or truncate at the end of each cycle, as one often does with game points (eg, fire resistance in D&D), then there is no problem.
For money systems, we also tend to round on every step to the nearest penny.
What you don’t have with rationals is the problem of 10.00 - 4.10 + 3.20 ending in a 9.
Re: Aztec monks with 1/55 HP no longer die when picking up or dropping a relic
#149Earlier quoted context omitted.
Not exactly complex, but you posted too quickly to have found the best solution. A better solution is to kill the unit when it drops below zero HP, not when it drops below 1.0; scaling will never move the current HP past zero in either direction. Having 0.9999994 HP instead of 1.0 HP would not cause any problems then; the unit is still one hit away from death in either case. The best solution is probably to store the…
> A better solution is to kill the unit when it drops below zero HP Then you have the situation where units are displayed as having 0 HP but are still alive.
So what? The players already know that attacks deal fractional HP damage.
Re: Aztec monks with 1/55 HP no longer die when picking up or dropping a relic
#150Earlier quoted context omitted.
> It's 2023: I'm still surprised that so many new languages/platforms […] still lack built-in, runtime-provided, nor even standard-library-provided rational types Because numerators and denominators can blow up easily, rational types effectively require storing them as bigints. That makes them bad from a performance viewpoint. Assuming your application will work fine with fixed-size rationals (which, IMO, is highly u…
I'm (vaguely) surprised there hasn't been a hardware type for rationals. Then the GCD operation could be done in hardware and everything would be fast (at least as fast as floats). Not surprising, because adding new hardware data types is hard, but the financial institutions would benefit from something like that. A rat64 could be: - 1 sign bit - 3 format bits. Determines where the decimal is located, e.g. 30.30 vs 5…
> Then the GCD operation could be done in hardware and everything would be fast (at least as fast as floats).
Could it? Is there a fast way to do GCD in hardware?
Googling gave me https://en.wikipedia.org/wiki/Binary_GCD_algorithm, which needs O(log₂(max(u, v))) operations to compute gcd(u,v), but I wouldn’t know whether that’s the best we can do in hardware, or whether that’s ‘as fast as floats’.
Also, I don’t see how your format describes a rational type. Rationals store numbers as p/q for integer p and q, not with a decimal point.