On Mon, Sep 20, 2010 at 10:10:01AM -0500, Guangcong Luo wrote: > On Mon, Sep 20, 2010 at 3:17 AM, Giel van Schijndel <m...@mortis.eu> 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.
Personally I like the idea of operator overloading (FixedPointInteger class) even better than either option. How much source (non-header) files directly contain fixed point math (those would need to be(come) C++ for overloading)? >> 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). Ouch, currency-like stuff should indeed be done with fixed point. >> 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"). Sorry, what do you mean by resolution? As the way I interpret it is: amount of datapoints within the same numerical range, which is the same as "number of significant figures" combined with an exponent for the range. >>> 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. I agree on that. You want an equal amount (or at least the same baseline) of precision across a range (our range being from lower-left to upper-right map corners). >> 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. Right, except that the greatest errors with "moving droids around" are more likely to be due to a rotation that's slightly off than a translation that's slightly off. This is because rotation errors are magnified when translation occurs. -- Giel
signature.asc
Description: Digital signature
_______________________________________________ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
