From: C R Onjob Date: Mon, 16 Jun 2014 17:00:02 +0000 (+0800) Subject: Automatic commit of irc logs X-Git-Url: https://git.ucc.asn.au/?a=commitdiff_plain;h=69490cf3e34fb7de15089db58b4f217ffafb3437;p=ipdf%2Fdocuments.git Automatic commit of irc logs Your talents will be recognized and suitably rewarded. --- diff --git a/irc/#ipdf.log b/irc/#ipdf.log index 2779e77..d757461 100644 --- a/irc/#ipdf.log +++ b/irc/#ipdf.log @@ -1775,3 +1775,93 @@ 16:31 <@matches> Well my exams have finished 16:32 <@matches> Now I can go back to panicking about the project again 16:37 <@sulix> Excellent: it's your turn to do something impressive for the meeting on Monday, then. :P +--- Day changed Mon Jun 16 2014 +14:49 <@matches> Some of this OpenGL stuff doesn't quite add up +14:49 <@matches> Like m_cahed_display.UnBind(); m_cached_display.Blit(); +14:50 <@matches> Oh +14:50 <@matches> I see +14:50 <@matches> There is a difference +14:51 * matches -> OpenGL documentation +14:53 <@matches> Right I see +15:03 <@matches> Well, this makes a lot more sense than tpg's "Adventures in VEMS" in #ucc at least +15:18 <@sulix> Well that's an achievement, I guess. +15:18 <@sulix> Also http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2431.pdf +15:18 <@sulix> It's the spec for "nullptr"... +15:20 <@matches> "Pointers are pretty cool. Pointers that are NULL are pretty cool. We address these issues by proposing nullptr" ? +15:21 <@sulix> Haha: Pretty much. +15:22 <@matches> Why not just reserve the word "null" +15:22 <@matches> I could get behind it then +15:23 <@matches> It is not a null reference +15:23 <@matches> But if you ever have a null reference something is horrifyingly wrong +15:23 <@matches> Bah humbug +15:24 <@sulix> They have a page about that where they said "everyone was naming their variables \"null\"". +15:24 * sulix realises he just escaped those quote. Oh dear. +15:24 <@matches> A valid point, which should have lead to "Everyone are morons" +15:24 <@matches> Fun fact +15:25 <@matches> Matlab (like fortran actually) will let you use key words as variable names. +15:25 <@sulix> "It's a feature!" +15:25 <@matches> Question on CITS2401 exam: "Why is 'ii' preferred over 'i' and 'jj' over 'j' for loop iteration?" +15:26 <@matches> Both i and j are the complex number sqrt(-1) +15:27 <@matches> It seems like naming it 'nullptr' instead of 'null' missed an opportunity to stop people naming their variables really confusing things :P +15:30 <@matches> Well I am infinitely wiser about nullptr now but I don't think it will stop me just using NULL +16:15 <@matches> This is slowly starting to make sense +16:35 <@matches> I'm having a bit of difficulty because it's all so optimised for the GPU +16:35 <@matches> I think what we need is an ObjectRenderer class or similar +16:36 <@matches> Have one for each type of object and implement RenderUsingGPU and RenderUsingCPU +16:36 <@matches> I will see what monstrosity I can come up with +16:36 <@matches> But a lot of that code for the circles and rectangles is exactly the same just copied and pasted with different variable names +16:37 <@matches> I think there is an official software engineering term for that sort of thing... +16:46 <@matches> Alright, breaking everything +16:46 <@matches> This will probably take a while +16:47 * matches dreads merges +17:02 <@sulix> Yeah, I was going to basically end up with an ObjectRenderer class, too. +17:02 <@sulix> So I'll leave it to you for now and procrasinate from doing my maths in some other way. +17:07 <@matches> Cool :) +17:52 <@matches> Now I'm not very strict about the whole RAII thing myself, but there seem to be some cases where things can probably just go in the constructor? +17:52 <@matches> I guess we can fight about those later +17:54 <@matches> I guess I can see us wanting to set m_render_inited to false and have it automatically recreate everything, maybe, but I can't see a case where we will want to recompile the shaders, so I am going to put the shader initialisation in the constructors +17:54 <@matches> I have gone mad with power +17:54 <@matches> Maaad +20:30 <@matches> This ObjectRenderer is like a two headed hydra +20:31 <@matches> I thought about using just the ibo and vbo and getting the indices out of it, but that's a bit terrible +20:31 <@matches> So it will have an ibo for the GPU and an array for the CPU +20:35 * sulix thinks this makes sense. +21:47 <@matches> Good news! I have things on the screen. Bad news. They are still on the GPU and they are wrong. +21:49 <@matches> More coffee required... +21:58 <@matches> Not sure if code wrong or fglrx having an existential crisis +22:04 <@matches> Unrelated to the segfaults of doom, but I just realised that there's all this interest in using GPUs for scientific computation, and everything seems to point to them having vastly inferior floating point computation to a CPU, which is a bit disconcerting +22:05 <@matches> I imagine the OpenCL libraries etc actually use the IEEE floating point capabilities? I hope? +22:05 * matches files under "beyond the scope of project" +22:06 <@sulix> If you commit code I can test it on non-fglrx if that'll help. +22:06 <@matches> I'd rather not commit it just yet, I am 90% sure it is something I have done wrong and don't want to shame myself by committing broken code +22:06 <@matches> It'd be like vomiting all over the codebase +22:07 * sulix is pretty sure half of his commits broke something. +22:29 <@matches> Ok I committed stuff that should in theory work with the test pattern again +22:30 <@matches> Using new and improved ObjectRenderer classes +22:30 <@matches> For some definition of improved +22:30 <@matches> It doesn't actually use the CPU yet +22:30 <@matches> It'll get there +22:33 <@matches> You can go and add your MandleBrotSetRenderer now though :P +22:36 <@sulix> Cool. +22:37 <@sulix> The circles do trigger that intel driver bug again, though... +22:38 <@matches> Ah damn +22:38 <@matches> Would making CIRCLE_FILLED the first ObjectType fix that? +22:38 <@sulix> It does. +22:38 <@sulix> (I just checked) +22:38 <@sulix> Yay intel! +22:39 <@matches> Haha +22:49 <@matches> Hey, does our rendering approach completely break compositing? +22:49 <@matches> Render all circles +22:49 <@matches> Then render all rectangles... +22:49 <@matches> There's no depth... +22:49 <@sulix> Um, maybe. +22:49 <@matches> :P +22:49 <@matches> I was just worrying about how to make compositing work using the CPU +22:49 <@matches> and then I realised it won't work using the GPU as it is either +22:50 <@sulix> If we're not doing alpha-blending, we could just add a z-coordinate and use the z-buffer. +22:50 <@sulix> Otherwise, they need to be sorted if they intersect. +22:50 <@matches> Let's not worry about this for now... +22:50 <@matches> Even though I spent a rather significant part of my lit review explaining how awesome compositing is +22:51 <@matches> I guess it doesn't matter, clearly the lit review was not intended for anyone to actually read +23:42 <@matches> I suspect RenderPixels doesn't work +23:45 <@sulix> This may be the case.