About to break everything with a merge
Mostly features added to DebugScript Also got MPFR C++ reals to work Should allow for a quantitative comparison between Rationals and Arbitrary Precision Floats Just... overwhelming amounts of results that it would be nice to get, so I don't know where to start...
Don't sigfpe as much
More turtles Also we can't take logarithms of negative numbers, dur
Compile with float/double again.
Turtles all the way down Also fix up DebugScript's performance data I can actually plot things! Still haven't actually plotted things, but in theory I can.
Keeping it Real, add Gmprat::Str, Gmprat::Log10 Fixed* all those horrible compile errors. View can now use VReal and Path can now use PReal and at the moment they are Gmprat unless the quadtree is enabled. For Gmprat::Log10 there are problems. Using: log(a/b) = log(a) - log(b) log(a*b) = log(a) + log(b) Unfortunately mpz_div_ui quickly becomes a massive performance issue. Even when well within the range of IEEE singles. Need to rewrite Gmprat::Log10 but may as well commit since it works* slowly at least.
Totally FITH everything I'm trying to get it so that Path and View can use a different number representation to Bezier. It's not going well.
Use Gmprat for Path bounds with TRANSFORM_BEZIERS_TO_PATH So, the bounds of Paths are stored with Gmprat The Bezier's are all stored relative to the Path, as floats The transformations are only applied to the Path Gmprat bounds. This seems to work rather well. In other news, the DeCasteljau algorithm in the CPU renderer had no upper limit, which is why it was slowing down so much. The CPU renderer tends to suffer from SIGFPE-itis when using floats, because when you do a cast there is a SIGFPE if the resultant type can't represent the operand. This occurs in a few places that don't actually affect the rendering...
Add loadsvg script command, fix ParanoidNumber size limiting* Need to write some scripts and performance test them now I guess? Maybe add commands for scripts to output information for plotting.
Commit before breaking everything Trying to make ParanoidNumber less shit. Spends a lot of time in std::vector
All of the things and none of the sleep GMPrat is a type that works (un)surprisingly well, until you start changing the view. ParanoidNumbers explode more dramatically but actually simplify for certain things. Simplify seems to end up adding operations that don't cancel twice, eg: debug: TestRandomisedOps (tests/paranoidtester.cpp:152) - Test 1000*1 randomised ops (max digits = 4) ERROR: TestRandomisedOps (tests/paranoidtester.cpp:208) - {7+(7/10)} *= {119} ERROR: TestRandomisedOps (tests/paranoidtester.cpp:209) - {7*119+(99127/10)} ERROR: TestRandomisedOps (tests/paranoidtester.cpp:210) - double Yields: 916.2999773025512695312500000000000000000000 ERROR: TestRandomisedOps (tests/paranoidtester.cpp:211) - PN Yields: 10745.7001953125000000000000000000000000000000 FATAL: int)() (tests/paranoidtester.cpp:212) - Failed on case 102 Note 7*119 * 119 = 99127, so the *119 is being applied extra times Probably because of reasons that hopefully the cold light of morning will reveal.
Change to things to make performance testing easier - Saving of CPU and GPU BMPs - OverlayBMP doesn't overlay a BMP which is good because we don't want it to... - SVG loads in centre of view - This will break the Quad tree, probably - tests/bmpdiff allows us to quantitatively compare output bmp images. - I didn't say it was a good metric, there's just a metric now. - Arguments to set rendering and transform type, argument to set maximum number of frames to render, argument to turn off the lazy rendering. Will make some kind of ipython notebook next I guess.
Paranoia is setting in Paranoid Numbers are hard to simplify properly. But they work. Kind of...
Add MPFRC++ mpreal type It's slow but less slow than Rationals. Project complete. Haha I wish.
Fix compiling with non doubles Added really terrible number representation as a series of operations on floats. It currently gets a few things wrong...
Classify Beziers, use DeCasteljau for CPU renderer I don't know how glDrawLines does it, but I can't get rid of the wiggles in straight lines done using CPU renderer. So I switched to DeCasteljau. Then I made it classify the lines and only use one Bresenham instead of 100 anyway.
Careful, you may have to shade your eyes Except for all the things that don't quite work, shading works perfectly.
Add a vec2 struct.
Bezier bounds rectangles are calculated correctly CPU rendering and SVG parsing uses absolute coordinates. GPU rendering uses relative coordinates (relative to the bounding box). The Objects struct stores the absolute bounding boxes now. Previously it was just using {0,0,1,1} (and thus the GPU's relative coordinates were equivelant to the CPU's absolute coordinates). I might have fixed some other things but I can't remember.