From 658c156ba0465e3f42572275eb8f9702050293d6 Mon Sep 17 00:00:00 2001 From: C R Onjob Date: Fri, 18 Apr 2014 01:00:02 +0800 Subject: [PATCH] Automatic commit of irc logs Do not overtax your powers. --- irc/#ipdf.log | 100 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 100 insertions(+) diff --git a/irc/#ipdf.log b/irc/#ipdf.log index 3470f59..b3caf87 100644 --- 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 View 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 -- 2.20.1