| --- Log opened Mon Apr 07 00:00:19 2014 |
| 00:19 | | You're now known as TheWatcher[T-2] |
| 00:19 | | Vornicus [Vorn@Nightstar-28h42k.sd.cox.net] has quit [Connection closed] |
| 00:28 | | You're now known as TheWatcher[zZzZ] |
| 00:33 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 00:35 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has joined #code |
| 00:35 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| 00:51 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has joined #code |
| 00:51 | | mode/#code [+o himi] by ChanServ |
| 01:30 | | Thalass [thalass@Nightstar-90oetb.bigpond.net.au] has quit [Ping timeout: 121 seconds] |
| 01:58 | | iospace [Alexandria@Nightstar-fkokc2.com] has quit [[NS] Quit: Reconnecting] |
| 01:58 | | iospace [Alexandria@Nightstar-fkokc2.com] has joined #code |
| 01:58 | | mode/#code [+o iospace] by ChanServ |
| 02:02 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 02:04 | | JustBob [justbob@ServerAdministrator.Nightstar.Net] has quit [Server shutdown] |
| 02:04 | | ErikMesoy [Erik@Nightstar-6v0.mal.203.80.IP] has quit [Server shutdown] |
| 02:04 | | Xon [Xon@Nightstar-j72.ku7.252.119.IP] has quit [Server shutdown] |
| --- Log closed Mon Apr 07 02:04:39 2014 |
| --- Log opened Mon Apr 07 02:09:47 2014 |
| 02:09 | | TheWatcher[zZzZ] [chris@Nightstar-ksqup0.co.uk] has joined #code |
| 02:09 | | Irssi: #code: Total of 35 nicks [15 ops, 0 halfops, 0 voices, 20 normal] |
| 02:09 | | mode/#code [+o TheWatcher[zZzZ]] by ChanServ |
| 02:10 | | Irssi: Join to #code was synced in 38 secs |
| 02:15 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has joined #code |
| 02:15 | | mode/#code [+o himi] by ChanServ |
| 02:24 | | McMartin_ is now known as McMartin |
| 02:24 | | mode/#code [+ao McMartin McMartin] by ChanServ |
| 03:30 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 03:44 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has joined #code |
| 03:44 | | mode/#code [+o himi] by ChanServ |
| 04:05 | | Turaiel^ is now known as Turaiel |
| 04:42 | | VirusJTG [VirusJTG@Nightstar-6i5vf7.sta.comporium.net] has quit [[NS] Quit: Program Shutting down] |
| 04:50 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 04:57 | | Thalass [thalass@Nightstar-90oetb.bigpond.net.au] has joined #code |
| 04:57 | | mode/#code [+o Thalass] by ChanServ |
| 05:03 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has joined #code |
| 05:03 | | mode/#code [+o himi] by ChanServ |
| 05:20 | | JackKnife [Z@Nightstar-484uip.cust.comxnet.dk] has joined #code |
| 05:21 | | mode/#code [+o JackKnife] by ChanServ |
| 05:33 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 05:41 | | Thalass [thalass@Nightstar-90oetb.bigpond.net.au] has quit [Ping timeout: 121 seconds] |
| 05:47 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has joined #code |
| 05:47 | | mode/#code [+o himi] by ChanServ |
| 05:49 | | Kindamoody|autojoin [Kindamoody@Nightstar-180u8i.tbcn.telia.com] has joined #code |
| 05:49 | | mode/#code [+o Kindamoody|autojoin] by ChanServ |
| 05:49 | | Kindamoody|autojoin is now known as Kindamoody |
| 05:55 | | AverageJoe [evil1@Nightstar-fb1kt4.ph.cox.net] has joined #code |
| 06:04 | | mode/#code [+o ErikMesoy] by ChanServ |
| 06:39 | | macdjord is now known as macdjord|slep |
| 06:45 | | RchrdB [RichardB@Nightstar-c6u.vd5.170.83.IP] has quit [[NS] Quit: Gone.] |
| 06:49 | | RchrdB [RichardB@Nightstar-c6u.vd5.170.83.IP] has joined #code |
| 07:03 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 07:17 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has joined #code |
| 07:17 | | mode/#code [+o himi] by ChanServ |
| 07:17 | | AverageJoe [evil1@Nightstar-fb1kt4.ph.cox.net] has quit [[NS] Quit: Leaving] |
| 07:29 | | Turaiel is now known as Turaiel[Offline] |
| 07:34 | | Kindamoody is now known as Kindamoody|afk |
| 08:27 | | celticminstrel [celticminst@Nightstar-mhtogh.dsl.bell.ca] has quit [[NS] Quit: KABOOM! It seems that I have exploded. Please wait while I reinstall the universe.] |
| 10:05 | | Ogredude_ [quassel@Nightstar-dm1jvh.projectzenonline.com] has quit [[NS] Quit: No Ping reply in 180 seconds.] |
| 10:05 | | Ogredude [quassel@Nightstar-dm1jvh.projectzenonline.com] has joined #code |
| 10:05 | | mode/#code [+o Ogredude] by ChanServ |
| 10:14 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 10:27 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has joined #code |
| 10:27 | | mode/#code [+o himi] by ChanServ |
| 10:43 | | mode/#code [+o RchrdB] by ChanServ |
| 10:59 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has quit [Connection reset by peer] |
| 11:07 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 11:21 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has joined #code |
| 11:21 | | mode/#code [+o himi] by ChanServ |
| 11:22 | | Thalass [thalass@Nightstar-90oetb.bigpond.net.au] has joined #code |
| 11:22 | | mode/#code [+o Thalass] by ChanServ |
| 11:32 | | VirusJTG [VirusJTG@Nightstar-6i5vf7.sta.comporium.net] has joined #code |
| 11:48 | | Thalass [thalass@Nightstar-90oetb.bigpond.net.au] has quit [Ping timeout: 121 seconds] |
| 11:50 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 12:03 | | You're now known as TheWatcher |
| 12:05 | | Thalass [thalass@Nightstar-90oetb.bigpond.net.au] has joined #code |
| 12:05 | | mode/#code [+o Thalass] by ChanServ |
| 12:06 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has joined #code |
| 12:06 | | mode/#code [+o himi] by ChanServ |
| 12:21 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 12:35 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has joined #code |
| 12:35 | | mode/#code [+o himi] by ChanServ |
| 12:59 | | macdjord|slep is now known as macdjord|wurk |
| 13:00 | | thalass_ [thalass@Nightstar-90oetb.bigpond.net.au] has joined #code |
| 13:00 | | thalass_ is now known as Thalass|otherpooter |
| 13:00 | | Thalass|otherpooter is now known as Thalass|2 |
| 13:19 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 13:34 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has joined #code |
| 13:34 | | mode/#code [+o himi] by ChanServ |
| 13:57 | | Thalass|2 [thalass@Nightstar-90oetb.bigpond.net.au] has quit [Connection reset by peer] |
| 14:12 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 14:16 | | Syk [the@Nightstar-s57.sib.126.1.IP] has quit [Connection closed] |
| 14:22 | | * Azash notes that logging into production from the public webpage is pretty fun |
| 14:25 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has joined #code |
| 14:25 | | mode/#code [+o himi] by ChanServ |
| 14:27 | | JackKnife [Z@Nightstar-484uip.cust.comxnet.dk] has quit [Ping timeout: 121 seconds] |
| 14:33 | | Syka [the@Nightstar-s57.sib.126.1.IP] has joined #code |
| 14:34 | | Syka is now known as NSGuest10712 |
| 14:35 | | NSGuest10712 is now known as Syk |
| 14:54 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 15:03 | | JackKnife [Z@Nightstar-ro94ms.balk.dk] has joined #code |
| 15:04 | | mode/#code [+o JackKnife] by ChanServ |
| 15:07 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has joined #code |
| 15:07 | | mode/#code [+o himi] by ChanServ |
| 15:16 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 15:18 | <@AnnoDomini> | Hmm. I have http://pastie.org/9000805 to determine locations of objects that travel along a circular path. But these paths do not match the projected path that I draw with an ellipse-drawing tool when I zoom up a lot. |
| 15:18 | <@AnnoDomini> | The orbits agree when I am zoomed out. As I near the point where the orbital path fragments appear more and more like straight lines, the actual path of the object is very jittery. |
| 15:19 | <@AnnoDomini> | They travel as if on a distorted sine wave. |
| 15:19 | <@AnnoDomini> | Any ideas what the problem might be? |
| 15:19 | <@ErikMesoy> | What's drawing the comparison path? |
| 15:20 | <@AnnoDomini> | A function provided by the Qt library, specifically addEllipse(). |
| 15:29 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has joined #code |
| 15:29 | | mode/#code [+o himi] by ChanServ |
| 16:16 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 16:29 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has joined #code |
| 16:29 | | mode/#code [+o himi] by ChanServ |
| 16:40 | | Thalass [thalass@Nightstar-90oetb.bigpond.net.au] has quit [Ping timeout: 121 seconds] |
| 16:55 | <@AnnoDomini> | Visual demonstration of what happens: https://www.youtube.com/watch?v=ALSVfx48zXw&feature=youtu.be |
| 17:23 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 17:36 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has joined #code |
| 17:36 | | mode/#code [+o himi] by ChanServ |
| 18:03 | <@RchrdB> | AnnoDomini, btw, cos() and cosf() in <math.h> are different functions. double cos(double), float cosf(float). |
| 18:03 | <@RchrdB> | (I don't think that that's got anything to do with it, though.) |
| 18:04 | <@RchrdB> | AnnoDomini, I'd be very unsurprised if Qt's ellipse-drawing function was *not* a fast, grungy approximation. >_> |
| 18:04 | <@RchrdB> | er |
| 18:04 | <@RchrdB> | very *surprised* if Qt's ellipse-drawing routing was not a fast, grungy approximation. |
| 18:07 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 18:09 | <@AnnoDomini> | I posted this to Stack Overflow, and one guy seems to agree with you - that the Qt's ellipse renderer fails miserably in this instance. |
| 18:21 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has joined #code |
| 18:21 | | mode/#code [+o himi] by ChanServ |
| 18:26 | <@RchrdB> | AnnoDomini, offhand, I think a postscript renderer would be required to have a really accurate ellipse-drawing function. |
| 18:55 | | Kindamoody|afk is now known as Kindamoody |
| 19:15 | | Turaiel[Offline] is now known as Turaiel |
| 19:44 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has joined #code |
| 19:44 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| 19:47 | | Turaiel is now known as Turaiel[Offline] |
| 19:52 | | Kindamoody is now known as Kindamoody[zZz] |
| 20:38 | | JackKnife [Z@Nightstar-ro94ms.balk.dk] has quit [Ping timeout: 121 seconds] |
| 20:54 | | Orthia [orthianz@Nightstar-3tp.juj.184.203.IP] has quit [Ping timeout: 121 seconds] |
| 20:55 | | gnolam [lenin@Nightstar-471pis.cust.bredbandsbolaget.se] has quit [A TLS packet with unexpected length was received.] |
| 20:55 | | gnolam [lenin@Nightstar-471pis.cust.bredbandsbolaget.se] has joined #code |
| 20:55 | | mode/#code [+o gnolam] by ChanServ |
| 21:37 | | celticminstrel [celticminst@Nightstar-mhtogh.dsl.bell.ca] has joined #code |
| 21:37 | | mode/#code [+o celticminstrel] by ChanServ |
| 21:38 | <@celticminstrel> | Okay, I'm not sure what sorts of issues cause the fail bit to be set on my stream... |
| 21:38 | <@celticminstrel> | (While opening the file.) |
| 21:39 | <&ToxicFrog> | Exceptions in __getitem__ or __getattr__ silently vanish. |
| 21:40 | <&ToxicFrog> | Fuck you too, python. |
| 21:44 | <&McMartin> | When you call hasattr() three times the King in Yellow comes for your soul |
| 21:44 | <&McMartin> | s/call/invoke/ |
| 21:44 | <@TheWatcher> | snrk |
| 21:54 | <@ErikMesoy> | Can you get around this with getattr()? |
| 21:56 | | * AnnoDomini reimplements ellipse drawing in Qt, unsurprisingly, this results in major lag. But at least the orbits look pretty now! |
| 22:01 | <@celticminstrel> | Okay, the issue was that I converted the relative path to an absolute path and then passed the relative path to the ifstream. Whoops. |
| 22:08 | <@celticminstrel> | Hm, my approach to making a window modal doesn't seem to be working. Do I need a thread for the window being blocked? It seems I might... |
| 22:09 | <@celticminstrel> | (The approach is "if the blocked window receives an event, bring the modal window to the front".) |
| 22:09 | <@celticminstrel> | (And currently I'm polling for events in the blocked window whenever the modal window doesn't get an event.) |
| 22:21 | <@RchrdB> | ToxicFrog, uh, no they don't always? AttributeError raised from __getattribute__() is swallowed and then a call to __getattr__() is made, but the others don't. |
| 22:21 | <@RchrdB> | ToxicFrog, https://gist.github.com/anonymous/10059518 |
| 22:29 | | ErikMesoy is now known as ErikMesoy|sleep |
| 22:44 | <@celticminstrel> | Hm, apparently I'm not allowed to process events outside the main thread, |
| 22:44 | <@celticminstrel> | ^. |
| 22:45 | <@celticminstrel> | What's the thing that every Java object is that involves a notify() method? |
| 22:46 | <&McMartin> | A condition variable. |
| 22:46 | <&McMartin> | Which are, incidentally, rather tricky to use right |
| 22:50 | <@celticminstrel> | Okay, so it looks like constructing an std::thread also initiates execution. |
| 22:55 | <@celticminstrel> | A condition variable probably doesn't need to be declared volatile, right? |
| 22:59 | <&McMartin> | Is this part of std? |
| 22:59 | <&McMartin> | Check the docs -_- |
| 22:59 | <&McMartin> | I put nothing past C++ |
| 22:59 | <@celticminstrel> | It's C++11 stuff. |
| 23:00 | <&McMartin> | It "shouldn't" |
| 23:00 | <&McMartin> | It should instead have volatile members |
| 23:00 | <@celticminstrel> | I see nothing implying it should need to be, and the example doesn't do it. |
| 23:00 | <&McMartin> | Then nah |
| 23:00 | <@celticminstrel> | Okay, so... |
| 23:01 | <@celticminstrel> | Need to figure out the flow here... |
| 23:01 | <&McMartin> | This is where CVs get tricky. |
| 23:02 | <&McMartin> | Externally, there's a mutex that's "part of" the CV. You have to acquire the mutex, and be holding it when you call either wait() or notify(). |
| 23:02 | <@celticminstrel> | I guess that means the mutex needs to be the same in both threads. |
| 23:02 | <&McMartin> | Yes. It's traditionally treated as "part of" the condition variable. |
| 23:03 | <&McMartin> | Java did a pretty good job of hiding that part. |
| 23:03 | <@celticminstrel> | The wait methods here require a lock as an argument, and the mutex is an argument to the lock. |
| 23:06 | <@celticminstrel> | Locking the mutex as the first action in both threads sounds like the wrong plan. |
| 23:06 | <&McMartin> | It's the right one |
| 23:06 | <@celticminstrel> | It is? |
| 23:07 | <&McMartin> | The act of waiting needs to *atomically* release the lock and go to sleep. |
| 23:07 | <&McMartin> | Otherwise there's the risk that the notify will slip in before lock release and going to sleep, and then you'll have gone to sleep after the alarm went off, and will sleep forever. |
| 23:07 | <@celticminstrel> | They can both lock it at the same time? |
| 23:08 | <&McMartin> | No. |
| 23:08 | <&McMartin> | They have to run in sequence. |
| 23:08 | <&McMartin> | In particular, the one that waits has to run first. |
| 23:09 | <&McMartin> | The correct sequence is: |
| 23:09 | <&McMartin> | Waiter locks mutex |
| 23:09 | <&McMartin> | Notifier tries to lock mutex, goes to sleep |
| 23:09 | <&McMartin> | Waiter goes to sleep, releasing mutex atomically as part of that act |
| 23:09 | <&McMartin> | Notifier wakes up, sends notification |
| 23:09 | <&McMartin> | Waiter wakes up, tries to regrab mutex, goes back to sleep because notifier has it |
| 23:09 | <&McMartin> | Notifier does any cleanup required, releases mutex |
| 23:10 | <&McMartin> | Waiter gets mutex, probably releases it right afterwards |
| 23:10 | <@celticminstrel> | I'm not quite sure if the old thread is suspended when a new thread is started. Also I need to figure out which is the notifier and which is the waiter. |
| 23:11 | <@celticminstrel> | It's not constant, is it... |
| 23:11 | <@celticminstrel> | They swap roles... |
| 23:11 | <&McMartin> | It is not obvious to me that CVs are what you want here |
| 23:11 | <&McMartin> | You sound like you want something more like channels. |
| 23:11 | <&McMartin> | Where if the notifier sends a notify, the waiter's "wait" will be a no-op if it happens later, and any value is available for immediate consumption |
| 23:11 | <&McMartin> | ...look into semaphores. |
| 23:12 | <@celticminstrel> | Hm. |
| 23:13 | <@celticminstrel> | I suppose this is sort of like the "consume/produce" pattern; main thread produces events, subthread consumes them. |
| 23:13 | <&McMartin> | You don't need anything more for that than a mutex and a queue it protects. |
| 23:13 | <@celticminstrel> | Can it be done without a queue? |
| 23:13 | <@celticminstrel> | (Equivalently, a queue of size one.) |
| 23:14 | <&McMartin> | Traditionally, produce/consume does not do this |
| 23:14 | <&McMartin> | But it can. UQM does limit its queue size. |
| 23:14 | <&McMartin> | But man, that code is 10 years old now and was bad then. -_- |
| 23:15 | <@RchrdB> | McMartin, limits on queue sizes are pretty common to stop producers from endlessly burning RAM buffering up more stuff that a slow consumer can't eat quickly enough. |
| 23:15 | <&McMartin> | Yeah |
| 23:15 | <@RchrdB> | That is not in any way a fault in UQM. |
| 23:15 | <&McMartin> | That part isn't |
| 23:17 | <@celticminstrel> | Okay so... |
| 23:17 | <@celticminstrel> | Then I just need to lock before accessing and unlock after accessing, right? |
| 23:17 | <@RchrdB> | I can't think of any sensible cases where you would want a completely unbounded queue⦠not even in a system where the producer has to hit real-time guarantees, since a fast producer could accidentally enqueue so much stuff as to attract the ORM killer's attention and nuke the process, missing *all* its deadlines forever. |
| 23:18 | <@RchrdB> | celticminstrel, mmmmhmmm. And be aware that, <lock> *do A()* <unlock> <lock> *do B()* <unlock> isn't atomic. *do A()* will be atomic and *do B()* will be, but the pair together won't because locks don't compose. |
| 23:19 | <&McMartin> | RchrdB: The UQM code tended to livelock anyway so it also has code that does frame-breaking after a certain number of primitives are processed even if it's keeping up |
| 23:20 | <@celticminstrel> | And if I do <lock> push() <unlock> <lock> pop() <unlock>, I'm guessing there's no guarantee that push() won't be called twice in succession. |
| 23:20 | <@celticminstrel> | (Both cases are in a loop.) |
| 23:20 | <@celticminstrel> | (And different threads.) |
| 23:21 | <@RchrdB> | celticminstrel, indeed. |
| 23:21 | <@celticminstrel> | Okay, then I need a queue. |
| 23:21 | <@celticminstrel> | Blargh. |
| 23:21 | <@RchrdB> | McMartin, "The UQM code tended to livelock" â aaaaa, run away screaming. |
| 23:21 | <&McMartin> | RchrdB: Well, it's the render thread |
| 23:22 | <&McMartin> | It was very easy for it to fall permanently behind |
| 23:22 | <&McMartin> | Especially in 2002~ |
| 23:22 | <@RchrdB> | Was it really worth putting rendering on a separate thread from the rest of the game when nobody had multiple cores or sockets anyway? |
| 23:23 | <&McMartin> | celticminstrel: IIRC, we used locks to keep the queue intact, condition variables that would notifyAll on the conditions of queue empty or queue full, and semaphores that you put *in* the queue for the instruction "I want to sleep until everything I've asked for has been drawn". |
| 23:23 | <@Azash> | http://heartbleed.com |
| 23:23 | <&McMartin> | RchrdB: That was not our choice; the initial code was extremely multithreaded. |
| 23:23 | <&McMartin> | That said, yes, it is an excellent idea to do this, because it means your physics is independent of your framerate. |
| 23:24 | <&McMartin> | This is a desirable property |
| 23:24 | <@RchrdB> | What? No, it isn't. |
| 23:24 | <@celticminstrel> | But I don't need a condition variable, do I? |
| 23:24 | <@RchrdB> | It's actively undesirable on multiple levels. |
| 23:24 | <&McMartin> | Your physics should have a fixed timestep. |
| 23:25 | <@celticminstrel> | I don't need to worry about that here in BoE, since it's turn-based. |
| 23:25 | <@RchrdB> | Firstly, you make physics be framerate-independent by using a fixed timestep, accumulating time and then ditching it in discrete fixed-size chunks. |
| 23:25 | <&McMartin> | Yes |
| 23:25 | <@RchrdB> | None of which involves threading in any way. |
| 23:25 | <&McMartin> | It would, in fact, be possible to write UQM in a way that did this |
| 23:25 | <@celticminstrel> | So it's a desirable property but not necessarily a good way of doing it. |
| 23:25 | <&McMartin> | In case you forget, we didn't write UQM. |
| 23:26 | <@RchrdB> | McMartin, yeah, yeah, not blamestorming, just head-scratching. |
| 23:26 | <@RchrdB> | Did the original authors think it was going to be easier or something? |
| 23:26 | <&McMartin> | The original code used the 3DO's threading mechanisms quite extensively and one of my major projects in, IIRC, 0.4 was to patch in stuff that made SDL threads behave the way 3DO threads apparently did. |
| 23:27 | <&McMartin> | Hell, that could have gone back to DOS since you can hijack the clock interrupt trivially for in-process taskswitching. |
| 23:27 | <@Azash> | McMartin: Something for you? https://helloworldopen.com/ |
| 23:27 | <@RchrdB> | McMartin, this still doesn't sound like a good way to write software. |
| 23:27 | <&McMartin> | And yes, they generally spawned threads to do ambient animations and a dozen other things. We ultimately dropped it to three; event processing (render/UI thread), game logic, and audio decoder. |
| 23:28 | <@celticminstrel> | Alright, I think I have this right now, hopefully. |
| 23:28 | <&McMartin> | Is your objection to threading in general or this use of it? |
| 23:28 | <@RchrdB> | McMartin, this use of it! |
| 23:28 | <&McMartin> | OK |
| 23:28 | <@RchrdB> | well |
| 23:28 | <@celticminstrel> | I find it slightly annoying that the pop() methods in std::stack and std::queue don't return the element being popped. |
| 23:28 | <&McMartin> | It's, um, pretty common to have all the actual work of a UI-based program happen in threads that are not the one that has main() in it. |
| 23:29 | <@RchrdB> | True, but that's a different use case again. |
| 23:29 | <&McMartin> | ... no it isn't? |
| 23:30 | <&McMartin> | Are you under the impression that UQM has some kind of generic engine underneath it that reads the entire game as configuration and plugin scripts? |
| 23:30 | <@RchrdB> | It really is completely different. |
| 23:30 | <&McMartin> | OK, what do you think you're distinguishing here |
| 23:31 | <@RchrdB> | A videogame's goal is to, every 16ms, compute one frame, check the state of all the joysticks, post a result to screen. |
| 23:31 | <@celticminstrel> | Not necessarily? |
| 23:31 | <&McMartin> | Yeah, that isn't how they did it. |
| 23:32 | <@Azash> | http://i.imgur.com/GHxmrsR.jpg |
| 23:32 | <@RchrdB> | A GUI app's goal is to do some bulk computation that takes multiple seconds to run, and also present a GUI that responds to user clicks. |
| 23:32 | <&McMartin> | (And at least three points of the code were clearly "this takes more than one frame to compute so, um, just update this as fast as you can with all spare CPU cycles") |
| 23:34 | <@RchrdB> | McMartin, what were those? |
| 23:34 | <&McMartin> | "ambient animation effects" like the planet rotating in the scan view |
| 23:34 | <&McMartin> | We folded those into the "do things" loop. |
| 23:34 | <@RchrdB> | So the planets spin faster the quicker your CPU is? |
| 23:34 | <&McMartin> | That was in fact the case in the original, yes. |
| 23:35 | <&McMartin> | Because on my 386 it spun at like one tick every couple of seconds. |
| 23:36 | <@RchrdB> | Okay, there's a case to be made for putting background tasks like that onto a separate thread that's prio'd down so that it gets woken up only in the intervals while you're waiting for the next vsync. |
| 23:36 | <@RchrdB> | The alternative would be to shit all over that computation with logic that constantly checks whether or not it's time to go back to the main game⦠which would obviously be worse. |
| 23:36 | <&McMartin> | So, that's the other thing; you don't actually wait for vsync anymore, and even if you think you are, you might not be because the GPU may be lying to you under external orders. |
| 23:37 | <@RchrdB> | Don't bring 2014 into it when we're talking about ~1990. |
| 23:37 | <&McMartin> | Well, that's the other part |
| 23:38 | <&McMartin> | If we're talking about 1990, the concept of "frame" is a little dodgy because you have total framebuffer control |
| 23:38 | <&McMartin> | And they used that too; we have to put a screen simulator in because it expects to be able to submit incremental updates. |
| 23:38 | <@RchrdB> | Ah, no double-buffering? |
| 23:38 | <&McMartin> | A000:0000 or bust |
| 23:39 | <&McMartin> | We have, um, treble buffering in our system at the end because the 3DO had some kind of support for hardware crossfading |
| 23:39 | <&McMartin> | So the game draws to one layer, which might be copied to a crossfade layer, and then we draw system dialogs on top of those. |
| 23:40 | <@RchrdB> | Cool. |
| 23:41 | <&McMartin> | The funniest part is that the thing that shreds performance the most is the MOD decoder. |
| 23:41 | <&McMartin> | MOD decoders these days add a fuckton of cubic interpolation and upsampling and will happy peg every core of an i7 if you let it. |
| 23:41 | <&McMartin> | *happily |
| 23:42 | <@RchrdB> | I thought mikmod was blazingly fast on 486es. |
| 23:42 | <&McMartin> | It is. |
| 23:42 | <&McMartin> | If you turn that stuff off. |
| 23:42 | <&ToxicFrog> | RchrdB: so, the issue I was having is that I had an object, and I had another object wrapping it that forwarded __getattr__ and __getitem__ both to __getattr__ on the wrapped object |
| 23:43 | <&ToxicFrog> | And then had a bunch of @property methods for stuff that uses multiple underlying fields, etc |
| 23:43 | <@RchrdB> | ToxicFrog, yep. |
| 23:43 | <@RchrdB> | Ah, how do descriptors and __getattr__ mix? *look up* |
| 23:44 | <&ToxicFrog> | And if I had an error in one of the @properties, the error message I would get is not (say) KeyError with a stack trace pointing at (say) Wrapper.feature_list, but "AttributeError: Wrapped has no attribute 'feature_list'" |
| 23:44 | <&ToxicFrog> | Fix the error in the @property method and suddenly everything starts working. |
| 23:44 | <&ToxicFrog> | I can't reproduce this locally, but I may have a go at making a minimal reproduction when I'm back at work tomorrow. |
| 23:45 | <&ToxicFrog> | I note that my forwarding was: try: return getattr(self, key); except AttributeError: return getattr(self._wrapped, key) |
| 23:46 | <&ToxicFrog> | So if I understand my python exception handling, that shouldn't swallow anything except AttributeErrors in the wrapper class. |
| 23:49 | | celticminstrel [celticminst@Nightstar-mhtogh.dsl.bell.ca] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] |
| 23:49 | <@RchrdB> | raise'ing AttributeError *inside* an @property getter causes⦠ugh, the documentation is too twisty, look at the code instead. |
| 23:58 | <@RchrdB> | PyObject_GetAttrString(v, str) calls o->ob_type->tp_getattr(v, str). There's also a ->tp_getattro(v, str) for if str happens to be wanted as a PyObject* instead of as a char*⦠|
| --- Log closed Tue Apr 08 00:00:35 2014 |