X-Git-Url: https://git.ucc.asn.au/?p=ipdf%2Fdocuments.git;a=blobdiff_plain;f=irc%2F%23ipdf.log;h=ddae826a40214702772bc2181de90090d71db364;hp=c8c17c93ac4160223f5f0864c18104ac0dc633d1;hb=0744a3cd8d1a772c1948a0412e7aef914b1ed50a;hpb=b63206e3974de26097a2c9f0e1dedeec06ea66fb diff --git a/irc/#ipdf.log b/irc/#ipdf.log index c8c17c9..ddae826 100644 --- a/irc/#ipdf.log +++ b/irc/#ipdf.log @@ -4148,3 +4148,83 @@ 23:07 < matches> 8 hours in the future 23:07 < matches> I really should fix my system clock 23:07 < matches> One of these days... +--- Day changed Mon Sep 01 2014 +17:05 < matches> The wobbly lines on things are irritating me +17:10 < matches> There doesn't seem to be anything wrong with Bresenham, which means the actual line endpoints are wrong +17:11 < matches> The GPU does everything from floats and magically they go to the right spot in the buffer +17:11 < matches> The CPU has to calculate integer pixel coordinates +17:16 < matches> I need a magnifier I can't see the pixels that are in the wrong spot +17:16 < matches> I know they are there +17:21 < matches> ... ok maybe the Bresen Ham was a little past its use by date +19:48 < matches> The more I try and get these lines to not look dumb, the more convinced I become that glDrawLines is doing something fancy +19:56 < matches> You end up with wiggles in the line because the end points round to a different pixel to what you end up at by drawing the line +19:57 < matches> If you make sure you start from where the last line ended, you still get a bend because of the left over error from the last line +19:58 < matches> ... +19:58 < matches> Drawing a single line when you know the Bezier is actually a single line is probably going to be less rage inducing than trying to fix this +21:01 < matches> The Beziers are now classified according to Loop and Blinn +21:01 < matches> Well +21:01 < matches> Maybe +21:01 < matches> It at least knows what lines are +21:01 < matches> ... +21:02 < matches> Ok all the ttf beziers are SERPENTINE and LOOP so that's probably wrong +21:43 < matches> Ah, floating point precision strikes again +21:43 < matches> That's kind of annoying +21:47 < matches> But I suppose it's relevant +21:47 < matches> Unless I'm totally screwing something up +21:48 * matches adds in arbitrary fabs(x) < 1e-6 checks +21:58 < matches> On the other hand, if you use DeCasteljau and stop the sub dividing whenever you get to something that classifies as a line, it's actually pretty cool +21:59 < matches> But if you zoom in too far it starts to get classifications totally wrong +22:02 < matches> Yeah I have an abstract due in 2 weeks +22:02 < matches> so screwed +--- Day changed Tue Sep 02 2014 +13:42 < matches> Ok, let's not use floating point values for colours +13:42 < matches> Baad +13:43 < matches> Bad bad +13:43 < matches> Bad sheep +13:43 < matches> The project isn't about precision of representable colours +13:44 < matches> So I'm perfectly OK with using uint8 for colour components +18:53 < matches> Is it too late to change the aim of the project to "render svg-tests/fox.svg but without antialiasing" +18:54 < matches> "Or using the GPU" +18:55 < matches> Well, I understand why shading doesn't usually use flood fill now anyway +18:55 < matches> But I still kind of think flood fill is better at high resolutions +18:56 < matches> Not parallelisable I guess +18:56 < matches> ... Or is it +18:57 < matches> I was going to try and do arbitrary precision stuff but it seems we can no longer compile unless Real == double or float +--- Day changed Wed Sep 03 2014 +17:26 < matches> It would seem Mr Munroe has beaten us... +17:28 < matches> In Javascript +17:28 < matches> We should die of shame +17:29 < matches> Hahaha +17:29 < matches> "// there is no elegance here. only sleep deprivation and regret" +17:31 < matches> On the bright side, we now have a reason to reference xkcd +17:31 < matches> I guess? +17:59 < sulix> I just saw that, and had planned to use that comment as my next commit message. +--- Day changed Thu Sep 04 2014 +10:59 * sulix sulix also engages panic mode. +11:00 * sulix apparently also needs to engage sleep mode. +11:00 * sulix almost engaged sheep mode by mistake. +11:49 < sulix> How sure are you that SolveCubic works? +18:37 < matches> Well, sure within 1e-4 +19:40 < matches> Rational compiles again +19:41 < matches> It just takes... several minutes... to load "The quick brown fox jumps over the lazy dog" +21:04 < matches> I have a new ingenius plan +21:06 < matches> This will probably not work but hopefully it won't take me too long... +21:06 < matches> Oh dear what am I saying +21:06 < matches> It's going to take a month now +22:24 < matches> I really should be integrating one of those two libraries Rowan suggested into the project +22:24 < matches> As opposed to implementing what I like to call the "Paranoid Number" +22:25 < matches> It starts as a float +22:25 < matches> It checks each operation for an exception, and if it does it adds the operation to a linked list instead +22:25 < matches> After trying to simplify the next elements in the list +22:26 < matches> This is going to be awful +22:26 < matches> But it's been a while since I wrote a good linked list +22:32 < matches> ... I think the last linked list I wrote had a nasty tendency to randomly segfault... +22:32 < matches> Nevertheless we shall forge ahead +23:14 < matches> You know you haven't had enough sleep when you start to terminate lines with ':' instead of ';' +23:14 < matches> I blame python +23:14 < matches> Not that it was valid python syntax either +23:15 < matches> But it's a good scapesnake +23:42 < matches> Oh recursive list based functions +23:42 < matches> How I have missed you +23:42 < matches> void Foo() {if (m_next != NULL) m_next->Foo();} +23:42 < matches> <3