On Mon, Sep 20, 2010 at 3:17 AM, Giel van Schijndel <[email protected]> wrote: > Right, lets do that, or until we get there stuff it in functions, e.g.: >> int fixed_mul(int a, int b); >> int fixed_div(int a, int b);
Fine by me. > Except that '>> fixed_point_bits' and '/ (1 << fixed_point_bits)' are > used interchangeably making it a *lot* harder to ignore. Secondly, even > in places where one or the other is used consistently it isn't easy to > ignore. We could standardize on one or the other? I think "(a * b) [bunch of ignorable stuff]" is a bit more readable than "mul(a, b)", especially once it starts nesting. > Except that we never used floats to store HP, experience or power (and > never should use floats for that), so those points are moot. 2.3-branch uses floats for experience, iirc, and trunk uses it for power as well. I made a power queue patch that, among other things, converts power to fixed point, but it never got committed (because the "other things" in question were pretty controversial). > My > argument is about using floats for geometry, that's where floats shine > as long as all geometry resides in a limited space. And currently all > our geometry *does* reside in a limited space: the map boundaries. I don't mind using floats for pure graphics, but for other geometry, I think determinism matters more than variable precision (and by "precision" I mean "resolution" not "number of significant figures"). >> The only advantage of floating point is the ability to store large >> values at low precision and small values at high precision in the same >> data type, which is pretty much never needed in practice. > > Actually it stores small and large values at the *same* precision. > Which *is* needed in practice, in our case it's needed for rotations > (cos/sin). Well, it depends on how you define "precision". I was trying to use it to mean "resolution" rather than "number of significant figures". Resolution makes more sense as a definition in this context, too. It's not like you need more "precision" in the top left corner of the map than the lower right. > Right, and most geometric math (with translations as the *only* > exception) involves multiplication and division. Moving droids around is a lot of translation. =| Geometry isn't a part of the code I touch often, though, so I defer to Per and you. -Zarel _______________________________________________ Warzone-dev mailing list [email protected] https://mail.gna.org/listinfo/warzone-dev
