Sam Moore [Thu, 14 Aug 2014 04:48:04 +0000 (12:48 +0800)]
SVG tests are 100% less symlinky
That's the good news.
The bad news is that somewhere along the way a bunch of them became 100% more segfaulty.
Sam Moore [Thu, 14 Aug 2014 04:34:55 +0000 (12:34 +0800)]
Groups are a thing and sort of have a bounding box now
That was what I forgot in the last commit; I added "GROUP".
So, the idea is that GROUP can be used to shade a path.
Maybe. Eventually.
Or, it could just be used to make quad tree magic easier (?)
Or it could do both! (Since you can pretty easily just turn off the shading...
but we're getting ahead of ourselves a bit there)
Or, if it gets given a name, then it can be used to implement the <use> SVG tag.
And then we can allow recursion (which regular SVG doesn't support).
Wouldn't it be nice...
Sam Moore [Thu, 14 Aug 2014 04:21:31 +0000 (12:21 +0800)]
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.
David Gow [Wed, 13 Aug 2014 13:38:56 +0000 (21:38 +0800)]
Support some more SVG stuff.
Can now get a dodgy, slightly hacked bit of gnuplot output to
render.
David Gow [Wed, 13 Aug 2014 13:09:59 +0000 (21:09 +0800)]
Clipping for RECT types. Breaks a little.
When using QuadTrees, RECT_OUTLINE and RECT_FILLED are clipped to
the quadtree node.
This lets you zoom in forever on rectangles with a couple of caveats:
1. This is technically wrong for RECT_OUTLINE, as more lines will be added.
2. There are a couple of issues related to the fact that only one node is
visible at a time. Notably:
(a) You lose the infinite precision when stradling a quadtree boundary,
which will happen eventually.
(b) Zooming out will show random broken things.
However, if you look at shape.svg, you can see how moving the camera around when
both the RECT and the BEZIER are in view, the RECT moves smoothly and the BEZIER
doesn't.
David Gow [Wed, 13 Aug 2014 12:52:57 +0000 (20:52 +0800)]
Use correct font metrics from truetype files.
Kerning, etc. should now be correct, but we use a monospace font
so it doesn't matter.
David Gow [Wed, 13 Aug 2014 11:49:33 +0000 (19:49 +0800)]
Automatically generate quadtree children.
This mostly works, and does the view reparenting. It doesn't do any clipping,
so we still hit precision issues as (for example) bézier control points are
outside the quadtree node's coordinate system, and become very, very large.
There are some issues with the boundaries of quadtree nodes, as the system
currently can't display two nodes at once. To compensate, it traverses up the
tree until it finds a single node which contains both, though this will be
a distant anscestor if the nodes are distantly related.
Quadtrees are still disabled by default. There are also a couple of minor
changes to the GL code to make it spit out fewer error messages and run
slightly faster on some hardware.
David Gow [Wed, 13 Aug 2014 08:05:38 +0000 (16:05 +0800)]
I am an idiot: the quadtree code is now fixed.
tl;dr: needed more * by 2.
iab;wtd*: The index buffers on the GPU contain _two_ elements per object,
one for the top left of the object's bounding box, one for the bottom-right.
We were taking that into account when computing the number of indices to give
the DrawElements() call, but not when calculating the offset into the buffer.
Oops.
*: I am bored; want tedious detail
David Gow [Wed, 13 Aug 2014 04:45:26 +0000 (12:45 +0800)]
A bunch of OpenGL debug annotations.
(Which will probably break compiling on cabellera)
Sam Moore [Tue, 12 Aug 2014 16:54:35 +0000 (00:54 +0800)]
SVG transforms now less broken
They work for rabbit_simple.svg now; that's pretty cool
Still appear slightly broken for more complicated SVGs (eg: the fox in ipdf/sam).
svg-tests/recursive.svg produces this error in eye of mate:
(eom:7883): librsvg-WARNING **: Circular SVG reference noticed, dropping
(If you have only one group referencing itself, there is no error but no recursion).
David Gow [Tue, 12 Aug 2014 14:08:36 +0000 (22:08 +0800)]
Merge branch 'master' of git.ucc.asn.au:ipdf/code
David Gow [Tue, 12 Aug 2014 14:07:56 +0000 (22:07 +0800)]
Still-broken quadtree shenanigans!
Quadtrees are, therefore, still disabled by default.
Sam Moore [Tue, 12 Aug 2014 10:29:59 +0000 (18:29 +0800)]
Only slightly totally broken SVG transformations
Argh
The matrices are ((a c e) (b d f) (0 0 1))
*Not* ((a b c) (d e f) (0 0 1))
I guess it's better than the Rect bounds crap.
But still broken.
Sam Moore [Tue, 12 Aug 2014 07:14:40 +0000 (15:14 +0800)]
SVG text and line elements
Totally not done properly but whatever
Sam Moore [Tue, 12 Aug 2014 06:36:47 +0000 (14:36 +0800)]
Make adding text to the document easier
tl;dr Use Document::AddText() to put text in places
Pass the font file in the Document constructor or call Document::SetFont() to change fonts
ts;iwtrm I am not freeing the font data buffer because I strongly suspect we will want to keep it.
You might be able to have arbitrary precision text only documents really easily if you
just re-add the glyphs at a new scale. That might be better than reparenting each individual bezier.
We could add a Document::Finalize() to free memory like the font data
which is used in creating the document but not needed afterwards.
But I want to be able to interactively add text anyway, so there doesn't seem
to be much point at the moment.
Sam Moore [Tue, 12 Aug 2014 06:08:00 +0000 (14:08 +0800)]
Deal with groups in SVG parsing
ParseSVGNode will recursively parse <svg>, <g> and <group> nodes.
Basically just going to try and implement a bunch more of SVG now.
The "transform" attribute would be a useful one to deal with because svg editors (at least, inkscape)
seem to be rather liberal in using it.
I hope the timestamp for this is correct, I ran git commit --amend but
I don't know if that will fix it.
Sam Moore [Fri, 8 Aug 2014 08:08:30 +0000 (16:08 +0800)]
Merge branch 'master' of git://git.ucc.asn.au/ipdf/code
David Gow [Thu, 7 Aug 2014 14:45:02 +0000 (22:45 +0800)]
Yes, we do need to delete m_op somehow.
David Gow [Thu, 7 Aug 2014 14:30:37 +0000 (22:30 +0800)]
"fixed" Rational::ToDouble().
Previously if the numerator or denominator was > the range of a double,
Rational.ToDouble() would return NaN. We now check for this case, and
discard precision accordingly.
David Gow [Thu, 7 Aug 2014 14:05:03 +0000 (22:05 +0800)]
Fix compiling with Arbint/Gmpint rationals
David Gow [Thu, 7 Aug 2014 13:40:33 +0000 (21:40 +0800)]
Fix SVG rendering of glyphs.svg
- Convert Quadratics -> Cubics properly
- Correctly handle relative movements in LineTo.
David Gow [Thu, 7 Aug 2014 13:34:33 +0000 (21:34 +0800)]
The power of truetype font rendering!
Sam Moore [Thu, 7 Aug 2014 03:44:01 +0000 (11:44 +0800)]
Make it work on Cabellera (again)
I keep forgetting I shouldn't use C++11 features
THEY ARE JUST SO CONVENIENT!
:(
Clownfish has C++11 but the open source AMD drivers don't like
geometry shaders and sulix threatened me with dire consequences
of installing fglrx...
Also fix the symlinks in svg-tests
Sam Moore [Thu, 7 Aug 2014 02:46:46 +0000 (10:46 +0800)]
Merge branch 'master' of git.ucc.asn.au:/ipdf/code
Dammit I hate merges
Sam Moore [Thu, 7 Aug 2014 02:42:02 +0000 (10:42 +0800)]
Cubic Beziers and more SVG stuff
Cubic Beziers!
Actually transform the coordinates properly!
Sort of maybe kind of render shape.svg correctly*
* Shading and stroke width will be available in the premium edition, order today for $99.99
David Gow [Wed, 6 Aug 2014 16:09:37 +0000 (00:09 +0800)]
Merge branch 'master' of git.ucc.asn.au:ipdf/code
David Gow [Wed, 6 Aug 2014 16:09:23 +0000 (00:09 +0800)]
Some QuadTree fixes.
Sam Moore [Wed, 6 Aug 2014 10:14:14 +0000 (18:14 +0800)]
Merge branch 'master' of git.ucc.asn.au:/ipdf/code
At least I set my time correctly this time. ho ho.
Sam Moore [Wed, 6 Aug 2014 10:11:40 +0000 (18:11 +0800)]
The view size is not 640x480 and hasn't been for a long time
So taking that plus some other stuff into account, the CPU renderer
for Beziers now uses the same number of lines as the GPU renderer!
Except when the bezier is a straight line. Then it just uses 1.
They still look slightly different. There is probably something wrong
with my Bresenham implementation.
David Gow [Wed, 6 Aug 2014 03:56:03 +0000 (11:56 +0800)]
QuadTree should segfault less frequently.
Still gives incorrect results w/ GPU transform.
David Gow [Tue, 5 Aug 2014 15:10:28 +0000 (23:10 +0800)]
Fix Bézier CPU rendering.
David Gow [Tue, 5 Aug 2014 14:54:25 +0000 (22:54 +0800)]
Fix beziers on GPU.
We can now render an SVG correctly(ish)! Woah!
David Gow [Tue, 5 Aug 2014 14:19:26 +0000 (22:19 +0800)]
Fix a huge bunch of memory corruption bugs in GL
It now is equally broken across Intel and nVidia.
The brokenness can be very pretty, though.
David Gow [Tue, 5 Aug 2014 13:48:59 +0000 (21:48 +0800)]
Don't try to unmap buffers which aren't mapped.
Fixes the GL_INAVLID_OPERATION that snuck in: this would occur
when calling GraphicsBuffer::Resize() on an unmapped, non-invalidated buffer.
Sam Moore [Tue, 5 Aug 2014 18:46:41 +0000 (02:46 +0800)]
Perpetrate SVG on the codebase
Well, parts of it.
We can have black and white SVG only.
I think it's currently buggy.
I figure we should probably be able to actually parse a document format.
And SVG, despite being XML, seems like the least terrible.
Using pugixml for XML parsing and horrible string tokenising because
SVG is not really a DOM language because of the "d" attribute (-_-)
Did I mention it was the least terrible?
Also, there seem to be lots and lots of bugs with things,
including Quadtree rendering of Beziers and actually just GPU rendering of more than one
Bezier in general.
Also I compiled atril without zoom limits but it crashes
due to things not related to precision. So we're beating atril I guess. Woo!
Sam Moore [Mon, 4 Aug 2014 07:52:58 +0000 (15:52 +0800)]
CS Lab machines have met their nemesis
The ongoing adventures of overcomplicated makefile land.
David is dictating this commit message by the way,
PS:
They are i686 and only g++0x from before 0x
Tune in next week for another exciting episode (or installment, you, the
viewer, decide!) of randomly ifdefing things out! Will our heroes
successfully defeat the 32 bit long? Or will they perish in an integer
overflow?
(I think the project is beginning to affect our minds)
Sam Moore [Mon, 4 Aug 2014 11:16:58 +0000 (19:16 +0800)]
Apparently things were done
Sam Moore [Sun, 3 Aug 2014 13:55:56 +0000 (21:55 +0800)]
Remove terrible "pow()" functions
There are many reasons why that was terrible and it finally all came apart
in a segfaultastic display.
We now have Power which only works for integer powers
But we only need those at the moment anyway.
Sam Moore [Sun, 3 Aug 2014 12:50:10 +0000 (20:50 +0800)]
VFPU derpage fixed
In my defence, hex and binary are only 14 digits apart
Sam Moore [Tue, 29 Jul 2014 14:36:53 +0000 (22:36 +0800)]
Add VFPU::Float (but it is broken)
Fails every single realops test.
Also it's stuck at 32 bits still.
Sam Moore [Tue, 29 Jul 2014 14:12:16 +0000 (22:12 +0800)]
Use "Real" in CPU renderer for filled circles
Sam Moore [Fri, 25 Jul 2014 05:03:15 +0000 (13:03 +0800)]
Get it compiling on Cabellera (g++0x not c++11)
... But at what cost?
David Gow [Wed, 23 Jul 2014 04:50:48 +0000 (12:50 +0800)]
More QuadTree code.
David Gow [Wed, 16 Jul 2014 07:40:29 +0000 (15:40 +0800)]
Fix some quadtree rendering bugs.
David Gow [Wed, 16 Jul 2014 06:48:11 +0000 (14:48 +0800)]
Quadtree Rendering for CPU transorm+render
David Gow [Tue, 15 Jul 2014 13:26:52 +0000 (21:26 +0800)]
QuadTree Rendering with GPU coord transform.
David Gow [Tue, 15 Jul 2014 13:10:05 +0000 (21:10 +0800)]
We should compile even if REAL is not 5
David Gow [Mon, 14 Jul 2014 15:12:56 +0000 (23:12 +0800)]
Actually add the Quadtree coordinate code
David Gow [Mon, 14 Jul 2014 01:24:00 +0000 (09:24 +0800)]
Quadtree transforms
David Gow [Mon, 7 Jul 2014 16:02:11 +0000 (00:02 +0800)]
Merge branch 'master' of git.ucc.asn.au:ipdf/code
David Gow [Mon, 7 Jul 2014 16:01:55 +0000 (00:01 +0800)]
Quadtrees! (Almost)
Sam Moore [Mon, 7 Jul 2014 08:46:12 +0000 (16:46 +0800)]
Change Rational<Arbint> -> Rational<Gmpint>
Works better (not surprising). Can change back @real.h:52
Sam Moore [Mon, 7 Jul 2014 08:19:50 +0000 (16:19 +0800)]
Now with GNU MultiPrecision (GMP) integers
gmpint.h is (in theory) mostly inline and shouldn't add much overhead
and was simpler than trying to understand the C++ "binding".
The Str() function is kind of terrible but that can't be helped.
Also fixed bug in realops tester (even the testers have bugs...)
And removed asm tester because the asm function is gone.
The bezier testers now don't compile, I don't think we need them anymore.
David Gow [Mon, 7 Jul 2014 05:15:59 +0000 (13:15 +0800)]
Merge branch 'master' of git.ucc.asn.au:ipdf/code
David Gow [Mon, 7 Jul 2014 05:14:23 +0000 (13:14 +0800)]
Zooming is now sligtly less slow.
Sam Moore [Mon, 7 Jul 2014 03:48:36 +0000 (11:48 +0800)]
C++11 lambdas - are they really worth it?
David Gow [Mon, 7 Jul 2014 03:10:59 +0000 (11:10 +0800)]
Divide some numbers by 5.
David Gow [Mon, 7 Jul 2014 02:57:20 +0000 (10:57 +0800)]
Fix GPU rendering a bit. Will probably break >1 ob
Sam Moore [Mon, 7 Jul 2014 01:53:15 +0000 (09:53 +0800)]
Merge branch 'master' of git.ucc.asn.au:/ipdf/code
We both fixed bugs.
David Gow [Mon, 7 Jul 2014 01:49:48 +0000 (09:49 +0800)]
Clear the carry/borrow flag before add/sub
Sam Moore [Mon, 7 Jul 2014 01:49:20 +0000 (09:49 +0800)]
Arbint subtraction/addition deal with borrow/carry correctly, maybe
Eventually they will be right.
This still doesn't fix the wierd bezier bug or the growing digits really fast (exponential?). I suspect the former is related
to pow(Rational<Arbint>, Rational<Arbint>) and the latter probably makes sense if you do the theory (considering how fast Rational<int64_t> overflowed).
Sam Moore [Mon, 7 Jul 2014 01:17:12 +0000 (09:17 +0800)]
Arbint subtraction should work* now
Yes I was being clever and resizing if sub.m_digits.size() > this->m_digits.size()
But I forgot about when this->m_digits.size() > sub.m_digits.size()
Passes tests/realops.test now!
On the other hand, CPU rendering of Beziers doesn't work anymore.
I think it's just drawing two lines instead of lots of them.
Sam Moore [Sun, 6 Jul 2014 14:41:19 +0000 (22:41 +0800)]
More debugging, harder realops test
David Gow [Sun, 6 Jul 2014 14:31:09 +0000 (22:31 +0800)]
Maybe this is more correct. realops likes it.
David Gow [Sun, 6 Jul 2014 14:23:57 +0000 (22:23 +0800)]
digit_t is now unsigned, asm division for 1 digit
We now do the "two's complement" in SubBasic by hand. It is maybe even
correct.
David Gow [Sun, 6 Jul 2014 13:51:10 +0000 (21:51 +0800)]
Rational<Arbint> now passes realops.test
Sam Moore [Sun, 6 Jul 2014 12:30:40 +0000 (20:30 +0800)]
Arbint now does sign in division correctly
The tester still sometimes picks up a fith Rational<Arbint> /= operation though.
Sam Moore [Sun, 6 Jul 2014 12:17:09 +0000 (20:17 +0800)]
More testing particularly of negatives
Sam Moore [Sun, 6 Jul 2014 11:45:52 +0000 (19:45 +0800)]
Merge branch 'master' of git.ucc.asn.au:/ipdf/code
Dammit I forgot to `git stash; git pull; git stash apply`
Sam Moore [Sun, 6 Jul 2014 11:44:50 +0000 (19:44 +0800)]
Improved "realops" tester
And there are signs of serious problems in Arbint too!
Sam Moore [Sun, 6 Jul 2014 10:19:34 +0000 (18:19 +0800)]
Slightly less memory errors
Using more std::vector and less memcpy/memset etc.
Still seems to have issues but not segfaulting as much.
Fixed m_sign missing in = operator
David Gow [Sun, 6 Jul 2014 09:50:49 +0000 (17:50 +0800)]
Fix a warning/compile error.
Sam Moore [Sun, 6 Jul 2014 09:32:28 +0000 (17:32 +0800)]
Horribly unreliable Arbint's and Rational<Arbint>'s
Changes from before: Arbint's use a division algorithm based on bitshifting.
So, you might get a random segfault (if you scroll you will definitely get a random segfault)
and pretty much every single operation with Rational<Arbints> gives you an accuracy warning...
And yet somehow I can render a Bezier. Really slowly.
David Gow [Sun, 6 Jul 2014 08:30:39 +0000 (16:30 +0800)]
Some initial QuadTree goodness.
David Gow [Sun, 6 Jul 2014 06:17:33 +0000 (14:17 +0800)]
Render object range on the CPU
David Gow [Sun, 6 Jul 2014 05:41:16 +0000 (13:41 +0800)]
Render part of a document (incorrectly) on the GPU
In order to get QuadTrees working, we're going to need to
render small "parts" of a document individually. The way this works
is that, when calling RenderObjectsOnGPU, we now pass a range of
object IDs. The ObjectRenderer will then find (in O(N) time, sadly)
the range of indices needed for that object type and then render those.
Béziers, and other objects which rely on the ObjectID on the GPU being
correct might be broken by this (in some cases), though if so it shouldn't
be too hard to fix by passing an offset in as a uniform.
David Gow [Sun, 6 Jul 2014 01:46:52 +0000 (09:46 +0800)]
now with fewer midnight-isms
David Gow [Sat, 5 Jul 2014 16:32:16 +0000 (00:32 +0800)]
This might help: divide an arbint by a uint64
Sam Moore [Sat, 5 Jul 2014 10:05:46 +0000 (18:05 +0800)]
Add assembly sources to git
Sam Moore [Sat, 5 Jul 2014 09:33:39 +0000 (17:33 +0800)]
Division less buggy, still slow
Ok I need to put more thought into this. Or just look it up.
Sam Moore [Sat, 5 Jul 2014 07:52:38 +0000 (15:52 +0800)]
It compiles... and runs with FPS of zero
Well I suppose this shouldn't have been totally unexpected...
Sam Moore [Sat, 5 Jul 2014 07:31:02 +0000 (15:31 +0800)]
Arbint class implemented
Seems to not explode, at least, when it only has one digit...
Sam Moore [Sat, 5 Jul 2014 05:56:01 +0000 (13:56 +0800)]
Inner step of multiplication in x64 assembly
Just does the multiplication of the array by one digit, taking into account overflows.
I hope. It's kind of difficult to test.
What I need is a VM with equivelant instruction set but magically uses decimals instead of binary 64 bit, so I can test with numbers
that my feeble human brain understands directly...
Sam Moore [Sat, 5 Jul 2014 04:44:48 +0000 (12:44 +0800)]
Arbint class with += and -= operators
Using x64 assembly routines for addition and subtraction loops,
but C++ for memory management through std::vector
Dealing with the sign is a bit annoying.
(Get it?)
David Gow [Fri, 4 Jul 2014 13:47:33 +0000 (21:47 +0800)]
Use the lea instruction to reduce number of "inc"s
Sam Moore [Fri, 4 Jul 2014 13:20:33 +0000 (21:20 +0800)]
More moronic bugs
So that P/-Q simplifies to -P/Q, -P/-Q simplifies to P/Q, properly this time
Sam Moore [Fri, 4 Jul 2014 13:08:35 +0000 (21:08 +0800)]
Arbitrary integer addition in x64 assembly
Who needs portability?
Also yes I could probably just use a library but that seems like cheating.
Sam Moore [Fri, 4 Jul 2014 06:05:44 +0000 (14:05 +0800)]
Maybe don't use all of the lines. Or maybe do.
The CPU version. CPU rendering still looks slightly different to GPU.
Replicates behaviour in
54798ed9050d0742c6cdab067fad0cc364b1d6b2
Also actually use the right +/- operators for Rational.
Oh and compile as rational by default because we like things to explode right?
Sam Moore [Fri, 4 Jul 2014 05:09:47 +0000 (13:09 +0800)]
Moronic bug identified, also Backtrace is a thing now
Copy/Paste bug @rational.h:123
At least division and addition both involve maths right?
Sam Moore [Mon, 30 Jun 2014 04:29:14 +0000 (12:29 +0800)]
Rational representation
Buggy, partly due to integer overflows, partly due to moronic bugs that have yet to be determined.
David Gow [Mon, 30 Jun 2014 04:26:52 +0000 (12:26 +0800)]
Maybe don't use all of the lines. Or maybe do.
David Gow [Thu, 19 Jun 2014 06:20:15 +0000 (14:20 +0800)]
Fix the missing bit of GPU béziers.
Off by one!
David Gow [Wed, 18 Jun 2014 15:36:27 +0000 (23:36 +0800)]
Béziers on the GPU.
So this was a terrible thing in many ways.
What we're doing:
- Converting all of the coefficients to floats (+ doing a bit of
preprocessing) and uploading the the GPU.
- Uploading the data_indices array from the document to the GPU.
- Using the vertex ids in the IBO when rendering béziers to get
the object id, then looking up the data_indices array (as a texture)
to find which bézier coefficients to use, then reading the bézier
coefficients from another buffer texture and finally having the
geometry shader generate 100 lines much as the CPU one does.
We're using buffer textures to access these things because they don't
have fixed sizes (and can get big), so we can't use uniform buffers and
because shader storage buffer objects need OpenGL 4.3, which only graphics
cards manufactured in the last 45 seconds actually support.
Sam Moore [Wed, 18 Jun 2014 09:19:40 +0000 (17:19 +0800)]
The Béziers are quadratic not cubic...
I can maths
Sam Moore [Wed, 18 Jun 2014 08:41:40 +0000 (16:41 +0800)]
Béziers
It's hard to type the ́e so I will just call them Beziers from now.
New struct represents a cubic bezier, can be evaluated. The Objects struct contains a vector of beziers, and a vector of indices for each object.
If an ObjectType is BEZIER than the index can be used to look up the bezier control points. Control points are relative to the bounding rectangle;
so we can reuse the same curves (eg: For fonts).
Rendering happens on CPU only, sub divide and use Bresenham lines.
Bresenham lines are not quite optimal but I eventually gave up.
So we don't have a "line" type, but you can make one by creating a Bezier where x1,y1 == x0,y0
They look kind of wobbly.
Save/Load not tested. It might break. But it will have to be pretty heavily rewritten soon anyway.
Sam Moore [Tue, 17 Jun 2014 09:26:46 +0000 (17:26 +0800)]
Performance graphs!
Amazeballs
Sam Moore [Tue, 17 Jun 2014 09:25:47 +0000 (17:25 +0800)]
Python script for plotting data using Gnuplot
Sam Moore [Tue, 17 Jun 2014 03:45:11 +0000 (11:45 +0800)]
Bugfixes for CPU rendering
Fix segfault caused by RectOutlineRenderer not properly checking bounds on pixel array.
Fix positioning of RectOutline sides in other locations when they were off the screen.
When you zoom in too far, an integer overflow will occur and the CPU rendered objects disappear.
This occured at widths of about 1e-7 (for our test pattern). Improved for now by int -> int64_t
Later need to replace everything except the actual array access with Real's I think. Then make Real's arbitrary precision. Done.
There is a slight size difference between CPU rendered and GPU rendered objects; not sure what the source of this is. Blame rounding.
GPU sometimes leaves off the corner pixels of the rectangles by the way.
David Gow [Tue, 17 Jun 2014 02:14:44 +0000 (10:14 +0800)]
Fix RenderPixels, CPU rendering "works"
Sam Moore [Mon, 16 Jun 2014 17:01:55 +0000 (01:01 +0800)]
Implemented CPU rendering for current ObjectTypes
RECT_FILLED (easy), RECT_OUTLINE (ok I need to maths), CIRCLE_FILLED (oh my god how do I maths)
Screen::RenderPixels is FITH but can see the correct(ish) output in "cpu_rendering_last_frame.bmp"
TODO:
- Fix Screen::RenderPixels
- Fix reading a BMP from the screen (so we can do "gpu_rendering_last_frame.bmp" as well)
- Put Beziers in
- Implement infinite precision document format
- Profit
UCC git Repository :: git.ucc.asn.au