| --- Log opened Wed Dec 10 00:00:25 2014 |
| 00:16 | | thalass [thalass@Nightstar-9ai58o.bigpond.net.au] has joined #code |
| 00:16 | | mode/#code [+o thalass] by ChanServ |
| 00:40 | | himi [fow035@Nightstar-dm0.2ni.203.150.IP] has joined #code |
| 00:40 | | mode/#code [+o himi] by ChanServ |
| 02:05 | | thalass is now known as Thalass|KSP |
| 03:48 | | Thalass|KSP [thalass@Nightstar-9ai58o.bigpond.net.au] has quit [Ping timeout: 121 seconds] |
| 03:56 | | Thalass|KSP [thalass@Nightstar-9ai58o.bigpond.net.au] has joined #code |
| 04:14 | | Tamber_ [tamber@furryhelix.co.uk] has joined #code |
| 04:15 | | Reiver [quassel@Nightstar-ksqup0.co.uk] has quit [Ping timeout: 121 seconds] |
| 04:16 | | Tamber [tamber@furryhelix.co.uk] has quit [Ping timeout: 121 seconds] |
| 04:22 | | Reiver [quassel@Nightstar-ksqup0.co.uk] has joined #code |
| 04:22 | | mode/#code [+ao Reiver Reiver] by ChanServ |
| 04:22 | | VirusJTG [VirusJTG@Nightstar-6i5vf7.sta.comporium.net] has quit [[NS] Quit: Program Shutting down] |
| 04:27 | | Reiver [quassel@Nightstar-ksqup0.co.uk] has quit [Ping timeout: 121 seconds] |
| 04:28 | | Reiver [quassel@Nightstar-ksqup0.co.uk] has joined #code |
| 04:28 | | mode/#code [+ao Reiver Reiver] by ChanServ |
| 05:04 | | himi [fow035@Nightstar-dm0.2ni.203.150.IP] has quit [Connection closed] |
| 05:08 | | himi [fow035@Nightstar-dm0.2ni.203.150.IP] has joined #code |
| 05:08 | | mode/#code [+o himi] by ChanServ |
| 05:28 | <~Vornicus> | arg I have topdown terrariacraft stuck in my head once more. |
| 05:28 | | abudhabi [abudhabi@Nightstar-7nkq9k.de] has quit [Connection closed] |
| 05:47 | <@celticminstrel> | Okay. Why is it that every time I try to change how my tiling routine works, stuff doesn't get drawn in one of my dialog windows, and then from there everything else is messed up? |
| 05:47 | <@celticminstrel> | It looks like the aforementioned window just contains uninitialized stuff. |
| 05:49 | | Checkmate [Z@Nightstar-484uip.cust.comxnet.dk] has joined #code |
| 05:49 | | mode/#code [+o Checkmate] by ChanServ |
| 05:51 | <@celticminstrel> | Okay, it looks like it occurs when a dialog is launched via a menu item... |
| 05:52 | <@celticminstrel> | And exactly how it messes up is predictable based on the dialog launched... |
| 05:53 | | Vornicus [vorn@ServerAdministrator.Nightstar.Net] has quit [[NS] Quit: Leaving] |
| 05:56 | <@celticminstrel> | Could this be related to some sort of buffer overflow? Or something being freed before I'm done with it? |
| 05:57 | | * celticminstrel decides to try the static analyzer, finds tons of cases of using uninitialized variables. |
| 05:57 | | * celticminstrel has no idea whether that's relevant though. |
| 06:11 | <@celticminstrel> | It doesn't seem likely that this could be a problem with forgetting to initialize something, since it worked before changing the tiling routine... |
| 06:20 | | himi [fow035@Nightstar-dm0.2ni.203.150.IP] has quit [Ping timeout: 121 seconds] |
| 06:37 | | macdjord|wurk is now known as macdjord|slep |
| 06:47 | <@celticminstrel> | Apparently drawing is changing the transform matrix of the window. That doesn't seem right... |
| 06:49 | <@celticminstrel> | Though, it does occur for windows that display fine Maybe it is right? |
| 06:54 | <@celticminstrel> | Oh huh, somehow the broken window's contents got drawn to the main window right after it closed... |
| 06:56 | <@celticminstrel> | This suggests the wrong rendering context is active. Somehow. |
| 06:56 | <@celticminstrel> | Or maybe it doesn't. |
| 06:57 | | abudhabi [abudhabi@Nightstar-7nkq9k.de] has joined #code |
| 07:07 | <@celticminstrel> | Okay, I have proven that it is indeed going to the wrong window. |
| 07:15 | <@celticminstrel> | I have set the correct window active three times redundantly. |
| 07:15 | | mac [macdjord@Nightstar-r9vt2h.mc.videotron.ca] has joined #code |
| 07:15 | | mode/#code [+o mac] by ChanServ |
| 07:16 | <@celticminstrel> | So why isn't stuff going to the main window? |
| 07:18 | | macdjord|slep [macdjord@Nightstar-r9vt2h.mc.videotron.ca] has quit [Ping timeout: 121 seconds] |
| 07:19 | <@celticminstrel> | Uh. Correction. Why is stuff going to the main window. |
| 07:28 | | * celticminstrel blinkblinks. |
| 07:28 | <@celticminstrel> | Replace texture with fill colour, and suddenly it works. |
| 07:29 | <@celticminstrel> | Or could it be... |
| 07:30 | <@celticminstrel> | ...nope, doesn't work if I set both. |
| 07:38 | | Kindamoody[zZz] is now known as Kindamoody |
| 07:48 | <@celticminstrel> | So, it seems that I can fix it by redundantly requesting twice in a row for the window's rendering context to be set active... |
| 07:49 | <@celticminstrel> | ...and that proceeded to fail when reopening the window. |
| 07:49 | <@celticminstrel> | ...buut then it worked when reopening again...? |
| 07:49 | <@celticminstrel> | I don't get this! :( |
| 07:52 | <@celticminstrel> | ...and it didn't work the next time I ran it. |
| 08:06 | <&jeroud> | celticminstrel: Is the code available somewhere? |
| 08:07 | <@celticminstrel> | Well, the working version is. The broken version hasn'y even been committed yet. |
| 08:07 | <@celticminstrel> | I could pastebin it if you want. It uses SFML. |
| 08:07 | <&jeroud> | What language is this? |
| 08:09 | <@celticminstrel> | C++. |
| 08:10 | <&jeroud> | That's probably not something I can get setup easily. |
| 08:11 | <&jeroud> | I'm happy to take a look at the code, though. |
| 08:11 | <&jeroud> | Is the broken version a refactor or a new feature? |
| 08:13 | <@celticminstrel> | More like a refactor. I've been creating a new texture every time I want to tile something, which happens every time the screen is redrawn, which happens pretty frequently (possobly more frequently than necessary though). |
| 08:13 | <@celticminstrel> | Not sure if this is a sufficient snippet, but here you go: http://pastebin.com/gLY057R3 |
| 08:14 | <@celticminstrel> | And the working version of tileImage is here: https://github.com/calref/cboe/blob/master/osx/tools/graphtool.cpp#L1133 |
| 08:15 | <@celticminstrel> | clip_rect just sets glScissor. |
| 08:16 | <@celticminstrel> | That comment at the top turned out to be wrong - it did appear to cause it to work, but not consistently. |
| 08:18 | <@celticminstrel> | ...oh, the comment in the updated tileImage is also wrong. |
| 08:18 | <&jeroud> | Is this single-threaded? |
| 08:18 | <@celticminstrel> | Well, all my code is in one thread, at least. |
| 08:19 | <&jeroud> | What does setActive() return? |
| 08:20 | <&jeroud> | You're putting it in a bool, but I don't see anything looking at it. |
| 08:21 | <@celticminstrel> | I did that so that I could see in the debugger what it was returning. It's returning true both times. |
| 08:21 | <@celticminstrel> | I thought it might be returning false, but apparently not. |
| 08:21 | <&jeroud> | What does the value mean? |
| 08:22 | <@celticminstrel> | From setActive documentation: "Activate or deactivate the window as the current target for OpenGL rendering ... return True if operation was successful, false otherwise" |
| 08:22 | <&jeroud> | Ah. |
| 08:25 | <@celticminstrel> | There are two other windows in existence when this breaks (the hidden map window, and the main window); the dialog just shows garbage, while it seems the drawing is somehow directed to the main window instead. |
| 08:25 | | Tamber_ is now known as Tamber |
| 08:25 | | mode/#code [+o Tamber] by ChanServ |
| 08:25 | <@celticminstrel> | Though you only see that as a glimpse after the dialog closes, unless I call the main window's .display() method from the debugger. |
| 08:32 | | abudhabi [abudhabi@Nightstar-7nkq9k.de] has quit [Connection closed] |
| 08:33 | <&jerith> | Sanity check: Is the `win` in `cDialog::draw()` the correct window? |
| 08:33 | <@celticminstrel> | Hm. |
| 08:34 | <@celticminstrel> | I don't see any way it could be the wrong window; it's created in cDialog::run(), just a few lines above the first call to draw(). |
| 08:35 | <&jerith> | I don't understand how C++ does scoping. That just looked like a global variable or something. |
| 08:36 | <&jerith> | Does the fill work even if the texture stuff doesn't? |
| 08:37 | <@celticminstrel> | Ah, it's really this->win. |
| 08:37 | <@celticminstrel> | If I comment out the texture lines in tileImage, and replace it with a setFillColor, it works perfectly. |
| 08:38 | <&jerith> | You also don't seem to be calling tileImage() with enough params. |
| 08:39 | <@celticminstrel> | The mode param has a default. |
| 08:39 | <@celticminstrel> | No blending by default. |
| 08:43 | <@celticminstrel> | Hm, I wonder if I could make tesselInfo.tessel be just a Texture instead of a RenderTexture... |
| 08:43 | | * celticminstrel has no idea if that would help though. |
| 08:43 | <&jerith> | Do you share textures between windows? |
| 08:44 | <@celticminstrel> | The same textures are used to draw in both windows. |
| 08:44 | | abudhabi [abudhabi@Nightstar-7nkq9k.de] has joined #code |
| 08:44 | <&jerith> | Does a RenderTexture konw anything about the windows? |
| 08:44 | <&jerith> | *know |
| 08:44 | <@celticminstrel> | I'm pretty sure it doesn't. |
| 08:44 | <&jerith> | Maybe try caching textures per-window instead of globally. |
| 08:44 | | * jerith is guessing here. |
| 08:45 | | * celticminstrel suspects it might be a good guess, considering that the working version creates the texture on the fly. |
| 08:45 | <&jerith> | What does the documentation for RenderTexture say? |
| 08:52 | <@celticminstrel> | Well, I don't see anything about windows in its documentation... |
| 08:54 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has joined #code |
| 08:54 | | mode/#code [+o himi] by ChanServ |
| 09:01 | <@celticminstrel> | I dunno if it's relevant, but it only seems to occur in dialogs that are launched via a menu command. |
| 09:02 | <@celticminstrel> | In fact, it always seems to occur in such dialogs. |
| 09:02 | <@celticminstrel> | In fact, it doesn't have anything to do with which dialog; one dialog can be launched via button or menu, and displays the issue only if launched via menu. |
| 09:02 | <&jerith> | Hrm. |
| 09:03 | <&jerith> | Maybe the menu rendering stuff is grabbing the display back from you. |
| 09:03 | <@celticminstrel> | Hm. |
| 09:03 | <@celticminstrel> | There is an "ensureGLContext()" method somewhere, maybe I should try that... |
| 09:03 | <&jerith> | What happens if you delay a few hundred milliseconds before rendering the dialog? |
| 09:03 | <@celticminstrel> | Good question. |
| 09:03 | <@celticminstrel> | I will try it. |
| 09:06 | <@celticminstrel> | Oh huh. I added a sleep for 5 seconds before the window is created, and it seems to work, |
| 09:07 | <@celticminstrel> | ...oh, ensureGLContext is protected. Oh well. |
| 09:07 | | * celticminstrel will try 500ms. |
| 09:08 | <@celticminstrel> | Still works. |
| 09:08 | <@celticminstrel> | Hmm... |
| 09:10 | <@celticminstrel> | Even 100ms is enough. |
| 09:10 | <&jerith> | My hypothesis here is that some other thread is redrawing the main window because the menu changed. |
| 09:10 | <&jerith> | So you want some kind of lock around that, I think. |
| 09:11 | <@celticminstrel> | I have no idea how I would do that. |
| 09:11 | <&jerith> | What do the docs say? |
| 09:11 | <&jerith> | Especially about menu handling and such. |
| 09:12 | <@celticminstrel> | Which docs? NSMenu or - okay, I'll take a look. |
| 09:14 | <&jerith> | Oh, you have more than one graphical framework involved? |
| 09:15 | <@celticminstrel> | 99% of what I'm doing uses SFML, but for menus and a few other bits I'm digging into Cocoa. |
| 09:15 | <@celticminstrel> | SFML uses some Cocoa too, for creating windows and context and such, I think. |
| 09:20 | <@celticminstrel> | Maybe there's a better way to do this, but at least delaying 100 milliseconds works. |
| 09:20 | | * celticminstrel didn't find anything that looked useful in the NSMenu documentation, |
| 09:21 | <&jerith> | Does SFML say anything about interacting with Cocoa? |
| 09:24 | <@celticminstrel> | Not explicitly as far as I've seen, but... the documentation of the function that returns a native window handle (which is a Cocoa NSWindow on Mac) says "You shouldn't need to use this function, unless you have very specific stuff to implement that SFML doesn't support". |
| 09:32 | | Kindamoody is now known as Kindamoody|afk |
| 09:33 | <@celticminstrel> | Thanks for the help, by the way. |
| 09:34 | <&jerith> | I'm glad I could provide some assistance. :-) |
| 09:48 | <@celticminstrel> | Huh, even though it works, I still got that glimpse of it being drawn to the main window. |
| 09:48 | | * celticminstrel assumes it has something to do with how closing the dialog also meant quitting the program. |
| 09:49 | <&jerith> | Does OpenGL provide any kind of locking? |
| 09:49 | <@celticminstrel> | I have no idea. |
| 09:50 | <@celticminstrel> | For now though, I can live with a minor glitch that only occurs on quit. |
| 10:02 | <@celticminstrel> | Now I just have to figure out how to decide when I need to redraw, because constantly redrawing causes annoying flickering. |
| 10:02 | <&McMartin> | You are in fact supposed to redraw every single frame in OpenGL |
| 10:03 | <@celticminstrel> | Well, that's nice, but flickering... |
| 10:04 | <&McMartin> | Double-buffering. |
| 10:04 | <@celticminstrel> | ...wait a second. |
| 10:04 | <&McMartin> | You should be drawing to the backbuffer and flipping back to the front every frame, which should be, at a minimum, 20 or 30 times per second. |
| 10:05 | <@celticminstrel> | Yeah, and I thought I was doing that, so why is it flickering... |
| 10:06 | <@celticminstrel> | Just what does "redraw every frame" mean? |
| 10:07 | <@celticminstrel> | Maybe I'm redrawing more than once per frame? Could that cause flickering? |
| 10:08 | <&McMartin> | ... are you starting each frame with a glClear()? |
| 10:08 | <@celticminstrel> | Actually, for some reason or other, no. |
| 10:08 | <&McMartin> | OK. You may still have garbage from a couple frames back then |
| 10:08 | <@celticminstrel> | ...wait, I did recently add one, I think. |
| 10:09 | <@celticminstrel> | Yeah, there is a clear now, |
| 10:10 | <&McMartin> | If you're doing whatever SFML's equivalent of SDL_Flip() is more than once a frame you will indeed only be getting a fragment of a frame each scene, which will produce flicker. |
| 10:11 | <@celticminstrel> | Okay, so that's most likely it then, since I'm redrawing at the top of the event loop. |
| 10:13 | <@celticminstrel> | I think SFML provides something that might help... |
| 10:14 | <&McMartin> | GLUT does all this with callbacks |
| 10:14 | <&McMartin> | But almost nobody uses GLUT anymore and for good reason. |
| 10:14 | <&McMartin> | (My most recent Steam purchase does and I was kind of floored) |
| 10:16 | <@celticminstrel> | ...okay, I set SFML's framerate limit ridiculously low (1 fps) and still get flicker. If you can call it flicker when it's that slow. |
| 10:18 | <&McMartin> | Mmm |
| 10:20 | <&jerith> | You should be clearing at the start of the render portion of each frame and flipping at the end. |
| 10:21 | <@celticminstrel> | This is what is happening. |
| 10:22 | <&jerith> | How does OpenGL handle the different windows? |
| 10:22 | <@celticminstrel> | I'm not quite sure. SFML handles all that for me. |
| 10:27 | <@celticminstrel> | Okay, uh, there might be something else going on. It seems that every other redraw skips everything except the background, somehow. |
| 10:28 | <@celticminstrel> | ...maaaybe I'm setting glScissor somewhere and forgetting to clear it? |
| 10:29 | <@celticminstrel> | Hm, that doesn't appear to be the case... |
| 10:32 | | * celticminstrel decides to give up for now and sleep. |
| 11:20 | | VirusJTG [VirusJTG@Nightstar-6i5vf7.sta.comporium.net] has joined #code |
| 12:07 | | gnolam [lenin@Nightstar-fk7ia4.cust.bredbandsbolaget.se] has quit [[NS] Quit: Again footwear] |
| 12:12 | | gnolam [lenin@Nightstar-fk7ia4.cust.bredbandsbolaget.se] has joined #code |
| 12:12 | | mode/#code [+o gnolam] by ChanServ |
| 12:23 | | Thalass|KSP is now known as Thalass |
| 12:23 | | mode/#code [+o Thalass] by ChanServ |
| 15:01 | | Thalass [thalass@Nightstar-9ai58o.bigpond.net.au] has quit [[NS] Quit: ahahahaha] |
| 15:01 | | Reiv [NSwebIRC@Nightstar-q8avec.kinect.net.nz] has quit [Ping timeout: 121 seconds] |
| 15:01 | | Reiv_ [NSwebIRC@Nightstar-q8avec.kinect.net.nz] has quit [Ping timeout: 121 seconds] |
| 15:07 | <@iospace> | https://eval.in/194807 |
| 15:11 | <@iospace> | http://iospace.privatepaste.com/159ab83e2c |
| 15:12 | <@iospace> | I swear to the gods i will hunt these people down and stab them (kidding, of course) |
| 15:15 | <&McMartin> | I forget if sleep() is guaranteed to use monotonic time |
| 15:17 | <@iospace> | no clue |
| 15:18 | | mac is now known as macdjord|wurk |
| 15:18 | <&McMartin> | Like, it's not intrinsically dumb to mix sleep or select with time-of-day checks just to make sure that people aren't fucking with you by messing with system time |
| 15:18 | <&McMartin> | This isn't that |
| 15:18 | <&McMartin> | This, as you describe it, will peg the CPU |
| 15:18 | <&McMartin> | Naughty |
| 15:19 | <&ToxicFrog> | McMartin: the POSIX standard says that sleep "shall suspend the calling thread from execution for s realtime seconds" and refers you to the section on alarm(); alarm() says that "realtime" means specifically "wall clock time" and not system time, nor does it have any relation to "realtime" as in RTOS. |
| 15:20 | | * McMartin nods |
| 15:21 | <&ToxicFrog> | So messing with system time shouldn't have any effect on sleeps. |
| 15:35 | <@celticminstrel> | I still can't figure out this flickering. Maybe I really shouldn't redraw the screen all the time? I could draw everything to an offscreen texture that's only updated when something changes, and then just transfer that over every frame. |
| 15:36 | <@celticminstrel> | Oddly, sometimes the flickering stops after hitting a breakpoint. |
| 15:36 | <@celticminstrel> | Or just randomly after a few seconds. |
| 15:40 | <@celticminstrel> | Or after the window is covered up. |
| 15:43 | <@celticminstrel> | Or after the window is moved. |
| 15:44 | <&McMartin> | There is something very strange about your interaction with SFML here. |
| 15:44 | <&McMartin> | Which I have no experience with and cannot opine on |
| 15:44 | <&McMartin> | But double-buffering should be basically doing that *on its own* |
| 17:12 | | Syka [the@Nightstar-c409v3.vividwireless.net.au] has quit [Ping timeout: 121 seconds] |
| 17:20 | | Syka [the@Nightstar-c409v3.vividwireless.net.au] has joined #code |
| 17:35 | | Checkmate [Z@Nightstar-484uip.cust.comxnet.dk] has quit [Ping timeout: 121 seconds] |
| 17:52 | | Syka [the@Nightstar-c409v3.vividwireless.net.au] has quit [Ping timeout: 121 seconds] |
| 18:06 | | Syka [the@Nightstar-c409v3.vividwireless.net.au] has joined #code |
| 18:32 | | celticminstrel [celticminst@Nightstar-8hsj68.dsl.bell.ca] has quit [Ping timeout: 121 seconds] |
| 18:41 | | celticminstrel [celticminst@Nightstar-rq1cld.dsl.bell.ca] has joined #code |
| 18:41 | | mode/#code [+o celticminstrel] by ChanServ |
| 18:53 | | Syka [the@Nightstar-c409v3.vividwireless.net.au] has quit [Ping timeout: 121 seconds] |
| 19:00 | | Syka [the@Nightstar-c409v3.vividwireless.net.au] has joined #code |
| 19:03 | | * celticminstrel ponders. |
| 19:13 | <@celticminstrel> | If I move drawing to the bottom of the loop (plus an initial redraw just before), it... wait, now it works? Last time I tried that, it flickered when moving my mouse across it, or when clicking (which enters a separate event loop). |
| 19:14 | <@celticminstrel> | Ah, now it's doing that again, but only while clicking, so I guess not quite as bad. Somehow, hitting a breakpoint seems to fix it until the dialog is closed, but not for the next dialog. |
| 19:16 | <@celticminstrel> | However, if I repeat that stretegy (which is probably wrong anyway) in the clicking event loop, half the dialog isn't even drawn. |
| 19:18 | | * gnolam finds it a bit ironic that a textbook on color physics is printed in black-and-white. |
| 19:21 | | celticminstrel [celticminst@Nightstar-rq1cld.dsl.bell.ca] has quit [Ping timeout: 121 seconds] |
| 19:23 | | celticminstrel [celticminst@Nightstar-kuqdrv.dsl.bell.ca] has joined #code |
| 19:23 | | mode/#code [+o celticminstrel] by ChanServ |
| 19:26 | | VirusJTG [VirusJTG@Nightstar-6i5vf7.sta.comporium.net] has quit [[NS] Quit: Program Shutting down] |
| 19:27 | | VirusJTG [VirusJTG@Nightstar-6i5vf7.sta.comporium.net] has joined #code |
| 19:32 | <@celticminstrel> | Putting in a timer to only redraw at specified intervals doesn't change anything; it still flicks back and forth between full redraw and just background at that interval. |
| 19:33 | <@gnolam> | celticminstrel: post code |
| 19:34 | <@celticminstrel> | Incidentally, replacing the tiled background with a simple file (either a quad or a clear) doesn't help. |
| 19:34 | | Syka [the@Nightstar-c409v3.vividwireless.net.au] has quit [Ping timeout: 121 seconds] |
| 19:35 | | Syka [the@Nightstar-c409v3.vividwireless.net.au] has joined #code |
| 19:36 | <@celticminstrel> | gnolam: The run function is quite long and (probably) mostly irrelevant, but here you go: http://pastebin.com/2pAjkmqW |
| 19:40 | < abudhabi> | Whee. Salary get, computer parts order make. |
| 19:45 | <@ErikMesoy> | Hurrah. |
| 19:46 | | celticminstrel [celticminst@Nightstar-kuqdrv.dsl.bell.ca] has quit [Ping timeout: 121 seconds] |
| 19:49 | | Syka [the@Nightstar-c409v3.vividwireless.net.au] has quit [Ping timeout: 121 seconds] |
| 19:54 | | celticminstrel [celticminst@Nightstar-porlo8.dsl.bell.ca] has joined #code |
| 19:54 | | mode/#code [+o celticminstrel] by ChanServ |
| 19:55 | <@celticminstrel> | Gah, my Internet died for a bit. Did anyone say anything? |
| 19:55 | <@Tamber> | Nupe |
| 19:58 | <@celticminstrel> | Aw. |
| 19:59 | < abudhabi> | Actually, ErikMesoy said "Hurrah." |
| 20:00 | <@celticminstrel> | Fair enough, but I was more interested in things addressed to me. |
| 20:03 | | Syka [the@Nightstar-c409v3.vividwireless.net.au] has joined #code |
| 20:10 | | Kindamoody|afk is now known as Kindamoody |
| 20:38 | <@celticminstrel> | I have no idea what to try next... |
| 20:39 | < abudhabi> | Genuflect. |
| 20:39 | <@celticminstrel> | Hah. |
| 20:39 | <@celticminstrel> | Excpet maybe updating SFML. |
| 20:39 | <@celticminstrel> | ^Except |
| 20:39 | < abudhabi> | (Alternatively: Vomit.) |
| 20:39 | <@celticminstrel> | No. |
| 20:40 | < abudhabi> | Damn. That's my entire list of suggestions. |
| 20:40 | <@celticminstrel> | So helpful. :P |
| 20:40 | < abudhabi> | I aim to please. :P |
| 20:46 | <@Tarinaky> | Someone said my name, but I can't see it. |
| 20:47 | <@Tarinaky> | +in the last 4 days |
| 20:51 | <@ErikMesoy> | So helpful. |
| 20:51 | <@Tarinaky> | Well I've been away 4 days |
| 20:51 | <@Tarinaky> | I come back and this channel was purple |
| 20:52 | <@Tarinaky> | But the cause has scrolled off the backbuffer, so /lastlog -hilight doesn't work. |
| 20:52 | <@Tarinaky> | It's all the information I hav. |
| 20:52 | <@celticminstrel> | The fact that it magically fixes itself as soon as it hits a breakpoint in the debugger really doesn't help...+ |
| 20:52 | <@celticminstrel> | It means I can't locate the issue by stepping through it. |
| 20:53 | | * celticminstrel does sorta have an idea though. |
| 20:53 | <@Tarinaky> | Must be a memory issue then. |
| 20:53 | <@celticminstrel> | Could be! |
| 20:54 | <@Tarinaky> | Try Valgrind? |
| 20:54 | <@celticminstrel> | I recall trying to figure out valgrind once or twice. |
| 20:55 | <@celticminstrel> | Tried using it for something, can't remember what, but it didn't help at all. |
| 20:56 | <@celticminstrel> | Apple's Instruments app is simpler and might not be as powerful (not sure), but at least I can sometimes get it to output useful information. |
| 20:56 | <@celticminstrel> | (For example, proving that creating a texture several times per frame is a bad idea.) |
| 20:56 | <@Tarinaky> | idk, when I used valgrind it was pretty much just point and run, no probem# |
| 20:56 | <@Tarinaky> | Slow though. |
| 20:56 | <@celticminstrel> | Oh, yeah, it might've been that it was so slow that I simply couldn't do anything. |
| 20:56 | <@Tarinaky> | But I had a non-interactive app to debug, so that was a non-issue. |
| 20:57 | <@celticminstrel> | Yeah, that would probably help a lot. |
| 20:57 | <@Tarinaky> | Valgrind your unittests? |
| 20:57 | <@celticminstrel> | What unit tests? >_> |
| 21:00 | <@ErikMesoy> | Something something there's your problem. |
| 21:00 | <@Tarinaky> | Something something glass houses. |
| 21:01 | | * celticminstrel has no idea how you'd write a unit test for something like this, plus has no idea how to write unit tests in C++ anyway. I can do them in Java, but that doesn't help here. |
| 21:02 | <@Tarinaky> | How to write unittests in C++: You create a second make target/executable and use Macros to assemble your test suite in the tests make target main method. |
| 21:02 | <@Tarinaky> | There's a bunch of unittest frameworks that do similar things. |
| 21:03 | <@Tarinaky> | But the end goal is the same. |
| 21:07 | <@Tarinaky> | Not gonna lie: unittests in C++ is more work than in other languages... Just like everything else. |
| 21:15 | <@celticminstrel> | Anyway, telling me I need unit tests isn't really helpful here. |
| 21:17 | | Checkmate [Z@Nightstar-ev6.6um.94.83.IP] has joined #code |
| 21:17 | | mode/#code [+o Checkmate] by ChanServ |
| 21:18 | <@Tarinaky> | celticminstrel: You should still write a test case to debug your fault. |
| 21:19 | <@Tarinaky> | Even if it's not a unit ttest |
| 21:19 | <@Tarinaky> | Then you can push the test through Valgrind. |
| 21:19 | <@celticminstrel> | Hm. |
| 21:19 | <@celticminstrel> | But as said before, it's interactive. |
| 21:20 | <@Tarinaky> | So use a test fixture. |
| 21:20 | <@Tarinaky> | Input Playback. |
| 21:21 | <@Tarinaky> | Whatever you want to call it. |
| 21:21 | <@celticminstrel> | I have no idea how to do that! That said, I only need to click twice, so maybe I can just try it.... |
| 21:23 | <@celticminstrel> | ...though it's not good if the output just goes to terminal. |
| 21:25 | | Checkmate [Z@Nightstar-ev6.6um.94.83.IP] has quit [Ping timeout: 121 seconds] |
| 21:27 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 22:24 | <@celticminstrel> | ...okay, now I have a mini-app that does nothing but display a dialog and exit... but it crashes with EXC_BAD_ACCESS complaining that "address doesn't contain a section that points to a section in an object file", while attempting to call a virtual function. |
| 22:44 | | Kindamoody is now known as Kindamoody[zZz] |
| 23:00 | | * celticminstrel has given up on the flickering issue for the time being; will come back to it later. |
| 23:08 | | Checkmate [Z@Nightstar-484uip.cust.comxnet.dk] has joined #code |
| 23:08 | | mode/#code [+o Checkmate] by ChanServ |
| 23:21 | | himi [fow035@Nightstar-dm0.2ni.203.150.IP] has joined #code |
| 23:21 | | mode/#code [+o himi] by ChanServ |
| 23:32 | | Vornicus [vorn@ServerAdministrator.Nightstar.Net] has joined #code |
| 23:32 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| --- Log closed Thu Dec 11 00:00:40 2014 |