On Sun, 2004-08-15 at 12:04, bulia byak wrote:
I don't see that we need this custom RNG thing. Storing the generated random number with the star gives us portability and more.
What is non-portable about this simple formula? Depending on a system-provided RNG, on the other hand, may result in different rendering on different platforms or lib versions.
I agree; including our own RNG (particulary when it's this simple) is best.
For example, the seed can be controlled independently of tip position, allowing smoother variation of the output function and easier to get back to "that one half a second ago" without needing exceptional mouse stability: can use a "lower-geared" widget (less rapidly changing as a function of mouse position) or keyboard.
This seems to require some extra UI, and I'm not sure it's worth the trouble.
I am not sure we need to go that far, but experimenting with it it feels like it would be nice if I could make fine adjustments to e.g. inner/outer star radius without re-randomizing the shape.
I think all that is required UI-wise is a "randomize" button (and maybe a keyboard shortcut, as the star toolbar is getting a little crowded...) which selects a new seed. If the current "randomness" is 0.0, "randomize" should probably also bump it up to a sensible default.
Much less importantly: I'd guess that there can be consistency problems with using tip position to seed the RNG, due to different floating point behaviour on different machines (and even with different compiler or compiler flags).
When computing the unique int, the coordinates are rounded to approx 1/1000 of px, which is likely to protect it from rounding errors of any kind.
Not for floating-point numbers. They only preserve the upper N digits of the number (starting from the highest non-zero digit) and throw away the rest. If the value is big enough for a particular platform's floating-point representation to lose the digits after the decimal point, rounding to fractions of a px won't help.
What gets really fun is that the number of digits preserved can differ depending on whether the value came directly from an FP register or from memory (which in turn depends on compiler optimization setings, etc..).
These kinds of issues were responsible for many of the hard-to-solve bugs in the libnr renderer, and why Lauris' attempt to round to fractions of a pixel didn't fix everything. (livarot works better mainly because fred uses better algorithms, though fred may also have done some tweaking to stay within precision limits)
In practice I think double will have enough precision (minimum 52 bits) that this won't be a problem for generating seeds from realistic coordinates, but you should be aware of the issue.
-mental