12:39 <@matches> Yes
12:40 <@sulix> drumroll...
12:41 <@matches> I don't think it worked
+12:42 <@matches> Yes I did it manually
+12:42 <@matches> Maybe cron is broken on motsugo
+12:43 <@sulix> We shall find out next time at 12:40, I guess.
+12:43 <@sulix> (Or the next time cron emails errors out, maybe)
+12:52 <@matches> Let the record show that it didn't work because I didn't install the crontab
+--- Day changed Wed Mar 19 2014
+10:59 <@matches> Some guy asked me if he could use the whiteboard, so I let him rub out our timeline
+10:59 <@matches> And all he did was write "hello world"
+10:59 <@matches> >:(
+19:10 <@matches> Testing
+19:25 <@matches> So the IRC commits should have a different author
+19:25 <@matches> So that I don't get a ridiculous number of daily IRC commits
+19:26 <@matches> I could rebase the first three of them but I think that might break things
+19:45 <@matches> Ok, and now it will only commit when there is more than one new line, so we won't get one every day when no one says anything
+19:54 <@matches> Alright, and in theory
+19:54 <@matches> If I spam this some more
+19:54 <@matches> There will be a commit soonish
+19:56 <@matches> Any second...
+19:56 <@matches> Yes
+19:56 <@matches> Now that is sorted out I can attain maximum productivity
+19:56 <@matches> (Sorry)
+--- Log closed Mon Mar 24 01:12:25 2014
+--- Log opened Mon Mar 24 08:40:12 2014
+08:40 -!- Irssi: #ipdf: Total of 2 nicks [1 ops, 0 halfops, 0 voices, 1 normal]
+08:40 -!- Irssi: Join to #ipdf was synced in 3 secs
+13:26 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
+13:27 < matches> Uh oh
+13:29 -!- Netsplit over, joins: @sulix
+13:31 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
+13:32 -!- Netsplit over, joins: @sulix
+13:40 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
+13:40 -!- Netsplit over, joins: @sulix
+16:19 < matches> Well that will make a nice automatic commit
+--- Day changed Tue Mar 25 2014
+21:33 < matches> So, I am pretty much free all day tomorrow
+21:33 < matches> Also Thursday
+21:34 <@sulix> I'm pretty busy Thursday, but I'm free all tomorrow so long as I can get some maths done at some point.
+21:34 -!- mode/#ipdf [+o matches] by sulix
+21:35 <@matches> I'm supervising a test from 2-3pm but that's it
+21:35 <@matches> So, I will try and get to UWA as early as I can
+21:35 <@matches> It might be a good idea to have some kind of start on a code base
+21:35 <@matches> Even though we're supposed to be focusing on a literature review, I don't really like not having any code done yet
+21:36 <@sulix> Yeah. I agree.
+21:36 <@sulix> Code + fixing git stuff + preparing for this "talk" on Friday.
+--- Day changed Wed Mar 26 2014
+11:32 <@matches> I am in the super secret room
+11:36 <@sulix> Okay, I'll head in shortly. Had a small "parents fell for a scam email and entered passwords on dodgy websites" crisis here this morning.
+11:37 <@matches> Oh dear
+11:42 <@matches> The phone is ringing :O
+11:43 <@matches> Phew, it stopped
+22:42 <@matches> I think I have a way to do tests in the Makefile without using cmake
+22:42 <@matches> You can alter a variable for a target
+23:20 <@matches> Well, that ended badly
+23:21 <@matches> With me erasing my own Makefile using make
+23:21 <@matches> :P
+23:24 <@sulix> Better than erasing the source code, I guess.
+23:34 <@matches> This is why we have git
+--- Day changed Thu Mar 27 2014
+00:15 <@sulix> Crazy templated loading and saving!
+00:15 <@sulix> And now for bed!
+00:30 <@matches> Well
+00:30 <@matches> It doesn't break the test
+01:22 <@matches> We now have an arbitrary precision float
+01:22 <@matches> Where in this case arbitrary precision means I have no idea what the precision is but it is very bad
+01:35 <@matches> Ok I think I made a half precision float
+01:35 <@matches> They are quite bad
+01:36 <@matches> Um, I can probably make a graph of it being terrible as my contribution for Friday
+01:36 <@matches> Assuming I've done it right
+--- Day changed Wed Apr 02 2014
+09:41 <@matches> Dammit codejam is coming up again
+09:41 <@matches> There goes productivity
+09:42 <@matches> If you are not busy this afternoon we should do work
+09:42 <@matches> On the project I mean
+09:45 <@matches> Although it is tempting to just practice codejam problems for the next week
+12:44 <@matches> If I work on the project it will help when the inevitable "64 bits is not enough" problem comes up!
+12:45 <@matches> Maybe
+--- Day changed Sun Apr 06 2014
+13:40 <@matches> I get the feeling my part of the project could just be "typedef Real to something from boost"
+14:15 <@matches> I suppose I could talk about FPU and hardware
+--- Day changed Mon Apr 07 2014
+21:42 <@matches> I had a horrible horrible thought... implement a FPU in VHDL and then somehow run all our floating point operations on it :P
+21:42 <@matches> (This is not a good idea at all but it might be fun)
+21:42 <@matches> You know, for some definition of fun
+21:44 <@matches> So my lit review will probably be 1) We need higher precision documents because science (Pixels or Perish) 2) This is how FP works in hardware 3) This is how you can get higher precision in software
+21:45 <@matches> Oh, and 4) Document formats and rendering them (PDF/PostScript etc)
+21:46 <@matches> That is starting to sound suitably ridiculously broad?
+21:46 <@matches> Can always cut things out I guess
+21:47 <@matches> To reflect what we actually end up doing
+22:05 <@sulix> From what Tim was saying, I don't think "too broad" is a possibility.
+22:05 <@sulix> We could be talking about Aztec history and it'd probably not be "too broad."
+22:05 <@sulix> I do need to remember to read "Pixels of Perish," though.
+22:19 <@matches> I'll have a look into VHDL stuff, there seem to be compilers and simulators for linux
+22:20 <@matches> For a minute I was afraid I'd have to use the UWA EE VHDL environment
+22:20 <@matches> Which is like, running a Java program in a Windows XP VM
+22:20 <@matches> I heard you liked simulations of hardware so I simulated some hardware in your simulated hardware
+--- Day changed Tue Apr 08 2014
+10:46 -!- Netsplit arctic.uniirc.com <-> mits.mits.au.uniirc.com, services.uniirc.com, irc.cassa.au.uniirc.com, mussel.ucc.au.uniirc.com quits: @sulix
+10:46 -!- Netsplit over, joins: @sulix
+11:31 <@matches> The "Experiment Running" sign seems to have worked
+11:31 <@matches> Also open source VHDL stuff is less "actually compiles" than I had hoped
+11:32 <@matches> The two I've tried so far seem to generate absolute monstrosities of C or C++ files and then fail to compile and/or link
+--- Day changed Wed Apr 09 2014
+15:27 <@sulix> So I've been hitting my head against my desk for about half an hour trying to work out where some bugs were in some ipdf code I'm writing.
+15:27 <@sulix> Turns out to have mostly been precision issues due to the lack of precision in your Real data type.
+15:28 <@sulix> Switching it to double fixes them all.
+15:32 <@matches> Oh
+15:32 <@matches> Sorry
+15:37 <@sulix> Nah: it's good. It means that precision actually is important!
+15:37 <@sulix> (I was getting a little bit concerned for a while :P)
+15:40 <@matches> Well
+15:40 <@matches> I have rediscovered just how awful VHDL is
+15:41 <@matches> It seems like you can't define anything without typing it three times
+15:42 <@matches> You define an entity
+15:42 <@matches> Then you define a component with identical ports
+15:42 <@matches> Then you tell it to use the entity for that component
+15:42 <@matches> Then you tell it to map the identical ports to the entity ports
+15:42 <@matches> adder_0 : adder port map (a=>a, b=>b, cin=>cin, s=>s, cout=>cout);
+15:44 <@matches> Pretty much all the hardware papers I found talk about using VHDL for things
+15:46 <@matches> Let's see if I can make any sense of this jop-devel thing that appears to be a JVM implemented in VHDL
+15:47 <@matches> Uh oh, .bat files
+15:48 <@matches> This looks ominous
+15:51 <@sulix> The whole swapping out main thing breaks the makefile in a few ways btw.
+15:51 <@sulix> Because none of main.cpp's dependencies are listed.
+15:51 <@matches> Ah
+15:51 <@sulix> So if you change main.h, nothing gets recompiled.
+16:02 <@sulix> Okay, just pushed support for click+drag and zoom in and out in the viewer.
+16:03 <@sulix> (I did change the default precision to single, rather than half, as zoom out was totally broken with half-precision)
+16:05 <@matches> The half precision implementation is broken itself anyway
+16:07 <@matches> Hmm
+16:07 <@matches> I can't seem to compile anymore
+16:07 <@matches> Hang on
+16:07 <@matches> That would be because `uname -i` reports "unknown"
+16:12 <@matches> I have made unknown default to x86_64 :S
+16:13 <@matches> I can see the precision issues! Good work
+16:14 <@matches> These lecture notes seem useful: http://www.cs.berkeley.edu/~demmel/cs267/lecture21/lecture21.html
+16:14 <@matches> Lecture notes > Blog post in terms of suitable reference?
+16:16 <@sulix> It's got fortran in it, it must be suitably acedemic.
+16:18 <@matches> Haha
+16:18 <@matches> The VHDL compiler I am experimenting with uses Ada
+16:18 <@sulix> I'm getting my fill of new languages by trying out some c++11 features.
+16:20 <@sulix> I think I broak realtofloat by changing things to be single precision by default.
+16:22 <@sulix> (Hopefully fixed)
+16:49 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
+16:49 -!- Netsplit over, joins: @sulix
+16:54 <@matches> What's with the netsplits
+16:55 <@matches> You're on mussel? I'm on mantis? They are VMs on the same host?
+16:55 <@matches> I don't know what this uniirc nonsense is
+16:56 <@matches> What is "arctic"
+16:56 -!- matches changed the topic of #ipdf to: Happy Bannana Netsplit
+17:33 <@matches> Well I compiled the VHDL FPU
+17:33 <@matches> It seems to work quite well
+17:33 <@matches> Except for the part where it never actually finishes an operation
+17:34 <@matches> One of the virtual transistors must have overheated
+17:43 <@matches> Oops it might help to actually give it a valid operation
+18:27 <@matches> Alright, so I'm going to experiment with getting our Real operations to run on the virtual FPU
+18:28 <@matches> Then I can look into both hardware and software ways of getting arbitrary precision.
+18:30 <@matches> VHDL appears to have text I/O so I could make everything read and write from pipes, but this seems like a terrible idea
+18:30 <@matches> On the other hand the compiler is using Ada
+19:21 <@matches> Oh wow
+19:21 <@matches> To open stdout
+19:22 <@matches> You pass it a string "STD_OUTPUT" for the filename
+21:40 <@matches> Ok, I give up trying to link this thing
+21:40 <@matches> fork() and exec() is seeming more and more elegant
+22:11 <@matches> Nooo, buffering
+22:11 <@matches> Ok, screw this
+--- Day changed Thu Apr 10 2014
+00:00 <@matches> Note: Actually exec'ing the program instead of just going straight to "exit(EXIT_FAILURE)" is generally important
+00:00 <@matches> Wall of text commit message incoming
+00:01 <@matches> Horribly inefficient interface to virtual FPU sort of implemented
+00:02 <@matches> I would have made it based on binary read/write rather than hex strings but I could not work out how to do that in VHDL
+00:08 <@matches> I still can't believe what I have just done, it seems ludicrous
+00:08 <@matches> Using an entire executable and stdio operations
+00:08 <@matches> To do a floating point addition
+00:10 <@matches> You should see how much is involved in compiling the VHDL FPU...
+00:11 <@matches> I'm very pleased that it actually compiled from the version in jop's github without much effort, but still
+00:11 <@matches> It's like 30 object files
+00:11 <@matches> This is why it isn't in the code repo
+00:19 <@matches> Whoops, there are some blatantly wrong comments in vfpu.cpp
+00:19 <@matches> Oh well
+--- Day changed Fri Apr 11 2014
+13:38 <@matches> Warning! I am about to make a ipdf/vfpu repo
+13:43 <@matches> You know what's really cool
+13:43 <@matches> You can run it as `vfpu --vcd=output.vcd`
+13:43 <@matches> And it will create a gtkwave file as it runs showing all the operations
+13:44 <@matches> You only get the simulated time from the point of view of the device
+13:44 <@matches> Which is probably useful
+13:46 <@matches> Or it would be if I wanted to compare different devices
+13:47 <@matches> To do that I need to actually make different devices...
+17:12 <@matches> Would you prefer seperate repos for the individual reports or just sub directories in the documents repo?
+17:12 <@matches> I can't decide
+17:12 <@matches> On the one hand 5+ repos is getting a bit out of hand
+17:12 <@matches> On the other hand they are individual work
+17:24 <@matches> Individual seems best
+20:31 <@matches> Hmm
+20:31 <@matches> The sqrt op in the fpu appears to have been commented out
+20:31 <@matches> Also despite having constants for the sizes of things they have just used magic numbers everywhere
+20:34 <@matches> I need an IRC script to prevent myself from saying stuff unless someone else has said things, or this channel will just be me ranting
+--- Day changed Mon Apr 14 2014
+13:42 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
+13:43 -!- Netsplit over, joins: @sulix
+14:42 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
+14:43 -!- Netsplit over, joins: @sulix
+18:32 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
+18:32 -!- Netsplit over, joins: @sulix
+18:34 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
+18:35 -!- Netsplit over, joins: @sulix
+18:36 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
+18:38 -!- Netsplit over, joins: @sulix
+18:40 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
+18:41 -!- Netsplit over, joins: @sulix
+18:41 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
+18:43 -!- Netsplit over, joins: @sulix
+18:45 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
+18:45 -!- Netsplit over, joins: @sulix
+18:46 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
+18:47 -!- Netsplit over, joins: @sulix
+18:54 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
+18:56 -!- Netsplit over, joins: @sulix
+18:59 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
+19:00 -!- Netsplit over, joins: @sulix
+19:03 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
+19:04 -!- Netsplit over, joins: @sulix
+19:07 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
+19:08 -!- Netsplit over, joins: @sulix
+19:10 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
+19:10 -!- Netsplit over, joins: @sulix
+19:13 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
+19:13 -!- Netsplit over, joins: @sulix
+19:15 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
+19:15 -!- Netsplit over, joins: @sulix
+19:17 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
+19:18 -!- Netsplit over, joins: @sulix
+19:21 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
+19:22 -!- Netsplit over, joins: @sulix
+19:23 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
+19:23 -!- Netsplit over, joins: @sulix
+19:26 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
+19:26 -!- Netsplit over, joins: @sulix
+19:27 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
+19:29 -!- Netsplit over, joins: @sulix
+19:30 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
+19:31 -!- Netsplit over, joins: @sulix
+19:32 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
+19:35 -!- ServerMode/#ipdf [+o sulix] by mussel.ucc.au.uniirc.com
+19:40 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
+19:42 -!- Netsplit over, joins: @sulix
+19:44 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
+19:48 -!- ServerMode/#ipdf [+o sulix] by mussel.ucc.au.uniirc.com
+19:54 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
+19:54 -!- Netsplit over, joins: @sulix
+19:54 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
+19:54 -!- Netsplit over, joins: @sulix
+19:55 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
+19:56 -!- You're now known as 13VAAAAGJ
+19:56 -!- Netsplit over, joins: @sulix
+19:57 <@13VAAAAGJ> Why am I now known as 13VAAAAGJ
+19:57 <@13VAAAAGJ> WHAT THE FUCK IS GOING ON
+19:57 <@13VAAAAGJ> ARE WE UNDER ATTACK
+19:57 <@13VAAAAGJ> Oh crap this is #ipdf
+19:57 <@13VAAAAGJ> Um, disregard this bit of the totally project related conversation
+19:57 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
+19:57 <@13VAAAAGJ> I'd edit the commit script to censor the swear words, but effort
+19:57 <@13VAAAAGJ> Oh dear
+19:57 -!- Netsplit over, joins: @sulix
+19:57 <@13VAAAAGJ> Hello
+19:58 <@13VAAAAGJ> I think mantis might be dying?
+19:59 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
+20:00 -!- Netsplit over, joins: @sulix
+20:01 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
+20:01 -!- Netsplit over, joins: @sulix
+20:04 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
+20:04 -!- Netsplit over, joins: @sulix
+20:05 <@13VAAAAGJ> Sigh
+20:07 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
+20:07 -!- Netsplit over, joins: @sulix
+20:08 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
+20:08 -!- Netsplit over, joins: @sulix
+20:08 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
+20:09 -!- Netsplit over, joins: @sulix
+20:09 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
+20:10 -!- Netsplit over, joins: @sulix
+--- Log closed Mon Apr 14 20:11:29 2014
+--- Log opened Mon Apr 14 20:18:05 2014
+20:18 -!- Irssi: #ipdf: Total of 2 nicks [1 ops, 0 halfops, 0 voices, 1 normal]
+20:18 -!- Irssi: Join to #ipdf was synced in 0 secs
+22:04 < matches> Ergh
+22:06 < matches> http://szmoore.net/ghdl.bug
+22:06 < matches> Pretty
+22:10 < matches> Looks like we'll be sticking with ASCII input files for the FPU
+--- Log closed Mon Apr 14 22:29:33 2014
+--- Log opened Mon Apr 14 22:44:34 2014
+22:44 -!- Irssi: #ipdf: Total of 1 nicks [1 ops, 0 halfops, 0 voices, 0 normal]
+22:44 -!- Irssi: Join to #ipdf was synced in 12 secs
+22:53 <@matches> Someone's VPS was compromised and killing our network
+22:53 <@matches> For reference
+22:53 <@matches> It affects this project because
+23:07 <@matches> Argh
+23:07 <@matches> So I thought I was being really clever
+23:07 <@matches> I had files of type "bit" and everything
+23:07 <@matches> Guess how a "bit" is represented...
+23:08 <@matches> It's an ASCII "0" or "1"
+23:09 <@matches> I guess I will just conclude that ASCII strings treated as hex is the only way
+--- Day changed Wed Apr 16 2014
+00:10 <@matches> I'm either about to perpetrate horrible things on your nice View class or give up and go to sleep
+00:28 <@matches> Yeah... the problem is if we want to overlay objects rendered using different precision's over each other
+00:28 <@matches> It leads towards templates
+00:29 <@matches> And templates lead towards fear
+00:29 <@matches> And fear leads towards anger
+00:29 <@matches> And anger leads to hate
+00:29 <@matches> I think
+00:29 <@matches> Saving an image
+00:29 <@matches> Recompiling the program
+00:29 <@matches> Overlaying the image
+00:29 <@matches> Is going to lead to less hate
+00:30 <@matches> Otherwise pretty much every occurance of "Real" needs to be come a template
+00:50 < sulix> So there are a couple of problems with doing that.
+00:51 < sulix> - You'd need some way of storing objects of different precision. Possibly an extra "high-precision bounds" struct.
+00:51 < sulix> - View also uses real for its internal bounds, which is where many of the problems appear.
+00:52 < sulix> (I guess you could have a "high-precision viewport" as well.)
+00:52 < sulix> - The actual upload of graphics data to OpenGL is done as 32-bit floats, no matter the type of real, as that's all OpenGL supports.
+00:53 < sulix> (At some point we'll have to actually do some view transforms on the CPU rather than just passing all of the bounds and viewport straight to OpenGL)
+01:02 <@matches> Yeah I don't want to replace Real with templates
+01:02 <@matches> That'd be horrible
+01:03 <@matches> By the way, the introduction of SDL_Renderer in SDL2 is confusing
+01:05 <@matches> I thought it was replacing Surface with Renderer and Texture
+01:05 <@matches> But Surface seems to still be a thing
+01:13 < sulix> Yeah: basically Surfaces are in CPU memory, textures in GPU memory.
+01:13 <@matches> Right
+01:14 <@matches> And renderers magically put stuff on surfaces/textures
+01:14 < sulix> Yeah.
+01:14 < sulix> So it basically represents the graphics card.
+01:15 < sulix> But if you want to just use OpenGL yourself, you don't need to create a renderer at all.
+01:15 <@matches> Ah, but the plot thickens
+01:15 <@matches> I'm saving the window to a bmp
+01:16 <@matches> Which requires a renderer
+01:16 < sulix> Hmm... I'm not sure if that will work.
+01:16 <@matches> It does
+01:16 <@matches> It seems rather convoluted though to be honest
+01:16 < sulix> (In theory, it shouldn't, but it probably actually does)
+01:16 <@matches> I seem to remember it not being this convoluted in SDL1.2
+01:16 <@matches> -_-
+01:16 <@matches> So the procedure is
+01:17 <@matches> 1. Get a surface associated with the window
+01:17 <@matches> 2. Allocate buffer of unsigned char for the pixels
+01:17 < sulix> Yeah, TBH I prefer SDL1.2's rendering API, but I generally just use OpenGL anyway.
+01:17 <@matches> 3. Get renderer from the window (NB: Don't use SDL_CreateRenderer, only the (undocumented) SDL_GetRenderer works because the Window already has a Renderer because it has been created with an OpenGL flag)...
+01:18 < sulix> In theory we should probably use glReadPixels.
+01:18 <@matches> 4. Use the magical renderer power to put pixels into the pixel array
+01:18 <@matches> 5. Create an RGB surface from the pixel array
+01:18 <@matches> 6. Now you can call SDL_SaveBMP, congratulations
+01:18 <@matches> What's this about a glReadPixels
+01:18 <@matches> I was just about to commit this
+01:19 < sulix> Well, you can use glReadPixels instead of steps 1,3 and 4.
+01:19 < sulix> (This is what SDL is doing behind the scenes)
+01:20 < sulix> Unfortunately, the SDL wiki is still down thanks to heartbleed. :/
+01:20 <@matches> :O
+01:20 <@matches> It was up when I looked at it before
+01:20 <@matches> Throwing python exceptions when I tried the search function though
+01:21 < sulix> Ryan said that it was up, but I'm still getting revoked certificate errors.
+01:22 <@matches> Hmm, I needed to do step 1 in order to know the size of the pixel array in step 2...
+01:23 < sulix> Screen::ViewportWidth(), Screen::ViewportHeight()
+01:26 <@matches> Yeah this is looking a lot shorter than what I had
+01:33 <@matches> It doesn't seem to work though
+01:35 <@matches> I'm getting a segfault
+01:35 <@matches> And of course valgrind automatically exits when it gets more than 1000000 errors from the flgrx driver
+01:38 <@matches> First call to glReadPixels is OK but the bmp is just white, second call segfaults
+01:39 < sulix> Hmm... what's the call?
+01:44 <@matches> Segfault was due to me forgetting about the pixels needing 4 bytes for RGBA
+01:44 <@matches> Still white though
+01:45 < sulix> (That was going to be my guess)
+01:45 <@matches> The advantage of getting the SDL_Surface
+01:45 <@matches> Was that you just pass all the surf->format->format->stuff
+01:45 <@matches> Everywhere
+01:45 <@matches> Also makes it rather verbose
+01:46 < sulix> The white screen might just be an fglrx bug.
+01:46 <@matches> There we go
+01:47 <@matches> No, it helps to remember that the pixels need 4 bytes for RGBA
+01:47 <@matches> I have very selective memory
+01:47 <@matches> I had to remember it for each line individually
+01:47 <@matches> Right I guess it is slightly nicer now
+01:47 <@matches> Although it has a bunch of magical "*4" everywhere
+01:48 <@matches> I'm going to put this on Stack overflow as an alternative to the answer I was originally following
+01:48 < sulix> Well, I'm going to attempt to sleep...
+01:48 <@matches> Thank you for fixing my bug without seeing it :S
+01:49 < sulix> I have far too much experience breaking glReadPixels...
+01:53 <@matches> We need an easy way to compare our document rendering the same thing using a different Real and/or view representation
+01:53 <@matches> Templates would only solve changing the Real and really they probably wouldn't actually solve it
+01:53 <@matches> They'd just create nightmares
+01:53 <@matches> Hmm
+01:55 <@matches> Um
+01:55 <@matches> Just looking at View::Render
+01:55 <@matches> Why is there a seperate loop for each type of object...
+01:56 <@matches> With "continue" statements for the other types in each loop
+01:56 <@matches> Is this so you can just make one call to glBegin and glEnd...
+01:56 <@matches> I am suitable scared
+01:57 <@matches> suitably scared and also suitable scared
+22:05 <@matches> Ok, trying again. This is the sort of thing a template is supposed to be used for... I just seem to always end up suddenly having to make everything all the way back to Document into a template class :S
+22:07 <@matches> blergh
+22:07 <@matches> trying again
+22:07 <@matches> After getting coffee
+22:07 <@matches> I think
+22:30 <@matches> Ok, templates is way too complicated
+22:30 <@matches> I am going to do the following instead:
+22:31 <@matches> 1. Allow a "save this region to bmp" argument
+22:31 <@matches> 2. It reads the specified bmp, saves a new bmp with the current view overlayed in a different colour or something
+22:32 <@matches> 3. Makefile hacks to recompile the program using a different typedef of Real and then do 1. and 2. for them all
+22:32 <@matches> 4. Realise I probably should have used templates
+23:02 <@matches> So, according to my timeline that I haven't looked at since submitting the proposal, I will have done a draft literature review by tomorrow...
+23:02 <@matches> Hah
+--- Day changed Thu Apr 17 2014
+00:26 <@matches> I am not good at OpenGL/SDL
+00:26 <@matches> I am the master of producing a black screen
+00:26 <@matches> Also we have FILLED and OUTLINE the wrong way round still
+14:01 < sulix> Bunch of bugfixes incoming.
+14:01 < sulix> I'm not proud of what I did to glReadPixels, but it works.
+14:02 <@matches> Uh oh
+14:02 <@matches> I just worked it out!
+14:03 <@matches> The dreaded merge begins
+14:03 <@matches> I'm tempted to just delete my changes and merge yours but I should probably do a real merge
+14:04 <@matches> I fixed it (on my machine at least) by: Using GL_BGRA instead of GL_RGBA (should probably detect which one to use from the screen's format)
+14:04 <@matches> And calling glReadBuffers and glPixelStorei before glReadPixels
+14:05 < sulix> glPixelStorei is probably nicer than what I'm doing.
+14:05 < sulix> I tried just giving SDL a negative pitch and a pointer to the bottom-right corner of the buffer, but somehow it didn't like that much.
+14:07 <@matches> You do actually check the byte order which is good
+14:08 <@matches> I worked that out but basically just changed it to match my machine :S
+14:08 < sulix> There are a bunch of endian problems in the load-save code anyway if we want it to run on big-endian machines.
+14:09 < sulix> (Well, big-endian documents don't load with little-endian code and vice-versa)
+14:10 <@matches> http://szmoore.net/ipdf/code/src/screen.cpp
+14:10 <@matches> Is the merge
+14:10 <@matches> Which one is better?
+14:11 < sulix> I think yours will still get the bitmaps upside down?
+14:11 <@matches> Ah yes they do tend to be upside down
+14:12 < sulix> I'm not sure you should need the front buffer stuff anymore with mine, so if you just keep mine (which is doing the flipping), everything should work.
+14:12 <@matches> Woah you fixed the FILLED vs OUTLINE
+14:12 < sulix> I did test overlaying bitmaps and it was fine.
+14:12 <@matches> Good
+14:12 <@matches> Does this seem like a better way to compare approaches than using a template and having View<float> View<double> etc?
+14:13 <@matches> It means recompiling
+14:13 <@matches> But it means a lot less templates
+14:13 <@matches> Pretty much the entire thing has to be templatified that way
+14:13 <@matches> And then there's the issue of what type the document is saving with
+14:13 < sulix> I think, long term, it'd be worth just extending the view to have a "bounds" and a "high_precision_bounds" or something.
+14:14 < sulix> But that is kind-of ugly.
+14:14 <@matches> I think it's probably nicer to just have real.h contain nothing but a typedef
+14:14 <@matches> And just recompile with a different typedef and overlay the images
+14:15 < sulix> Yeah, but there are some artefacts that really show better in motion, so it's probably worth supporting that at some point.
+14:15 <@matches> True
+14:15 <@matches> But including a video in the pdf will be difficult anyway
+14:16 < sulix> (Clearly, we should add embedded videos to ipdf)
+14:16 <@matches> You could also make a movie using ffmpeg
+14:16 <@matches> Haha
+14:16 < sulix> (I've got some OpenGL video playback code somewhere...)
+14:17 <@matches> In fact, if you can output a video you can just overlay two videos
+14:17 < sulix> Oh... my... god!
+14:17 <@matches> I don't know if there's a better way to make a video but I'd just be saving a .bmp every frame and then combine them all with fmpeg
+14:17 < sulix> Nope, that's probably a good way.
+14:18 < sulix> With some MAGIC it wouldn't even be slow.
+14:20 <@matches> Whoops your code isn't giving me a second bmp anymore
+14:20 <@matches> At least, not one that has pixels that aren't white
+14:20 <@matches> Does my glReadBuffer thing work for you?
+14:21 < sulix> Hmm...
+14:21 <@matches> Can fix the upside-downness some other way
+14:21 < sulix> Did you make clean
+14:21 < sulix> Because main.cpp/main.h won't recompile otherwise.
+14:21 < sulix> And I moved the glClear() calls.
+14:22 <@matches> I did make clean
+14:22 < sulix> Which is a less hacky way of solving the problem than reading the front buffer.
+14:23 <@matches> So the problem is that the texture rendered by Screen::RenderBMP isn't in the buffer that glReadPixels reads from?
+14:23 <@matches> (Even though it gets shown on the screen fine)
+14:25 < sulix> Hmm... it works fine here with or without glReadBuffers.
+14:27 < sulix> Try changing it to save the screenshot before calling scr.Present() in main.h
+14:29 <@matches> That works
+14:29 <@matches> But why?
+14:29 < sulix> Because when you call Present(), it allocates a new buffer to render into.
+14:30 <@matches> Right
+14:30 < sulix> This is so that you can start rendering the new frame immediately, rather than having to wait for the window manager to actually re-render the screen.
+14:31 <@matches> I have merged it
+14:33 < sulix> Excellent.
+14:33 < sulix> This is much more fun than literature!
+14:33 <@matches> :S
+14:35 <@matches> It's important
+14:35 <@matches> It's part of the timeline
+14:35 <@matches> Just you know
+14:35 <@matches> It comes after the Literature Review
+14:37 < sulix> Strictly speaking the Lit Review deadline is past, now, isn't it... :/
+14:38 <@matches> Well technically it was never a deadline for me... :P
+14:38 * sulix sighs
+14:38 < sulix> I'm special.
+14:39 <@matches> I need to read that last paper on FPUs more
+14:39 <@matches> It was talking about how there are all these software techniques from the 1960s that can actually be done on the FPU itself
+14:40 <@matches> I'll probably just work on getting our / jop's FPU working for different sized floats instead
+14:40 <@matches> In theory that will teach me how they actually work
+14:40 <@matches> Then I can actually understand the papers
+14:40 < sulix> But can you write about it in a Lit Review?
+14:42 <@matches> Maybe not so much the Lit Review, but it means I can write the Background section that explains how they work
+14:43 <@matches> There's probably some early papers on them that I can reference at the same time if I try hard enough to find them
+14:44 <@matches> The modern papers all have a lot of assumed knowledge
+15:59 <@matches> Instead of reading papers I have progressed towards compiling different types and then overlaying them
+16:02 <@matches> I didn't know you could do such cool things with Makefiles and flags to the compiler
+16:02 <@matches> If people knew more about this maybe we wouldn't have to have python
+16:03 <@matches> I will learn to do all my highlevel programming using Make
+19:48 <@matches> Our Render/Screenshot combo for overlaying bitmaps and $$$ only works the first time it is done
+19:49 <@matches> Or maybe it's RenderBMP that only works once
+19:49 <@matches> Hmm
+19:52 <@matches> I swear the format was BGRA earlier and now it's RGBA
+19:53 <@matches> This can probably get fixed after some Literature Review
+20:09 <@matches> Anyway you can now set the type of Real with `make DEF=-DREAL=X`
+20:09 <@matches> Or `make single` and `make double`
+20:09 <@matches> 0 and 1 respectively
+20:09 <@matches> I tried a little bit too hard to get it working with actual C strings
+21:32 <@matches> Minutes now have less "~*" in them
+21:32 <@matches> Wrong channel
+21:32 <@matches> Very wrong channel
+--- Day changed Mon Apr 21 2014
+12:32 <@matches> Literature Review O'Clock
+12:36 < sulix> I have just returned from my Easter holiday and have some horrible code for you to scream at while I have lunch. :P
+12:43 <@matches> Uh oh
+12:44 <@matches> stb_truetype ?
+12:44 <@matches> DejaVuSansMono.ttf ?!
+12:44 <@matches> Is this going to render a font...
+12:45 <@matches> Woah
+12:47 <@matches> Looks good
+12:48 <@matches> I think I will avoid looking at stb_truetype too closely...
+12:48 <@matches> Too late
+12:48 <@matches> Why are all the implementations in the .h file
+12:48 <@matches> And the .cpp file just has some defines...
+12:48 <@matches> shudder
+12:53 <@matches> I particularly like #define STBTT_assert(...) do {} while(0)
+12:53 < sulix> That's a standard way of doing that. SDL_assert does the same thing.
+12:54 < sulix> It lets you put a semicolon after it or use it in an if() statement without braces, etc, without things breaking horribly.
+12:56 <@matches> But... your assert doesn't actually assert anything?
+12:56 < sulix> That's because you generally only want it enabled in debug builds.
+12:56 <@matches> I guess
+12:57 < sulix> So typically you'd have it as do {} while(0) in release builds, and something like a function call in debug builds.
+12:57 <@matches> So what is this "more code" going to do :P
+12:57 < sulix> Slightly more modern opengl.
+12:58 <@matches> Yeah, that would be a good idea
+12:58 < sulix> In particular, uploading the content of a document to a VBO, and just re-rendering from that when needed.
+12:58 <@matches> Cool
+12:58 < sulix> Jumps from 9 fps -> 37 fps with 1024^2 objects.
+12:59 < sulix> I've been without internet, though, so it's pretty broken in many ways, still.
+12:59 < sulix> Like outline rects don't work.
+12:59 < sulix> And it still uses a bunch of OpenGL 1.0 stuff.
+12:59 < sulix> And for some reason the glPrimitiveRestartIndex() function isn't working.
+13:00 < sulix> Also I need to write shaders at some point, which will be work.
+13:00 <@matches> I just found the best comment in an IEEE email list
+13:00 <@matches> We should totally use it
+13:01 <@matches> "It is too late now to repair the mistakes of the past that are present in millions of installed systems, but it is good to know that careful research before designing hardware can be helpful"
+13:01 < sulix> Oh man, that's basically the thesis in one sentance.
+13:02 <@matches> Dibs!
+13:02 <@matches> Although I doubt anyone will care if we both quote it
+13:03 < sulix> One thing I did discover reading my OpenGL book is that I think we can get OpenGL to use doubles with some shader hackery.
+13:03 <@matches> :O
+13:03 < sulix> Then again, the book was (partly) written by (one of) the authors of fglrx, so take it with the requisite salt.
+13:04 <@matches> Ah, so how many goats were required?
+13:05 < sulix> Just the two, I think.
+13:06 <@matches> This email message seems sort of vaguely relevant? It's the "infamous double rounding problem"
+13:06 < sulix> I take it that you worked out how to swap between CPU and GPU transforms with right-click.
+13:07 <@matches> I read it in the commit message
+13:08 < sulix> I was quite happy with how much nicer things ran with CPU transforms and doubles.
+13:08 <@matches> I think I can see a difference zooming in far enough
+13:08 <@matches> Yeah that's a huge difference
+13:08 <@matches> I had a tester that was going to automatically make images of the difference when you zoomed in really far
+13:09 <@matches> But there were issues with the screen shot / bmp rendering
+13:09 <@matches> Probably the bmp rendering
+13:09 < sulix> .bmp files suck.
+13:10 <@matches> They are nice and simple though?
+13:10 <@matches> At least, the SDL API is nice and simple
+13:10 < sulix> That's more a triumph of SDL than of the .bmp file format.
+13:10 <@matches> After looking through gm6 files with a hex editor to try and extract sprites...
+13:11 <@matches> Well we could always just fwrite the pixel buffer and fread it back
+13:11 <@matches> If you want no one to be able to use our files without compiling our program :P
+13:12 < sulix> I'm personally a fan of LodePNG, but I'm too lazy to hack it in at the moment: http://lodev.org/lodepng/
+13:13 < sulix> I'm probably going to get around to fixing all of the warnings in stb_truetype one day.
+13:13 <@matches> Haha
+13:13 <@matches> What about implementing an Oct-tree?
+13:14 <@matches> So .bmp is just a header and then the raw pixel data? What's disgusting about that? No compression?
+13:16 <@matches> Wait png is also just a header and then an IDAT section
+13:17 <@matches> Oh well you can put lodepng in if you want I guess
+13:17 <@matches> As long as I can open the images in eom
+13:18 <@matches> Ah so PNG is compressed. I missed that
+13:19 <@matches> Meh
+13:19 <@matches> Oh and alpha channel
+13:19 <@matches> Yeah
+13:19 <@matches> I remember that now
+13:20 <@matches> xpaint is the least shitty of the shitty sprite editors in debian, but it only stores RGB because it was designed around bmp and I guess they just hacked on exporting to other formats later
+13:21 <@matches> If you open things with alpha it gets really confused
+13:23 < sulix> You can put alpha in .bmp files, but then they sometimes crash KDE.
+13:26 <@matches> We can just run all our bmp files through image magick
+13:26 <@matches> convert a.bmp a.png
+13:26 <@matches> Done
+13:27 <@matches> Hmm, maybe if I opened the data from the gm6 files as png they would work, I was assuming they were bmps -_-
+13:27 <@matches> Actually gif
+13:27 <@matches> Probably
+13:28 <@matches> Since it has "Save as gif"
+13:28 <@matches> But that is not relevant to this project
+13:33 < sulix> Damn, just discovered that the opengl feature I was using for rectangle outlines is not supported by my laptop's hardware.
+13:34 < sulix> (This explains one of the bugs I've been seeing, but sadly only one)
+13:47 < sulix> Okay, remaining code pushed.
+13:47 < sulix> I am sorry.
+13:53 <@matches> I'm messing around trying to do something evil so I'll merge later
+13:53 <@matches> But you don't seem to call ToggleGPUTransform when there is a right click
+13:54 <@matches> Oh wait, I need to make clean
+13:54 <@matches> Cool
+13:54 <@matches> (So much for our Makefile magically tracking the header files :S)
+13:58 < sulix> It does it for every header file except ones included by main.cpp because of the weird main.cpp swapping stuff.
+13:59 <@matches> That main swapping stuff is amazing
+13:59 <@matches> It is worth it
+13:59 <@matches> Except main.cpp ends up eventually including all the header files
+14:00 <@matches> I think there is an alternative Makefile that just has every single header file in the current directory as a dependency for each .o file
+14:01 <@matches> But I'm normally used to running make clean anyway
+14:22 <@matches> Eh I was going to make a video of the difference between GPU and CPU coord transforms but it's not that great
+14:23 <@matches> Whatever you have done does not look happy
+14:24 < sulix> It takes like 5 minutes to DebugDumpObjects with a million objects, but it works okay* after that.
+14:24 <@matches> Yeah ok
+14:24 < sulix> *well, sort-of.
+14:25 < sulix> If you just want to show off the precision, getting rid of most of those objects is probably the right thing to do.
+14:25 <@matches> Interesting things happen when you zoom out really far
+14:25 <@matches> Do we care about that
+14:25 < sulix> I'm going to go with "no".
+14:26 <@matches> Ah, but the rectangles are not all the same size
+14:26 < sulix> This is a product of rounding to the nearest pixel. They'd be fine with antialiasing.
+14:29 <@matches> I have pushed a single line contribution
+14:29 <@matches> I decided not to bother with all the changes I made to make the video prettier
+14:29 <@matches> Since I can't actually capture my desktop properly anyway
+14:30 <@matches> I suppose I could make it render bmps and ffmpeg them all but that is way too much effort
+14:31 <@matches> So
+14:31 <@matches> Literature Reviews
+14:31 <@matches> They are a thing
+14:38 <@matches> I probably should not reference an email thread
+14:53 <@matches> In other news, I think this jvm FPU doesn't actually implement sqrt
+14:57 <@matches> It always gives 0x0 on sqrt ops
+14:57 <@matches> I certainly hope there isn't a jvm somewhere that just doesn't do square roots
+14:58 <@matches> They probably hacked it into some other part of their project instead of putting it in the FPU
+16:08 <@matches> So fprintf style formatting isn't very clever when it comes to floats vs doubles vs long doubles
+16:11 <@matches> Eg: %lf will work for either floats or doubles and %f will work for either floats or doubles (by truncating) but %llf is the only thing that works for long doubles and it only works for long doubles
+16:12 <@matches> s/truncating/casting whatever
+16:52 <@matches> We can compile with long double
+16:52 <@matches> I suspect this may break things but whatever
+16:52 <@matches> Running calculatepi on motsugo to see how much difference it actually makes...
+17:08 <@matches> Charles Babbage seems like an interesting fellow
+17:09 <@matches> "e sought to prove the
+17:09 <@matches> reality of the devil by drawing with his blood a
+17:09 <@matches> circle on the floor and repeating the Lord’s prayer
+17:09 <@matches> backward"
+17:09 <@matches> The things one does for science
+17:44 <@matches> Reading about Charles Babbage counts as Literature Review...
+17:44 <@matches> Actually I'm trying to find a paper written *by* him
+17:44 <@matches> Since apparently he came up with Floating Point representations
+22:11 <@matches> Found an actual paper talking about floating points on GPUs
+22:12 <@matches> It says they don't conform to IEEE and also the manufacturers don't like to tell people what they do do
+22:12 <@matches> So they wrote a version of Paranoia, which was a test program for computers in the 1980s before IEEE, to work out the characteristics of flops on various GPUs
+22:13 <@matches> This is probably of interest
+22:14 <@matches> So far one of the best papers I have on algorithms in software is actually one talking about implementing those algorithms in hardware instead
+22:15 <@matches> I also have a random obituary to Charles Babbage just because
+22:16 <@matches> Unfortunately UWA directs me to some useless website that just tells me the citation details and doesn't give me a download for any of Babbage's papers
+22:17 <@matches> He has some books but they are mostly about economics
+22:18 <@matches> Would have been nice if he'd written something that says "I have invented floating point" but I guess not
+22:18 <@matches> That's only really of historical interest but it'd be nice
+--- Day changed Tue Apr 22 2014
+01:17 <@matches> Urgh looking at the git diff
+01:17 <@matches> I really have not accomplished much
+01:30 <@matches> Oooh, motsugo finally got to a number of intervals where long double is better than double
+11:56 < sulix> So it turns out that I've broken the open-source GL drivers.
+11:56 < sulix> They don't support one of the features ("primitive restart") we need when in compatibility mode.
+11:56 < sulix> So I guess now I've got to rewrite everything to use OpenGL 3.
+14:47 <@matches> ?
+14:48 <@matches> I should probably look more carefully at what the OpenGL stuff is doing nowdays
+14:49 <@matches> Downgrading to OpenGL 3 sounds drastic
+14:50 <@matches> Wait 3 is the OK one, 4 is the new one
+14:50 <@matches> 1 is the ancient one
+14:52 <@matches> I see pointer arithmetic...
+14:53 <@matches> banana would be furious
+14:53 <@matches> should be using std::super_ptr_unsegfaultable_arith
+14:53 <@matches> (I am not a fan of the smart pointers)
+14:55 <@matches> *indexData = 0xFFFFFFFF; // Primitive restart.
+14:55 <@matches> I do not know what is going on here :S
+14:58 <@matches> Ahh I get it now
+14:58 <@matches> Reading commit messages turns out to be useful
+15:04 <@matches> git blame for view.cpp reveals that I still own the opening braces on some things
+15:05 <@matches> That's about it :P
+15:06 <@matches> I'm going to keep looking at rounding errors and maybe have a better thing than calculating pi
+15:06 <@matches> As a bench mark
+15:07 <@matches> I might look at Paranoia
+15:07 <@matches> Although it was originally in BASIC
+15:07 <@matches> And ~7000 lines
+15:07 <@matches> With almost no whitespace characters
+15:07 <@matches> And totally no indents
+15:08 <@matches> I sometimes get the feeling people used to be smarter than we are now...
+15:08 <@matches> Then I remember that those people are ultimately responsible for the tools we use now
+15:15 < sulix> Speaking of tools we use now, I think I've just got the debug font code to not only randomly corrupt a varible, but also cause valgrind to crash.
+15:18 < sulix> Okay, we need to fix that makefile at some point.
+15:38 <@matches> make clean?
+15:41 <@matches> It's not actually swapping out main.cpp
+15:41 <@matches> It just doesn't have main.o in the link objects and has main in the $(BIN) target and the testers in the tests/% target
+15:42 <@matches> I guess that is swapping out main but MAIN is not being changed
+15:42 <@matches> derp
+15:45 <@matches> I think I fixed it?
+15:45 < sulix> Ah. Well, you've got a merge conflict to look forward to.
+15:45 <@matches> Not if I just NEVER COMMIT IT
+15:46 <@matches> I'm going to call your fix being right and mine being a horrible hack
+15:46 <@matches> Ok I pullsd some changes to graphics stuff, is that it or is there more?
+15:46 < sulix> I haven't fixed it, I've just gone and bu(gg|ff)ered up the font stuff.
+15:47 <@matches> So it's not meant to render unless something changes? But the debug font stuff is changing so it needs to keep rendering?
+15:48 <@matches> I see a lot of "Flushing Debug Font arrays"
+15:48 < sulix> The debug font stuff is separate from the whole view system.
+15:48 <@matches> That makes sense
+15:48 < sulix> It's just trying to fill up a buffer of quads with individual characters in it and then draws them when the buffer gets full.
+15:49 < sulix> One more step on the path of getting rid of all of the OpenGL 1.1 stuff.
+15:50 <@matches> Haha
+15:50 <@matches> git stash seems to think I modified graphicsbuffer.h and screen.h
+15:51 <@matches> git diff seems to think everything is identical
+15:51 <@matches> I'm just going to git reset the things I didn't actually change...
+15:52 < sulix> I do that far too often.
+15:52 <@matches> Oh there is a comment "//test" for testing the Makefile
+15:53 <@matches> And a comment "This isn't the Screen class?" where you copy/pasted the screen class description for the GraphicsBuffer class
+15:53 <@matches> I don't think they need to be preserved
+15:54 < sulix> Yeah, I should have got rid of that screen class bit by now.
+15:55 <@matches> Have a 2 line commit
+15:55 < sulix> The best kind.
+15:55 <@matches> I really need to cut back on the new line creep
+15:56 <@matches> It's like I can't add a line by itself without putting in extra whitespace
+15:57 <@matches> Uh oh we've ran out of coffee here
+15:58 <@matches> I'm slightly scared by how much the graphics code has increased since I last actually understood how it worked...
+15:59 <@matches> Can you change those *vertexData to *(vertexData++) or is that considered even uglier
+16:03 < sulix> I thought of that, but given how much pointer arithmetic debugging I was going to do, I wanted it to be really obvious when the pointer was being incremented.
+16:03 < sulix> The plan is to have a nice AppendFloat() function or similar that will do this eventually.
+16:05 < sulix> Hmm: "Buffer usage warning: Analysis of buffer object 2 (bound to GL_ARRAY_BUFFER_ARB) usage indicates that the GPU is the primary producer and consumer of data for this buffer object. The usage hint supplied with this buffer object, GL_STATIC_DRAW, is inconsistent with this usage pattern. Try using GL_STREAM_COPY_ARB, GL_STATIC_COPY_ARB or GL_DYNAMIC_COPY_ARB instead.
+16:06 < sulix> Thanks nVidia.
+16:06 < sulix> Now if only we were using OpenGL 4.4 which got rid of buffer usage hints entirely.
+16:29 <@matches> Also I think you forgot the naming scheme :P
+16:30 <@matches> vertex_data
+16:31 <@matches> I will go back to pretending to be doing a literature review
+16:32 <@matches> Instead I will probably plot some graphs
+16:48 <@matches> So
+16:48 <@matches> If you look up "Handbook of Floating Point Arithmetic" on google (which lots of things like to reference these days)
+16:48 <@matches> You can download the entire thing
+16:48 <@matches> I was prepared to pay like $20 for it on amazon
+16:49 <@matches> Oh amazon doesn't sell actual books anymore though does it?
+16:49 <@matches> No they do have it
+16:50 <@matches> For $100...
+16:50 <@matches> I think I'll just stick with my free pdf thanks
+16:55 <@matches> "Handbook" being 579 pages...
+17:04 <@matches> I think if a textbook is citing blog posts we can probably get away with it
+17:05 <@matches> Oh my god I love this textbook
+17:05 < sulix> I was watching a conference talk last night when the presenter just said: "this technique is described on this guys blog. Here's a link."
+17:05 <@matches> "Table 1.1 gives the results obtained by compiling Program 1.1 and running on a Pentium4, using the GNU Compiler Collection and the Linux system"
+17:06 <@matches> [Complete C code for Program 1.1 follows]
+17:06 <@matches> None of this "Pseudo code" crap
+17:07 < sulix> Clearly we should get an extra 10% for every line of pointer arithmetic in our theses.
+17:07 <@matches> There'
+17:07 <@matches> s a problem here
+17:07 <@matches> How do I not make the entire literature review just paraphrased from this one text book
+17:08 <@matches> Mr Gullible and the Chaotic Bank Society!
+17:08 <@matches> It has stories!
+17:08 <@matches> Parents should read this textbook to their children
+17:09 < sulix> I'm pretty certain I know someone with a data structures and algorithms picture book...
+17:09 <@matches> That reminds me of a children's book I wrote about multithreading
+17:10 <@matches> I should probably scan it one day
+17:10 < sulix> Did it begin "Once upa timeon...
+17:10 <@matches> I think it did actually
+17:10 <@matches> Once upon a time there was a process who had a lot of work to do...
+17:11 <@matches> "I should probably scan it one day" - Why not TODAY!
+17:11 * matches goes searching
+17:16 <@matches> It is no where to be found
+17:16 <@matches> I distinctly remember going to throw it out and deciding not to, but not where it actually went
+17:27 <@matches> So maybe compiling a bunch of HFPA's examples using our Real type is a good way to make benchmarks
+17:27 <@matches> I don't know
+17:27 <@matches> My part of the project seems to move further and further away from the document formats thing
+17:27 <@matches> Maybe I'll try and compile the GPU Paranoia
+17:28 <@matches> Hah
+17:34 <@matches> It seems like whatever Mathematica does is what we should do
+17:35 <@matches> I wonder if wolfram is open about how Mathematica actually works
+17:35 <@matches> I don't think they are
+17:35 <@matches> The CQM lecturer for physics found a bug in Mathematica's number representation once that she showed us
+17:35 <@matches> Apparently she reported it years ago and it's still there
+17:36 <@matches> This segued nicely into why we should learn fortran
+--- Day changed Wed Apr 23 2014
+14:00 <@matches> IEEE's float encoding is inconvenient
+14:01 <@matches> The mantissa is like, reversed
+14:01 <@matches> b_{23-i} * 2^{-i}
+14:19 <@matches> And the implicit extra 1 except when it isn't is a pain in the ass as well
+14:19 <@matches> It's like
+14:19 <@matches> I can't just copy the right bits I have to think
+14:19 <@matches> What is this
+14:19 <@matches> Mental effort
+14:19 <@matches> Blargh
+14:20 <@matches> I should have just stuck with the 8 bit floats with their 2 sign bits
+14:20 <@matches> The hydra float
+15:17 <@matches> Wow you get really different representations with an IEEE encoding of the bits
+15:17 <@matches> ...
+15:17 <@matches> I think I liked just treating the two parts as integers in the order they were stored better
+15:18 <@matches> I have to call pow(3) and a floating point division for every '1' in the mantissa to get it to agree with IEEE
+15:19 <@matches> Unless I'm missing some obvious trick
+15:20 <@matches> But in IEEE the mantissa is not an integer
+15:37 <@matches> Ooookkk
+15:38 <@matches> You're precision doesn't disappear as fast when you do it that way
+15:38 <@matches> Your
+15:38 <@matches> Whatever
+--- Day changed Thu Apr 24 2014
+14:40 -!- You're now known as notmatches
+14:40 -!- You're now known as matches
+14:41 <@matches> Ok, less spammy channel time
+14:41 -!- mode/#ipdf [+b m:matches!*@*] by matches
+14:41 <@matches> Spam
+14:41 <@matches> Dammit
+14:42 -!- mode/#ipdf [-o matches] by matches
+14:42 < matches> Spam
+14:43 < matches> Yay
+14:43 < matches> ... this will all appear in the next git commit won't it -_-
+14:52 -!- You're now known as notmatches
+14:52 -!- You're now known as matches
+--- Day changed Sat Apr 26 2014
+00:45 -!- mode/#ipdf [+o matches] by OperServ
+00:46 <@matches> Incoming "at least it is self consistent in its wrongness" floating point conversion
+00:48 -!- mode/#ipdf [-o matches] by matches
+00:48 < matches> Still can't talk
+00:48 < matches> Excellent
+--- Day changed Sun Apr 27 2014
+17:10 < sulix> I finally got ipdf working on my laptop again by porting everything to OpenGL 3.1.
+17:10 < sulix> I'm so sorry about how ugly the code now is, by the way.
+18:04 -!- mode/#ipdf [+o matches] by OperServ
+18:05 < Pommers> You know what a really good feature for a PDF reader would be? The ability to have it completely borderless without menus, so you just see the page!
+18:06 <@matches> Wat
+18:06 <@matches> Well we've got that
+18:06 <@matches> We just can't read pdfs
+18:07 <@matches> Did you get much done not going to the cleanup?
+18:07 <@matches> I managed to transfer some dust from one location to another location, and then the wind blew it back in my face
+18:08 <@matches> Then I looked at Frames' proposal and despaired at how much it is actually complete and has words in it
+18:08 <@matches> I think he's onto something with his plan of actually writing things
+18:14 -!- matches changed the topic of #ipdf to: ipdf the pdf doesn't stand for pdf
+18:14 -!- matches changed the topic of #ipdf to: ipdf the pdf doesn't stand for pdf but the df stands for df
+18:14 -!- matches changed the topic of #ipdf to: Sort of
+18:15 <@matches> I need a script to auto mute me...
+18:15 < sulix> I spent basically all of today on that one commit.
+18:15 -!- mode/#ipdf [-o matches] by matches
+18:15 -!- mode/#ipdf [+o matches] by OperServ
+18:15 < sulix> Whether or not that was more useful than the cleanup remains to be seen.
+18:16 <@matches> I should look at it I guess :P
+18:16 < sulix> It compiles*
+18:16 < sulix> *but has lots of warnings.
+18:16 <@matches> It can't be worse than my tester that converts floats to floats
+18:17 < sulix> I'm pretty certain it can be and is worse.
+18:17 <@matches> However I've realised I kind of actually do need to be able to do that
+18:17 <@matches> Woah 3k+ lines
+18:17 <@matches> * 4k+ lines
+18:18 < sulix> Most of it was autogenerated, but still...
+18:18 * matches weeps for OpenGL 1
+18:18 < sulix> You don't realise how much you miss it until it's gone...
+18:19 <@matches> So what does all this stuff actually do
+18:19 <@matches> Because I could see rectangles and things just fine without it
+18:19 < sulix> Exactly the same thing as before but it works on my laptop now.
+18:19 <@matches> I see a shader program, that's obviously good
+18:20 <@matches> Actually I see code for a shader but no shader yet
+18:20 < sulix> The shaders are all #defines, I'm afraid.
+18:22 <@matches> What was wrong with your laptop?
+18:23 < sulix> It doesn't support the OpenGL compatibility mode, so --- as I was using the OpenGL 3.1 feature of "primitive restart", I had to code the entire thing in OpenGL 3.1
+18:23 < sulix> On the bright side, this paves the way for doing things like getting the GPU to use doubles.
+18:26 <@matches> Ooh
+18:27 < sulix> (also halves)
+18:27 < sulix> (halfs?)
+18:27 <@matches> Do GPUs use IEEE floats? I had a reference that seemed to be complaining they didn't
+18:27 <@matches> Although it was circa 2007
+18:28 < sulix> I don't think that there's a requirement that they internally use them, but they do read and write them.
+18:28 < sulix> A bit like how x86 processors use(d) 80 bit reals internally and rounded when reading/writing to memory.
+18:28 <@matches> Do halves have a different mantissa encoding
+18:29 <@matches> The examples given on wikipedia seem wrong
+18:30 < sulix> I think this is the canonical description: http://www.opengl.org/registry/specs/NV/half_float.txt
+18:33 <@matches> That would be before IEEE specified half (binary16) but its the same summation for the mantissa anyway
+18:33 <@matches> binary16 is (briefly) in the 2008 revised 754
+18:34 <@matches> So I think wikipedia is giving a wrong example, but I'm not confident enough to go and change wikipedia
+18:35 <@matches> Also I just realised my conversion of the mantissa to a Real is horrible
+18:35 <@matches> Oh well, it can get fixed later
+18:36 <@matches> Hopefully I can finish my fluid mechanics assignment quick enough to actually work on my progress report / proposal / thing
+18:36 <@matches> (Hah)
+18:36 -!- mode/#ipdf [-o matches] by matches
+18:37 < sulix> Yeah, I'm going to see how much Lit review I can write for tomorrow. :/
+--- Day changed Mon Apr 28 2014
+22:06 -!- mode/#ipdf [+o matches] by OperServ
+22:10 <@matches> Must find motivation to work on Lit Review at 10pm...
+--- Day changed Tue Apr 29 2014
+10:06 <@matches> Must find motivation to work on Lit Review at 10am...
+--- Day changed Wed Apr 30 2014
+13:04 <@matches> I wanted to rasterise a vector image so I could compare them at the same scale ("These look the same!") and zoomed ("This one looks crappier!)
+13:04 <@matches> But because vector graphics editor/viewers don't use pixels as units but they do when they export to a bitmap, it's difficult to actually get them to look the same
+13:04 <@matches> Before scaling
+13:05 <@matches> I guess a screenshot tool might be the best way
+13:06 <@matches> I don't know if I need to do this really
+13:07 <@matches> I guess Mechanical and Chemical engineers marking this will probably benefit from having an example
+13:07 <@matches> Doesn't everyone know the difference between vector and raster graphics
+13:07 <@matches> Where was that paper that had tux vector and rasterised
+13:10 <@matches> Ah, worth2003xr.pdf
+13:11 <@matches> If it's in a paper I guess it can go in a Lit Review
+13:11 <@matches> At least until I have something better
+13:15 <@matches> Kind of ironic that the image I am using was actually scanned first as a bitmap and then converted to vector using Trace Bitmap
+13:57 <@matches> Ah, it's actually impossible to get it to be exactly the same, because even taking a screenshot on my own screen it will then be different depending on the display of whoever reads the digital pdf
+13:57 <@matches> Oh well
+13:58 <@matches> I suppose "It looks shittier" will have to suffice without trying to make them look exactly the same before scaling
+13:59 <@matches> I have spent WAY too long making this example
+13:59 <@matches> I could have just gone "See \cite{worth2003xr.pdf}"
+16:00 <@matches> So it might be worth talking about dpi in pdf viewers and how it SUCKS
+20:17 -!- mode/#ipdf [-o matches] by matches
+21:14 -!- mode/#ipdf [+o matches] by OperServ
+21:46 <@matches> I have perpetrated XML on the codebase
+21:47 <@matches> I have grand visions of our code supporting SVGs
+21:47 <@matches> I also have grand visions of actually doing a Literature Review
+21:50 * sulix git pull's with some trepidation.
+21:52 < sulix> Never heard of pugixml before but it looks okay.
+21:55 <@matches> The W3C XML specification is pretty terrifying
+21:56 <@matches> I will feel more like I've satisfied the "Document Formats" part of the Literature Review if I say some things about it
+21:57 <@matches> Well SVG in particular
+21:57 <@matches> SVG defines a "minimum" precision of IEEE binary32
+21:58 <@matches> But there's a specification for "High Quality" viewers that have to use binary64
+21:58 <@matches> That's probably the only real thing relevant directly to our problem
+--- Day changed Thu May 01 2014
+01:23 <@matches> It's May 1st
+01:23 <@matches> This means we can no longer say "The Literature Review is due Next Month"
+01:23 <@matches> IT'S DUE THIS MONTH
+01:23 * matches freaks out
+01:23 <@matches> ... but after sleep
+01:25 <@matches> Page 12 of my Literature Review by the way
+01:25 <@matches> Is the only page I like
+16:34 <@matches> The C version of paranoia compiled for me
+16:34 <@matches> Not terribly exciting (I have an IEEE 754 compatible processor! Amazing)
+22:17 <@matches> W Kahan's website is a very interesting if slightly difficult read
+22:24 <@matches> He appears to have written this 80 page pdf in a day
+22:27 <@matches> It kind of reads like one of those religious propaganda pamphlets
+22:27 <@matches> "Java is the Work of Satan"
+22:27 <@matches> "Kernighan-Ritcie C floating-point semantics are the light"
+22:28 <@matches> But every so often he has a graph or example that makes him seem less crazy
+22:34 <@matches> "And now Java forbits you to mention or use extra-precise long double arithmetic, though IEEE Standard 754 recommends its use and over 95% of computers on desktops have it built into their hardware. You paid for it, but Java denies you its benefits."
+22:34 <@matches> Java has long double now right?
+22:34 <@matches> Although that JOP I was looking at was just 32 bit
+22:36 <@matches> Ah, java.lang.math.BigDecimal
+22:37 <@matches> "But be careful with division, because it will throw exceptions if it's like 1/3, then it will be Non-terminating decimal expansion."
+22:37 <@matches> That sounds horrifying
+22:40 -!- mode/#ipdf [-o matches] by matches
+--- Day changed Sat May 03 2014
+22:01 < sulix> My crazy idea to you would be to research p-adic number representations.
+22:01 < sulix> It's been a while, but they were mentioned a couple of times in pure maths units and seemed interesting/crazy and I can't remember much about them.
+22:28 -!- mode/#ipdf [+o matches] by OperServ
+22:29 <@matches> I will look at them, the "just use a float but with more bits until you run out of memory" doesn't seem a very well thought out approach
+22:29 <@matches> Maybe someone actually cares enough to research better ways
+22:29 <@matches> I mean, something's wrong with an idea when you can write "1/3" and have a runtime exception (re: Java BigNumber)
+22:30 <@matches> I plan to write some nasty things about Java based on Kahan's rants so as to gloss over the fact that it has BigNumber built into it and forstall the inevitable "Why didn't you use Java!"
+22:31 < sulix> I think we want to truncate to whatever the most accurate you can see at the given zoom level.
+22:31 <@matches> Yeah
+22:32 <@matches> It annoys me that XML and HTML specs don't have a PDF version
+22:32 < sulix> I've been printing to pdf for some of those things.
+22:33 <@matches> None of the links to different sections would work though
+22:35 <@matches> Specifications are thrilling
+22:35 <@matches> "How to read this specification"
+22:35 <@matches> "This specification should be read like all other specifications"
+22:35 <@matches> Oh wait
+22:35 <@matches> It actually gets better
+22:35 <@matches> Is that...
+22:35 <@matches> Humour!
+22:36 <@matches> I thought that wasn't allowed!
+22:36 <@matches> "First it should be read cover-to-cover, multiple times. Then, it should be read backwards at least once. Then it should be read by picking random sections from the contents list and following all the cross references"
+22:37 <@matches> As much as I love the idea of reading 626 pages of specification backwards...
+--- Day changed Tue May 06 2014
+00:39 <@matches> http://szmoore.net/ipdf/sam/rate-my-litreview.py
+00:39 <@matches> Tim will be thrilled!
+00:40 <@matches> I'm probably going to really regret making that
+00:41 <@matches> The regret is rising to the surface
+00:41 <@matches> It's an example of an interactive document format
+00:41 <@matches> The pixels or perish guy would approve
+00:43 <@matches> So much regret
+00:43 -!- mode/#ipdf [-o matches] by matches
+23:37 -!- mode/#ipdf [+o matches] by OperServ
+23:38 <@matches> So, I have this book called "Computer Graphics" that is pretty amazing
+23:38 <@matches> Funnily enough it has all the algorithms in it
+23:38 <@matches> For computer graphics
+23:38 <@matches> Probably should have been reading it ages ago but I thought we were worrying more about precision
+23:38 <@matches> I don't even know anymore
+23:39 <@matches> Have to read 500pg textbook on graphics, 500pg textbook on floating point numbers, 500pg PDF/PostScript standards...
+23:39 <@matches> Too many pages
+23:39 <@matches> Anyway it has a section on Octrees
+23:39 <@matches> But don't worry
+23:39 <@matches> It mentions Quad trees
+23:39 <@matches> It also actually mentions fractals
+23:39 <@matches> As a thing
+23:40 <@matches> In other news, extending the document we have at the moment to allow anything other than rectangles will be interesting
+23:41 <@matches> Did you do this on purpose? :P
+--- Day changed Wed May 07 2014
+12:32 <@matches> We need to do something about all the warnings generated by the magic OpenGL 3 stuff
+12:32 <@matches> It's making it hard to sport warnings that I actually care about
+12:33 <@matches> Like: You forgot to return a value in this function :S
+13:52 <@matches> Gah I did it again
+13:52 <@matches> auto is dangerous
+13:53 <@matches> Possibly because it's buggy
+13:53 <@matches> I can't actually see any compiler warnings at all
+17:39 <@matches> So you can almost maybe see a difference between beziers calculated using floats and doubles
+17:40 <@matches> If you squint
+17:40 <@matches> And view them on different monitors
+17:41 <@matches> Ah there we go
+17:41 <@matches> I successfully broke it
+17:42 <@matches> When you round to pixel positions it doesn't make a difference
+17:43 <@matches> But on the other hand if you calculate beziers using really big numbers they look wierd :P
+17:43 <@matches> That's important
+17:43 <@matches> Because if you have an arbitrary infinite document you might be at coordinate positions that are really big
+17:43 <@matches> Captain Obvious strikes again
+17:45 <@matches> I think I will make a video of a circle moving towards infinity
+17:45 <@matches> This probably won't help the literature view much but it's too tempting to resist
+17:46 <@matches> I gave up trying to deal with our document format so I currently just generate vector<pair<T, T> > and then map that to a bitmap :P
+--- Day changed Thu May 08 2014
+10:57 <@matches> So circle was a terrible example
+10:57 <@matches> It stays as a circle
+10:58 <@matches> Hopefully the first curve I tried wasn't just a bug
+12:31 <@matches> I think it was a bug
+13:35 <@matches> There are bezier things in ipdf/code/src/tests now
+13:57 < sulix> I am very confused.
+13:57 < sulix> It generates bitmaps of circles in varying shades of red?
+13:58 * sulix decides to actually read the code.
+14:03 < sulix> Ah: I see what it's doing now.
+14:16 <@matches> Your first comment was pretty accurate :S
+14:17 <@matches> I was trying to obtain some amazing animation of a circle that hopelessly collapsed or exploded or something
+14:19 < sulix> I'm slightly terrified that it's generating a vector of points.
+14:19 < sulix> On the other hand, it looks like the rest of the world is realising what a mistake making OpenGL 3 terrifying was.
+14:19 <@matches> Yeah that's a bit lazy
+14:19 <@matches> Although, is returning a vector optimisable?
+14:20 < sulix> In C++11 it is.
+14:20 < sulix> (But not C++98)
+14:20 <@matches> C++11 is growing on me
+14:20 < sulix> Yeah: I've found the same thing.
+14:21 < sulix> I'm a bit scared about what that means, though.
+14:21 < sulix> Maybe one day I'll think boost was a good thing, and then I'll truly be lost.
+14:21 <@matches> Hahaha
+14:21 <@matches> The lambdas remind me of Javascript :S
+14:22 < sulix> I think lambdas are one of those things that are good for you in moderation, but poisonous in large quantities.
+14:22 <@matches> Probably
+14:23 < sulix> I won't be around on Monday, btw, so I'll miss the meeting.
+14:23 < sulix> (Also I'm missing out on Codejam, sadly)
+14:23 <@matches> No!
+14:23 <@matches> (To both of those things)
+14:24 <@matches> Oh god that means I need to make double the progress
+14:25 < sulix> I spoke to Tim, he said that it might be worth cancelling the meeting altogether.
+14:26 <@matches> Haha
+14:26 <@matches> I'm not sure if I should take that as a good or bad sign
+14:27 <@matches> I'm not going great with the literature review
+14:28 < sulix> I rated a bit of it.
+14:28 < sulix> (Though there wasn't a submit button, and it took me a few goes to get through the Turing test)
+14:28 <@matches> Page 20?
+14:28 <@matches> Haha
+14:28 <@matches> The turing test defaults to the accepted answer though!
+14:28 <@matches> You have to actually change it to get it wrong
+14:29 < sulix> Yeah, I thought it was a trick question.
+14:29 <@matches> Maybe I'll give Tim a slightly less joke-worthy version of Rate My LitReview when the draft is done
+14:29 <@matches> ... when hell has frozen over...
+14:29 <@matches> Whichever comes first
+14:31 < sulix> You should read James Mickens' USENIX articles: mkdir -p vogl/vogl_build/bin/release64 && cd $_
+14:31 < sulix> cmake -DCMAKE_BUILD_TYPE=Release -DBUILD_X64=On ../../..
+14:31 < sulix> make -j 10
+14:31 < sulix> (Also I should paste the right thing in)
+14:31 < sulix> http://research.microsoft.com/en-us/people/mickens/
+14:32 <@matches> Ah yes, I will read those at some point
+14:32 * matches downloads the first one, telling himself he will not read it until working on the lit review
+14:33 * matches reads it anyway
+14:33 * sulix feels guilty about not doing lit review at the moment, too.
+14:40 <@matches> Have you heard of /read Computer Graphics by Hearn and Baker?
+14:40 <@matches> I have the ancient "In the dawn before OpenGL 1.0" version
+14:41 <@matches> There is a section mentioning "GL"
+14:41 <@matches> I don't think they use GPU anywhere, they call them "Display Rasterisers" or something
+14:42 <@matches> Display Processor
+14:43 <@matches> A Display Processing Unit is a Display Processor for a Random Scan (vector) display system
+14:43 <@matches> Input devices are interesting too
+14:44 <@matches> "Input Dials"
+14:44 <@matches> A box of variable resistors basically
+14:45 <@matches> Working with computers in the 70s/80s would have been interesting although probably just as horrible as it is today
+14:45 <@matches> But at least it would have been less "webby"
+14:46 <@matches> Where "How do I centre a div" is a deep philosophical question
+14:48 <@matches> I should probably obtain / read a newer edition of this if I want to put it in my lit review?
+14:48 <@matches> Although it is referrring to the same papers we had about Bressenheim
+15:14 <@matches> Oh my god they mention precision!
+--- Log closed Thu May 08 17:04:49 2014
+--- Log opened Thu May 08 18:56:39 2014
+18:56 -!- Irssi: #ipdf: Total of 2 nicks [0 ops, 0 halfops, 0 voices, 2 normal]
+18:56 -!- Irssi: Join to #ipdf was synced in 3 secs
+19:55 < matches> Bresenham made a tutorial on rasterisation
+19:56 -!- mode/#ipdf [+o matches] by OperServ
+19:56 <@matches> Bresenham has a nice tutorial about rasterising
+19:56 <@matches> Ties in with the "Since mankind came down from the trees" angle
+19:57 <@matches> "Needlepoint or counted cross-stitch, such as that popularised by the image on a box of Whitman Sampler chocolates..."
+19:57 <@matches> I'm not sure how to relate the rasterisation stuff to the precision stuff
+19:58 <@matches> You have to make a pretty big rounding error to end up in the wrong pixel
+19:59 <@matches> Hearn and Baker mention rounding errors as being one reason why you don't want to use floats and then round them when rasterising things
+19:59 <@matches> The (bigger) reason being that floating point operations are expensive
+20:00 <@matches> They say pixels could move from the line in the DDA algorithm for long lines... I wonder how long they mean... 1e38 pixels? :P
+20:02 <@matches> I want to actually make a drawing of things that look different due to rounding errors dammit!
+20:03 <@matches> None of this "here is a sentence or two of handwaving"
+20:04 <@matches> Maybe rounding errors were a problem on computers with 8 bit floats and terrible resolution displays :P
+20:04 <@matches> Except the worse your resolution the less you'd notice rounding errors
+20:04 <@matches> Well the more you'd notice them, the less they'd happen?
+20:04 <@matches> I don't know
+20:05 -!- mode/#ipdf [-o matches] by matches
+20:30 < sulix> These were recommended: http://www.amazon.com/Forman-S.-Acton/e/B001IYTXGY/?_encoding=UTF8&tag=mollrock-20&linkCode=ur2&qid=1358713701&camp=1789&sr=8-3&creative=390957
+20:30 < sulix> (By a blog post, which turned out not to be about floating point precision, but does mention it: http://mollyrocket.com/casey/stream_0009.html )
+21:21 < matches> I'll look at them at some point
+21:22 -!- mode/#ipdf [+o matches] by OperServ
+21:22 <@matches> I'll look at them at some point
+21:22 <@matches> I sort of got bogged down explaining how lines are drawn :S
+21:22 <@matches> Graphics is complicated dammit
+21:22 <@matches> I'll probably get more done if I just write about everything no matter how irrelevant
+21:23 <@matches> Sooner or later I'll actually write something important and the rest can be appendicised
+21:23 <@matches> Hopefully
+21:25 <@matches> Oh dear, I have located some primitive form of blog
+21:26 <@matches> Well, it talks about things, so I'll reference it...
+21:26 <@matches> "The good-looking textured light-sourced bouncy fun smart and stretchy page"
+21:26 <@matches> It's generally best to not go up a directory from the page you are looking at
+--- Day changed Sun May 18 2014
+15:47 <@matches> So things are due soonish
+15:47 <@matches> :S
+20:09 <@matches> Are you alive, because I don't think I'm alive
+20:10 -!- Irssi: #ipdf: Total of 2 nicks [1 ops, 0 halfops, 0 voices, 1 normal]
+20:11 <@matches> I'm feeling pretty guilty about all that work I didn't do last week...
+20:47 * sulix agrees entirely.
+22:11 <@matches> I give up
+22:11 <@matches> I will just have to face disappointment O'clock tomorrow
+22:22 < sulix> I still have to put more work in before I feel I even deserve disappointment, I think... :/
+22:23 < sulix> I made the mistake of deleting the irrelevant bits from my lit review, and now there's almost nothing left!
git.ucc.asn.au / ipdf / documents.git / blobdiff
UCC git Repository :: git.ucc.asn.au