Automatic commit of irc logs

Do not overtax your powers.

diff --git a/irc/#ipdf.log b/irc/#ipdf.log
index 3470f59..b3caf87 100644 (file)
--- a/irc/#ipdf.log
+++ b/irc/#ipdf.log
@@ -429,3 +429,103 @@
 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