[Shapefusion-devel] file save & fixed bug

[Tito D. C. <ti...@da...>]

I was comparing files written by trunk and 0.3, just for curiosity, when
I noticed something interesting about sequence names and something bad
about the "minimum light intensity" fixed field.

As you may know, the 32-char strings contain usually more text than
suggested by the first length byte. These are probably residual pieces
of longer names given by Bungie folks. Well, 0.3 won't touch them (apart
from setting a 0 at the right location) because it keeps the full 32
byte block in memory. Trunk, instead, will completely clear unused chars
with zeroes, tearing off those "ancient" chars, because it converts to
wxString internally. Not something we should worry about, just know it.
IMO trunk behaviour is more correct, since it follows the "convert that
ugly stuff to reasonable internal representation" phylosophy.

As for minimum light intensity... Apparently numerical roundoff in
ShapeFusion will progressively destroy minimum light intensity fields.
I've written a small test program which takes an initial double value
and simulates the effect of a succession of Shapes loading-saving. You
can see the effect on the attached plot, where I've plotted the field
value (starting from 0.5) versus the iteration. Each load-save cycle
seems to decrease the value by 0.01! So working intensively on a Shapes
file will eventually kill all minimum light intensities to 0. This
severe bug seems a combined effect of our fixed-double conversion code
(ShapesElements) and the fact that the wx field gets an event every time
we write something to it (ShapesView). I don't have yet found how to
solve it. Maybe we could just keep it as an integer value (between 0 and
0x10000) instead of converting to double. Damn wx, BTW ;-)

Bye
T
-- 
Physics is reverse engineering