On Sun, Sep 19, 2010 at 10:24:07PM +0200, Per Inge Mathisen wrote: > On Sun, Sep 19, 2010 at 10:12 PM, <muggen...@users.sourceforge.net> wrote: >> Log Message: >> ----------- >> piematrix: prepare for removal of fixed point math > > Careful! I believe some of this math is used for game state, and that > needs to be in fixed point, or else newnet will break.
Right, my main point against all that fixed point math is that it disguises the actual math going on by adding loads of shifts and muls only to correct for the fixed point offsets. E.g. a simple mul 'a * b' becomes '(a * b) >> fixed_point_bits'. Moreover, *why* does it need to be in fixed point? I know rounding errors can occur with floats, but that's what epsilon's for, to enable range-comparisons [1]. One very good of what disguising of the actual math going on can do: the pie_RotMat[XYZ] functions are *wrong*, i.e. they *wrongly* don't touch the column of the axis being rotated about. That's correct if your intent is not to ignore changes to the axes (which *can* be sensible at times, but isn't in this case), it however is *not* correct when you're intent is to perform the same transformation in-game as in the OpenGL renderer, considering that OpenGL does *not* do this. So *if* there's a good reason for using fixed point math, then at least reduce the risk of it introducing and disguising bugs by using some decent fixed-point library. But don't scatter all that fixed-point crap all over the code as it messes with the way we've all learned to think about basic mathematical operations. [1] http://stackoverflow.com/questions/17333/most-effective-way-for-float-and-double-comparison -- Giel -- "Computer Science is no more about computers than astronomy is about telescopes." -- Edsger Dijkstra
signature.asc
Description: Digital signature
_______________________________________________ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
