| --- Log opened Fri Nov 29 00:00:52 2013 |
| 00:01 | | You're now known as TheWatcher |
| 00:07 | | Turaiel[Offline] [Brandon@Nightstar-vku52k.resnet.mtu.edu] has quit [[NS] Quit: Bouncer terminated] |
| 00:17 | | Vornicus [vorn@Nightstar-sn7kve.sd.cox.net] has quit [[NS] Quit: ] |
| 00:26 | | himi [fow035@Nightstar-q9amk4.ffp.csiro.au] has joined #code |
| 00:26 | | mode/#code [+o himi] by ChanServ |
| 01:01 | | You're now known as TheWatcher[T-2] |
| 01:09 | | You're now known as TheWatcher[zZzZ] |
| 01:29 | | Vornicus [vorn@Nightstar-sn7kve.sd.cox.net] has joined #code |
| 01:29 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| 01:32 | | Vornotron [Vorn@Nightstar-sn7kve.sd.cox.net] has quit [Connection reset by peer] |
| 02:06 | | Turaiel[Offline] [Brandon@Nightstar-vku52k.resnet.mtu.edu] has joined #code |
| 02:06 | | Reiv [NSwebIRC@Nightstar-95746c1f.kinect.net.nz] has quit [Ping timeout: 121 seconds] |
| 02:11 | | AnnoDomini [abudhabi@Nightstar-4ji.fl3.98.208.IP] has quit [Connection closed] |
| 02:24 | < RichyB> | Ugh |
| 02:24 | < RichyB> | Complex multithreading bit with various invariants |
| 02:24 | < RichyB> | and it's the trivial linked-list implementation that I mess up instead |
| 02:30 | < RichyB> | hmmm, looks like I also got all of the rest of it wrong, too. |
| 02:31 | | io\parents is now known as iospace |
| 03:31 | | Turaiel[Offline] is now known as Turaiel |
| 03:47 | | mac [NSwebIRC@Nightstar-2dbe3d64.il.comcast.net] has joined #code |
| 04:04 | | VirusJTG [VirusJTG@Nightstar-6i5vf7.sta.comporium.net] has quit [Connection closed] |
| 04:06 | < [R]> | While waiting for the bus, I overhead a man of great intellect. |
| 04:06 | < [R]> | He said "calling me a pussy is like calling a nigger a nigger" |
| 04:07 | < Syka> | ...I am not sure what he was trying to get across |
| 04:08 | < [R]> | It ends with "you're going to get beat up." |
| 04:09 | < [R]> | Ultimately though, it was a poor choice of words. |
| 04:21 | | Kindamoody[zZz] is now known as Kindamoody |
| 05:02 | | Stalker [Z@Nightstar-484uip.cust.comxnet.dk] has joined #code |
| 05:24 | | RichyB [RichyB@Nightstar-c6u.vd5.170.83.IP] has quit [[NS] Quit: Gone.] |
| 05:27 | | RichyB [RichyB@Nightstar-c6u.vd5.170.83.IP] has joined #code |
| 05:27 | | mac [NSwebIRC@Nightstar-2dbe3d64.il.comcast.net] has quit [[NS] Quit: Page closed] |
| 05:46 | | Syka [the@Nightstar-iqga6o.iinet.net.au] has quit [Ping timeout: 121 seconds] |
| 05:50 | | ErikMesoy|sleep is now known as ErikMesoy |
| 06:07 | | Syka [the@Nightstar-19nmr3.iinet.net.au] has joined #code |
| 06:52 | <@froztbyte> | http://www.pouet.net/prod.php?which=61298 |
| 06:53 | | * McMartin does some screen memory hacking |
| 06:54 | <~Vornicus> | People do crazy things in 256 bytes |
| 06:57 | <&McMartin> | This is going to be two whole K |
| 06:58 | <&McMartin> | Also I'm going to do some raster hacking to change the background color twice mid-frame. |
| 07:06 | <@froztbyte> | Vornicus: it's pretty awesome :) |
| 07:11 | | abudhabi [abudhabi@Nightstar-4ji.fl3.98.208.IP] has joined #code |
| 07:12 | <&McMartin> | Ah yes, the raycaster |
| 07:12 | <&McMartin> | That is pretty boss |
| 07:12 | <&McMartin> | Hrm |
| 07:12 | <&McMartin> | OK, now I have to edit this more |
| 07:13 | <&McMartin> | My parents think the moon isn't round enough |
| 07:13 | | * McMartin breaks out GRAPH PAPER AND COMPASS |
| 07:16 | <~Vornicus> | Low-res circles are a pain in the ass. |
| 07:17 | <@froztbyte> | today's lulz courtesy of http://motherfuckingwebsite.com/ |
| 07:18 | <~Vornicus> | "This site doesn't care if you're on an iMac or a motherfucking Tamagotchi." |
| 07:20 | | himi [fow035@Nightstar-q9amk4.ffp.csiro.au] has quit [Ping timeout: 121 seconds] |
| 07:25 | < simon> | heh |
| 07:32 | <&jerith> | RichyB: It's 2013. Why are you writing a linked list implementation? |
| 07:32 | <&McMartin> | Classes demand it! |
| 07:32 | <&McMartin> | Also, I totally wrote my own red-black tree for Monocle, and I may need to throw in a linked list at some point too |
| 07:34 | <&jerith> | McMartin: Aren't there high-quality implementations you can just drop in? |
| 07:43 | | Kindamoody is now known as Kindamoody|out |
| 07:49 | <&McMartin> | jerith: It doesn't take a Hell of a lot to be a high-quality linked list |
| 07:49 | <&McMartin> | And there are reliable ones, but they are made of gigantic piles of horrible preprocessor macros. |
| 07:49 | <&McMartin> | I ultimately used those to fuzz-test and cross-check my implementation based on single inheritance and no preprocessor garbage instead of the intrusive-pointer version. |
| 07:49 | <&McMartin> | (It's BSD's sys/tree.h) |
| 07:50 | <&jerith> | Ah. |
| 07:50 | <&McMartin> | Also, Monocle is my mega-Not-Invented-Here playground :D |
| 07:51 | <&McMartin> | Er, I missed a "and there are reliable red-black tree implementations, but" |
| 07:52 | <&jerith> | McMartin: You missed a fantastic opportunity to NIH SDL out of it...~ |
| 07:52 | <&McMartin> | It's up to SDL2 now! |
| 07:52 | <&McMartin> | And no, SDL2 took two decades of work to do, I cannot replicate that |
| 07:53 | <&jerith> | Ooh! That menas I should try Python-wrap it on my mac sometime. |
| 07:54 | <&McMartin> | Possibly |
| 07:54 | <&McMartin> | I couldn't even get the damn thing to build on Mac but that is because Mac dynlinking is hot garbage |
| 07:55 | <&McMartin> | And fixing your DLL load paths involves literally hacking the binary and hoping that this doesn't overflow buffers with no guaranteed minimum size |
| 07:56 | <&McMartin> | Perhaps that is easier if you do Xcode integration right |
| 07:56 | <&McMartin> | But it doesn't seem to have a good equivalent to -Wl,-rpath,. |
| 08:28 | | Vornicus [vorn@Nightstar-sn7kve.sd.cox.net] has quit [[NS] Quit: ] |
| 08:33 | | Xon [Xon@Nightstar-q4s.ku7.252.119.IP] has quit [[NS] Quit: ] |
| 08:35 | | Xon [Xon@Nightstar-q4s.ku7.252.119.IP] has joined #code |
| 08:39 | | * McMartin blasts the rasters! |
| 08:50 | <&McMartin> | Ugh, I'm still getting some flicker here, I was hoping to not have to do IRQ hacking but I think I'll have no choice. |
| 09:03 | | * simon is wondering: in Portal, the game, once you introduce a pair of portals, this appears to still be a metric space. |
| 09:04 | < simon> | but if you consider the space of all the possible spaces where two portals are repositioned, is this a metric space? |
| 09:04 | < simon> | (I'm not sure the question is meaningful.) |
| 09:05 | <&McMartin> | IIRC Portal has one "impossible room" |
| 09:05 | < simon> | actually, considering relativity, if you only look at three dimensions, they're not a matric space, right? I mean, depending on your velocity, the path might be longer or shorter. |
| 09:06 | < simon> | McMartin, I'm not sure what an impossible room is. |
| 09:06 | < simon> | but spacetime is a metric space. |
| 09:06 | <&McMartin> | If you treat the map as a subset of Euclidean three-space, there is a volume within it that is part of two entirely different rooms. |
| 09:06 | < simon> | since relativity can be viewed as going into a time-valley or a time-hill. |
| 09:07 | < simon> | McMartin, I don't get that. |
| 09:08 | < simon> | do you mean to say that you can construct a Portal game where the map, given positions of portals, does not correspond to a subset of Eucledean three-space? |
| 09:08 | < simon> | Euclidean* |
| 09:09 | <&McMartin> | No |
| 09:09 | <&McMartin> | I mean, in the absence of portals, it fails to do this in one subvolume. |
| 09:13 | < simon> | is this the part where you have two rooms that are not connected in any other way than through portals? |
| 09:13 | <&McMartin> | No |
| 09:13 | <&McMartin> | Well. |
| 09:13 | <&McMartin> | No, in-universe. |
| 09:14 | <&McMartin> | In-engine, you are portaling around like a teleporting pinball, because they made no attempt to make the map properly connect if you ran it all together |
| 09:14 | | Turaiel is now known as Turaiel[Offline] |
| 09:14 | <&McMartin> | But it *mostly* works anyway. |
| 09:14 | <&McMartin> | Except for one spot. |
| 09:14 | <&McMartin> | Marathon, meanwhile, deliberately exploited this property to make geometrically impossible chambers. |
| 09:18 | <&McMartin> | It's been too long since I've done real analysis and multivariate calculus. |
| 09:19 | <&McMartin> | It does not seem to me to be the case that path integrals of appropriate distance functions will be constant across all paths in the presence of portals. |
| 09:19 | <&McMartin> | But I'm not sure if that's a requirement. |
| 09:24 | < simon> | I think I understand the impossible room. |
| 09:25 | < simon> | basically, the destination portal couldn't have ended up inthere by use of the portal gun. that's it, right? |
| 09:25 | <&McMartin> | No; the impossible room doesn't involve portals in any way |
| 09:25 | <&McMartin> | Let's see if I can construct a simpler example |
| 09:26 | < simon> | I read and watched http://gaming.stackexchange.com/questions/20601/where-is-the-impossible-space-in -portal-2 -- but this might be something else entirely? |
| 09:26 | <&McMartin> | +--+ |
| 09:26 | <&McMartin> | | | |
| 09:26 | <&McMartin> | ---+--+ |
| 09:26 | <&McMartin> | | |
| 09:26 | <&McMartin> | | |
| 09:26 | <&McMartin> | Imagine that this is all in a 2D space |
| 09:26 | <&McMartin> | And that while walking west to east you are in a seamless corridor |
| 09:27 | <&McMartin> | And that while walking north to south you are *also* in a seamless corridor |
| 09:27 | < simon> | ahhhh. |
| 09:27 | <&McMartin> | Location (4,2) is an "impossible room" |
| 09:28 | <&McMartin> | And yeah, ISTR that Portal 2 had one on purpose because it's tradition |
| 09:28 | <&McMartin> | And I also STR that these do, under the hood, involve invisible silent portals that look like doors or hallways |
| 09:28 | <&McMartin> | Because the Source engine requires you to exist in Euclidean threespace |
| 09:29 | <&McMartin> | (The Marathon engine did not; rooms were defined by the connector you went through to enter them.) |
| 09:29 | <&McMartin> | (So situations like the one I described above were *rampant* unless you were trying very hard to make them not happen, and the Marathon level designers not only weren't trying hard to avoid them, they were deliberately engineering them and selling it as a feature.) |
| 09:30 | | You're now known as TheWatcher |
| 09:31 | < simon> | ah. |
| 09:32 | < simon> | so... using portals still makes it a metric space, but one with impossible rooms in it. |
| 09:32 | < simon> | or a "non-trivial topology" :P |
| 09:33 | < simon> | it makes me think that the actual space is greater than the corresponding variant without portals. which makes me wonder what the dimensionality of three-space + portals is. |
| 09:34 | <&McMartin> | That's above my pay grade. |
| 09:34 | < simon> | since any point (given the right map) could be an impossible room, it is principally different from a room with the same coordinates in another seamless corridor, which means the space has at least one more point. if you consider all possible combinations of portal start-points and end-points you get a lot of extra points in this space |
| 09:34 | < simon> | so my roommate argued in the shower that it'd have to be infinitely dimensional. but I don't understand that at all. |
| 09:36 | <&McMartin> | https://hkn.eecs.berkeley.edu/~mcmartin/retro/river1.zip <-- So, should my next task be to try to get rid of the flicker, or to get scrolling text working at the bottom? |
| 09:37 | < simon> | McMartin, what format is it? |
| 09:38 | <&McMartin> | That's a C64 program, it'll run in VICE's x64 and probably also in other emulators |
| 09:38 | <&McMartin> | But I'm doing one piece of heinous cheating with the VIC-II and so it will need proper raster simulation to display right. |
| 09:39 | <&McMartin> | It is *almost* the case that the image I made can be typed in at the keyboard. Almost. |
| 09:39 | <&McMartin> | It's pretty obvious where I'm heinously cheating right now because it flickers occasionally. |
| 09:42 | < simon> | http://math.stackexchange.com/questions/137999/what-is-the-topology-of-a-world-w ith-portals -- apparently adding portals to R^3 is comparable to digging tunnels in R^4. so only one extra dimension is needed. yay! |
| 09:42 | < simon> | (and the only reason it isn't comparable to digging tunnels in R^3 is that you can have a portal on a floating platform, which you can't dig your way to otherwise.) |
| 09:49 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has joined #code |
| 09:49 | | mode/#code [+o himi] by ChanServ |
| 09:53 | < simon> | except, hmm, I'm not sure how to represent impossible spaces that way. |
| 09:54 | <&McMartin> | Do it the way Source does; one of the entrances to the impossible space is actually a 4D tunnel to a totally different place. |
| --- Log closed Fri Nov 29 10:07:36 2013 |
| --- Log opened Fri Nov 29 10:07:44 2013 |
| 10:07 | | TheWatcher [chris@Nightstar-ksqup0.co.uk] has joined #code |
| 10:07 | | Irssi: #code: Total of 36 nicks [15 ops, 0 halfops, 0 voices, 21 normal] |
| 10:07 | | mode/#code [+o TheWatcher] by ChanServ |
| 10:08 | <&McMartin> | You'll only need to export the ones you use. :D |
| 10:08 | | Irssi: Join to #code was synced in 38 secs |
| 10:08 | <&jerith> | McMartin: pymonocle kinds of needs to export them all. :-/ |
| 10:09 | <&jerith> | Actually... |
| 10:09 | <&jerith> | I wonder if I can get cffi to do the heavy lifting for me. |
| 10:10 | <&jerith> | Oh, I had to replace all the "gcc" with "cc" in the makefile to get it to build on my system. |
| 10:10 | <&McMartin> | You're probably using clang under the hood now. |
| 10:10 | <&jerith> | I only have the standalone CLT package installed, not the whole of xcode. |
| 10:10 | | * McMartin updates river1.zip, now with the flicker gone. |
| 10:10 | <&jerith> | So gcc invokes xcrun which explodes. |
| 10:10 | <&McMartin> | Take that, keyboard and timer interrupts! |
| 10:58 | <&jerith> | Looking up ~250 enum values at compile-time takes a while. :-/ |
| 11:06 | <&jerith> | I don't seem to be getting any music playing. |
| 11:07 | <&jerith> | Has anything in the mixer stuff changed since the old SDL1 version? |
| 11:07 | <&jerith> | Apart from mncl_play_music() -> mncl_play_music_file(), that is. |
| 11:10 | <&jerith> | Hoom. Fullscreen does /strange/ things. |
| 11:15 | <&jerith> | sfx works fine, music doesn't. |
| 11:21 | <&jerith> | McMartin: Your compiles earthball demo seems to be broken. |
| 11:21 | <&jerith> | *compiled |
| 11:21 | <&jerith> | It's apparently not finding any of its resources. |
| 11:24 | <&jerith> | Oh, it wants them in the current directory. |
| 11:24 | <&jerith> | But it tries to load libraries with a relative path. |
| 11:24 | <&McMartin> | It does indeed, that's what -Wl,-rpath,. does |
| 11:24 | <&McMartin> | That means "load DLLs from ." |
| 11:25 | <&McMartin> | the makefile should be copying resources into the place it needs to be in bin. |
| 11:25 | <&jerith> | Is that the library stuff you were talking about? |
| 11:25 | <&jerith> | The resources are in bin, but it's looking for them in ".". |
| 11:25 | <&McMartin> | The executables should also be in bin. |
| 11:26 | <&McMartin> | I don't think ELF lets you set it to $EXEDIR. |
| 11:26 | <&jerith> | So ./bin/earthball fails to find them and (cd bin; ./earthball) fails to find the libs. |
| 11:26 | <&McMartin> | The lib should *also* be getting copied into bin. |
| 11:26 | <&jerith> | (monocle)[13:23|jerith@minbar] ~/code/monocle% (cd bin; ./earthball) |
| 11:26 | <&jerith> | dyld: Library not loaded: bin/libmonocle.so Referenced from: /Users/jerith/code/monocle/bin/./earthball Reason: image not found |
| 11:27 | <&McMartin> | Something in the transition from ELF to Mach-O has messed this up. |
| 11:27 | <&jerith> | Except without irssi merging those lines. |
| 11:27 | <&jerith> | It might be llvm's linker instead of gcc's or something stupid. |
| 11:28 | <&McMartin> | mcmartin@osmium:~/devel/monocle/bin$ ldd earthball linux-vdso.so.1 => (0x00007fff335ff000) libmonocle.so => ./libmonocle.so (0x00007f75b2f56000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f75b2b7d000) libSDL2-2.0.so.0 => /usr/local/lib/libSDL2-2.0.so.0 (0x00007f75b2879000) |
| 11:28 | <&McMartin> | And then many other lines |
| 11:29 | <&jerith> | I don't seem to have ldd. |
| 11:29 | <&McMartin> | It's an ELF thing. |
| 11:29 | <&McMartin> | I think it's otool on OSX? |
| 11:30 | <&McMartin> | dylibs work fundamentally differently from .so files - in particular, LD_PRELOAD semantics don't work with them because they have their own notion of interposition. |
| 11:30 | <&jerith> | (monocle)[13:30|jerith@minbar] ~/code/monocle% otool -L bin/earthball |
| 11:30 | <&jerith> | bin/earthball: bin/libmonocle.so (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0) |
| 11:31 | <&McMartin> | sounds like it might want to be built while the pwd is itself bin. -_- |
| 11:32 | <&McMartin> | And of course in a real application you'd want it to go into the app bundle appropriately. |
| 11:33 | <&jerith> | Everything's relative paths. :-/ |
| 11:33 | <&McMartin> | I vaguely recall a binary rewriter tool that lets you change those |
| 11:33 | <&McMartin> | I also vaguely recall that it trashes important data if you try to make paths *longer*. |
| 11:33 | <&jerith> | Anyway, the music doesn't play with the compiled earthball either. |
| 11:34 | <&jerith> | So it's not something I'm doing wrong in pymonocle. |
| 11:34 | <&McMartin> | Yeah |
| 11:34 | <&McMartin> | The short answer to this is "fuck Mac development forever" and let XCode handle it all |
| 11:34 | <&jerith> | Maybe the makefile should use absolute paths or something? |
| 11:34 | <&McMartin> | Then you can never relocate the binary |
| 11:35 | <&McMartin> | And it will have your $HOME expanded in the binary and then fail to load it on anybody else's system |
| 11:35 | <&jerith> | Ah. |
| 11:35 | <&jerith> | Hrm. |
| 11:35 | <&jerith> | Well, for includes and such at least. |
| 11:36 | <&McMartin> | Yeah |
| 11:36 | <&McMartin> | Compiled graphical programs aren't supposed to work. =P |
| 11:36 | <&jerith> | Or just statically link libmonocle. |
| 11:36 | <&jerith> | It's not like it's huge. |
| 11:36 | <&McMartin> | You're supposed to have a proper .app bundle and then link it against a piece of it inside Frameworks. |
| 11:37 | <&McMartin> | You're also supposed to copy over things like SDL2 so that it never uses system libraries that Apple didn't write. |
| 11:38 | <&McMartin> | Basically, I need someone who knows XCode forwards and backwards to use it to create a Monocle.framework that can then be linked in appropriately and then have that produce Earthball.app |
| 11:40 | <&jerith> | Ah, found the music issue: |
| 11:40 | <&jerith> | ld: warning: ignoring file /usr/local/lib/libSDL2_mixer.dylib, file was built for x86_64 which is not the architecture being linked (i386): /usr/local/lib/libSDL2_mixer.dylib |
| 11:43 | <&McMartin> | ... that isn't an error? |
| 11:44 | <&jerith> | I think it means I'm not getting the mixer stuff because of an arch mismatch. |
| 11:44 | <&jerith> | Oh, that's not it. |
| 11:45 | <&jerith> | I'm getting it for all the SDL libs. |
| 11:45 | <&jerith> | C programming is hard. |
| 11:47 | <&jerith> | Maybe that just means I'm not getting a multiarch cffi wrapper. |
| 11:50 | <&jerith> | Hrm. earthball.py segfaults if it can't find its spritesheet. bin/earthball doesn't. |
| 11:51 | <&jerith> | Ah, there's a new API for that. |
| --- Log closed Fri Nov 29 11:59:04 2013 |
| --- Log opened Fri Nov 29 12:05:10 2013 |
| 12:05 | | TheWatcher [chris@Nightstar-ksqup0.co.uk] has joined #code |
| 12:05 | | Irssi: #code: Total of 35 nicks [14 ops, 0 halfops, 0 voices, 21 normal] |
| 12:05 | | mode/#code [+o TheWatcher] by ChanServ |
| 12:05 | | Irssi: Join to #code was synced in 38 secs |
| 12:07 | | Reiver [quassel@Nightstar-ksqup0.co.uk] has joined #code |
| 12:09 | | * jerith gives up and just rewrites the whole cdef thing. |
| 12:40 | | VirusJTG [VirusJTG@Nightstar-6i5vf7.sta.comporium.net] has joined #code |
| 13:34 | | Serah [Z@Nightstar-484uip.cust.comxnet.dk] has joined #code |
| 13:34 | | Stalker [Z@Nightstar-484uip.cust.comxnet.dk] has quit [Connection closed] |
| 13:47 | <&jerith> | McMartin: Would a PR to add a pymonocle/ directory to monocle be appropriate? |
| 13:48 | <&jerith> | It's very bare-bones for now, but earthball.py works happily. |
| 14:30 | | Pandemic [VirusJTG@Nightstar-6i5vf7.sta.comporium.net] has joined #code |
| 14:30 | | mode/#code [+o Pandemic] by ChanServ |
| 15:07 | < Syka> | hey jerith |
| 15:07 | < Syka> | jerith: I should show you my aludel-alike |
| 15:07 | < Syka> | I haven't got to the DB bit yet, but the API side is pretty fancy :D |
| 16:12 | | * RichyB briefly shakes his fist at munin |
| 16:12 | < RichyB> | what kind of silly person designs a config file format without an "include ./conf.d/*.cfg" |
| 16:14 | | Vornicus [vorn@Nightstar-sn7kve.sd.cox.net] has joined #code |
| 16:14 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| 17:49 | | ErikMesoy1 [Erik@Nightstar-ekm.o7n.203.80.IP] has joined #code |
| 17:50 | | ErikMesoy [Erik@Nightstar-3kot9q.80-203-17.nextgentel.com] has quit [NickServ (GHOST command used by ErikMesoy1)] |
| 17:50 | | ErikMesoy1 is now known as ErikMesoy |
| 17:54 | | abudhabi [abudhabi@Nightstar-4ji.fl3.98.208.IP] has quit [[NS] Quit: Lost terminal] |
| 17:54 | | abudhabi [abudhabi@Nightstar-4ji.fl3.98.208.IP] has joined #code |
| 18:03 | | abudhabi is now known as Sam |
| 18:32 | | Turaiel[Offline] is now known as Turaiel |
| 18:47 | | Vornicus [vorn@Nightstar-sn7kve.sd.cox.net] has quit [[NS] Quit: ] |
| 19:45 | | Sam [abudhabi@Nightstar-4ji.fl3.98.208.IP] has quit [[NS] Quit: Lost terminal] |
| 19:45 | | abudhabi [abudhabi@Nightstar-4ji.fl3.98.208.IP] has joined #code |
| 19:45 | < abudhabi> | Fucking irssi keeps freezing for no apparent reason. |
| 19:46 | | abudhabi is now known as Sam |
| 19:59 | <@Azash> | Do you use logging? |
| 19:59 | <@Tarinaky> | Bro, do you even log? |
| 20:07 | <@Tarinaky> | Dumb Python question. When iterating over a list or array with a for loop, is there an easy way to grab a 'block' at a time? |
| 20:08 | <@Tarinaky> | For example, if I have an array of 12 coordinates corresponding to 4x 3d vertexes and I'm iterating over the list in blocks of four? |
| 20:08 | <@Tarinaky> | Do I /need/ to wrap them in a tuple for readability? |
| 20:08 | <@Tarinaky> | Or is it sufficient to say for x,y,z in ... |
| 20:09 | < ErikMesoy> | You'll need tuples, or some funky condition on the iterator. |
| 20:09 | <@Tarinaky> | Lame :/ |
| 20:10 | < ErikMesoy> | For x,y,z in (list) is an error, I think |
| 20:12 | <&Derakon> | for i in xrange(len(list) / 3): x, y, z = list[i*3:i*3+3] |
| 20:12 | <&Derakon> | But you really should have a list of tuples in this situation. |
| 20:13 | <@Tarinaky> | Yeah. |
| 20:13 | <&Derakon> | Making a flat list doesn't help your performance and horribly mars your readability. |
| 20:13 | <@Tarinaky> | It means I need to do more mangling if I want to turn it into a vbo though. |
| 20:13 | <@Tarinaky> | But yeah. |
| 20:13 | <@Tarinaky> | List of tuples is the way forwards. |
| 20:13 | <&Derakon> | Alternately, if you have the X, Y, and Z coordinates each in their own lists (xCoords, yCoords, zCoords) then you can generate tuples with zip(): coords = zip(xCoords, yCoords, zCoords) |
| 20:22 | <@Tarinaky> | Wait. What the fuck. That worked first time. It must be broken. |
| 20:22 | <@Tarinaky> | (Ah the joys of refactoring code that resists unit testing) |
| 20:28 | < RichyB> | Derakon, you just advocate that because it's how you'd represent it in numpy. :) |
| 20:29 | <&Derakon> | Well, and? |
| 20:29 | < RichyB> | Just an observation. |
| 20:29 | <&Derakon> | Numpy and OpenGL have pretty strong integration. |
| 20:29 | < RichyB> | for x,y,z in some_damn_iterator: # in python is not necessarily an error, but it's an unpacking. |
| 20:30 | <@Tarinaky> | I assume that's undesirable? |
| 20:30 | <&Derakon> | No. |
| 20:30 | <@Tarinaky> | I thought unpacking was what I wanted >.< |
| 20:30 | <&Derakon> | It's just important to understand what you're doing. |
| 20:30 | < RichyB> | e.g. for x, y, z in [(1,2,3), (4,5,6)]: print x+y+z # will print "6" then "15" |
| 20:30 | <&Derakon> | Unpacking only works if the thing you're iterating over has the right shape. |
| 20:31 | <@Tarinaky> | Ah, right. |
| 20:31 | <&Derakon> | Otherwise you'll get an error like "ValueError: need more than 1 value to unpack". |
| 20:31 | <@Tarinaky> | So it has to be a tuple :p |
| 20:31 | <@Tarinaky> | *a list of tuples |
| 20:31 | < RichyB> | Derakon, would you really go with three vectors of floats rather than a single 2d array? |
| 20:31 | <&Derakon> | RichyB: not as a rule, no. |
| 20:31 | <&Derakon> | But Numpy likes to output such things. |
| 20:32 | <&Derakon> | E.g. the output of numpy.where() is a tuple of numpy arrays, one per axis. |
| 20:32 | <@Tarinaky> | Problem: ignoring graphics/rendering/view... |
| 20:32 | <@Tarinaky> | What kind of schema should an isometric tile have? |
| 20:33 | <@Tarinaky> | Because I have no ***ing idea. |
| 20:33 | <&Derakon> | How do you mean? |
| 20:34 | <@Tarinaky> | If I have a 2D map made up of rectangular 'tiles'. What... should an individual tile's schema look like... |
| 20:34 | <@Tarinaky> | I'm being a bit derpy with this but it always stumps me >.< |
| 20:34 | <&Derakon> | The isometric tile thing is just a way of looking at the map. |
| 20:34 | < RichyB> | Derakon, are there any decent python opengl bindings which use numpy arrays for all of the places where OpenGL asks you to pass in a vector of floats? |
| 20:34 | <&Derakon> | It shouldn't inform anything about how the internal data is structured. |
| 20:34 | <@Tarinaky> | By saying isometric I was trying to imply what I was using it for/driving with it. |
| 20:34 | <&Derakon> | RichyB: uh, dunno. I usually work in immediate mode. |
| 20:35 | | * RichyB sets Derakon on fire with his mind. |
| 20:35 | <&Derakon> | :p |
| 20:35 | | * Tarinaky at least has an excuse for working in immediate mode >.> |
| 20:38 | <@Tarinaky> | At the moment I'm thinking something like {position, blocking, material, walls} |
| 20:38 | <&Derakon> | Make the tile data a class. |
| 20:38 | <&Derakon> | Then you can stuff whatever you want into it. |
| 20:39 | <@Tarinaky> | I know. But having some kind of idea/plan helps avoid a mess >.> |
| 20:48 | | * Derakon ponders his map generation script, and specifically how to handle output. |
| 20:49 | <&Derakon> | Right now I'm just writing out HTML, but that scales kind of poorly, especially once I want to start providing tile-level resolution (currently only doing room-level). |
| 20:49 | <&Derakon> | Unfortunately image-writing libraries tend to be a pain in the ass to work with. |
| 20:50 | < RichyB> | Spit out a big string and a smallish javascript program that blits it onto a <canvas> |
| 20:50 | < RichyB> | :D |
| 20:50 | <&Derakon> | :p |
| 20:50 | < RichyB> | What are you writing in? |
| 20:51 | <&Derakon> | Python. |
| 20:51 | < RichyB> | If you're in Python, you'll probably find that PIL or Pillow have a perfectly acceptable API for use cases like "put these pixels into a PNG file on disk" |
| 20:51 | < RichyB> | there also exists pypng |
| 20:51 | <&Derakon> | PIL has IME been a pain in the ass to install. |
| 20:51 | <&Derakon> | Maybe it's improved lately though. |
| 20:52 | <&jerith> | Derakon: Pillow is a fork that exists only to make it installable. |
| 20:52 | < RichyB> | PIL is a fucking clusterfuck to install. |
| 20:52 | <&Derakon> | Will check out Pillow then. |
| 20:52 | < RichyB> | Pillow is a fork of PIL that does not change the API but |
| 20:52 | < RichyB> | yeah |
| 20:52 | <&Derakon> | "Pillow is the "friendly" PIL fork" |
| 20:52 | <&Derakon> | Yep. |
| 20:52 | <&jerith> | They don't accept any other changes. Just packaging and installability stuff. |
| 20:52 | < RichyB> | As far as I know, Pillow only actually has to do anything about PIL's broken setup.py, nothing else. |
| 20:53 | <&Derakon> | No OSX installs AFAICT. |
| 20:53 | <&Derakon> | Is install-from-source feasible? |
| 20:53 | < RichyB> | Use virtualenv, install it with pip or easy_install. |
| 20:53 | <&jerith> | Lots of clang warnings so far. |
| 20:54 | <&jerith> | Yup, it claims everything's happy. |
| 20:54 | < RichyB> | That's not surprising. Lots of the C code in PIL was from before they knew all those things were bad ideas. ;) |
| 20:54 | <&jerith> | RichyB: clang warns about a million things. Very verbosely. |
| 20:55 | < RichyB> | I quite like it so far. |
| 20:55 | <&jerith> | Almost all of them are "clang: warning: argument unused during compilation: '-mno-fused-madd'" and 32/64bit type conversions. |
| 20:57 | <&jerith> | The 32/64bit things are mostly from multiarch stuff where some types change size and others don't, but the precision of the values are all within the smaller size or whatever. |
| 20:57 | <&jerith> | I did a bunch of digging into that stuff once. |
| 20:57 | | * RichyB wtfs at the -mno-fused-madd thing. |
| 20:57 | <&jerith> | I came out of it a little more grizzled. |
| 20:57 | | * Derakon eyes the documentation, mutters at the fact that it all starts with a pre-existing image file. |
| 20:58 | <&jerith> | RichyB: I think that's a gcc arg that clang doesn't recognise. |
| 20:58 | | Reiv [NSwebIRC@Nightstar-95746c1f.kinect.net.nz] has joined #code |
| 20:58 | | mode/#code [+o Reiv] by ChanServ |
| 20:58 | <&jerith> | Derakon: pypng is much nicer to work with if you're just building images. |
| 20:58 | <&jerith> | It's pure-python too, IIRC. |
| 20:59 | <&Derakon> | Roger that. |
| 20:59 | <&McMartin> | jerith: Go ahead and send the PR |
| 20:59 | < RichyB> | jerith, yeah, I'm just a bit bewildered by the notion that any correct floating-point code would be broken by fused multiply-accumulate instructions. They're *more* accurate than the separate multiply and add instructions would be. |
| 20:59 | <&McMartin> | It won't be processed immediately, because I've got some unpushed API changes that may matter and we may need to do some back-and-forth before it goes in, but sure, send it |
| 21:00 | <&jerith> | Derakon: https://github.com/jerith/depixel/blob/master/depixel/io_png.py |
| 21:00 | <&jerith> | Oh, my depixel repo is still in the topic. |
| 21:00 | <&jerith> | Last commit was two years ago. |
| 21:01 | | * Tarinaky blinks and swears at the geometry of this not being sensible. |
| 21:01 | <&jerith> | Well, 19 months ago. |
| 21:02 | <&jerith> | McMartin: I'll do that tomorrow. |
| 21:02 | <&jerith> | I don't actually have a fork of the repo to push to, so there will be a bit of admin around that. |
| 21:03 | < RichyB> | Derakon, PIL.Image.frombuffer(mode, size, data) is probably what you want. http://effbot.org/imagingbook/image.htm |
| 21:03 | <&Derakon> | Ergh, pypng's writer expects an Nx(M*3) array for RGB data. |
| 21:04 | <&Derakon> | Why couldn't it be NxMx3? :( |
| 21:04 | < RichyB> | Derakon, bet you half a sausage that it won't notice if you feed it an ndarray? |
| 21:04 | <&Derakon> | I tried. No dice. |
| 21:04 | < RichyB> | Derakon, I'd probably use pypng if you're happy to only export to PNG, PIL(low) if you want to dump to maybe JPEG or whatever. |
| 21:04 | <&jerith> | Derakon: Probably because of the underlying structure in the serialised format. |
| 21:04 | <&Derakon> | JPEG won't be needed. |
| 21:04 | <&Derakon> | pypng sounds like what I want, I just need to wrestle it into submission. |
| 21:05 | <&jerith> | Easy enough to convert your arrays on the way in and out, but annoying. |
| 21:06 | <&Derakon> | Yeah. |
| 21:10 | <@Tarinaky> | I can never figure out in my head what order translations and rotations need to be in for the camera :/ |
| 21:14 | <&Derakon> | As a general rule, rotate before translating. |
| 21:14 | <@Tarinaky> | Except when you don't, ofc. |
| 21:14 | <&Derakon> | There are situations where you want the reverse, but they're less common. |
| 21:15 | <&Derakon> | When you translate the camera, imagine it's connected to the origin by a tether, which tether has the same "size" as the translation. |
| 21:15 | <&Derakon> | When you rotate post-translation, you are rotating the camera+tether entity. |
| 21:15 | <&McMartin> | jerith: If you haven't forked yet, hold off |
| 21:16 | <&McMartin> | If only because I removed about a dozen functions from the exported API and my next push will totally rewrite Earthball. -_- |
| 21:17 | <&jerith> | McMartin: My standard method of forking repos for the purpose of submitting patches is to track the default branch from upstream (but push to my fork) and use the fork for my branches. |
| 21:17 | <@Tarinaky> | Derakon: I can't quite visualise that. |
| 21:17 | <@Tarinaky> | Aww come on! |
| 21:17 | <&McMartin> | jerith: OK. I'm more saying "I expect a shit ton of conflicts after my next push" |
| 21:17 | <&jerith> | So "git pull; git push" updates my fork. |
| 21:17 | <&Derakon> | Tarinaky: unfortunate, this kind of thing is hard to explain via text. |
| 21:17 | <@Tarinaky> | I had this working a second ago :/ |
| 21:17 | | * Derakon eyes his code. |
| 21:18 | <&Derakon> | writer = png.Writer(*reversed(result.shape[:2])) |
| 21:18 | <&Derakon> | I...can't tell if that's good style or not. >.< |
| 21:18 | <@Tarinaky> | 48 #Zoom out | 4 from OpenGL.GL import * |
| 21:18 | <@Tarinaky> | 49 glTranslate(0,0,-10) | 5 from OpenGL.GLUT import * |
| 21:18 | <@Tarinaky> | Oh hang on. |
| 21:19 | <&jerith> | McMartin: I rewrote the whole of pymonocle in about an hour and a half (most of which was faffing about with editor macros to build boilerplate wrappers) and rewrote half of earthball to match your current version in about half that time. |
| 21:19 | <&Derakon> | Anyway, qualified success: http://derakon.dyndns.org/~chriswei/games/mapmaker/png1.png |
| 21:19 | <@Tarinaky> | http://pastebin.com/sp0bfKDf |
| 21:19 | <&Derakon> | (You'll need to blow up the image significantly) |
| 21:20 | <&jerith> | McMartin: I think I have a fairly good idea about which API functions you'll be removing. |
| 21:20 | <&Derakon> | You're stacking rotates post-translate, Tarinaky. |
| 21:20 | <&Derakon> | That is unlikely to do what you want. |
| 21:20 | <@Tarinaky> | Derakon: This does exactly what I want. |
| 21:20 | <&Derakon> | ... |
| 21:20 | <@Tarinaky> | I just can't visualise why. |
| 21:20 | <&Derakon> | What are you doing? |
| 21:20 | <&McMartin> | Rotation is about the origin |
| 21:21 | <&McMartin> | So when you move it out, rotation is like swinging it on a string like the one you translated. |
| 21:21 | <&McMartin> | jerith: It's most of the functions that create/destroy based on virtual filename instead of resource ID. |
| 21:21 | <@Tarinaky> | Derakon: I have a plane in x,y made up of square tiles. |
| 21:21 | <@Tarinaky> | Derakon: I am rotating them to a faux-isometric view. |
| 21:22 | <@Tarinaky> | I'd take a screenshot but I don't remember how. |
| 21:23 | <&jerith> | McMartin: Yup, those are the ones. |
| 21:24 | <&jerith> | McMartin: So far I've just wrapped the C in Python which gives a very C-like API. |
| 21:24 | <&jerith> | I plan to encapsulate a bunch of the structures (sprites, data resources, etc) in objects. |
| 21:25 | <&McMartin> | I'm hoping for an ultimate API that's more like "setup; consume event stream; teardown" |
| 21:25 | <@Tarinaky> | How do you take a screenshot on this stupid thing :/ |
| 21:25 | <&jerith> | But I'm waiting for the API to stabilise a bit before putting real work into that. |
| 21:25 | <&McMartin> | And yeah. Hold off on big API designs until the base API is done or you may get nasty surprises~ |
| 21:25 | | Kindamoody|out is now known as Kindamoody |
| 21:25 | <&McMartin> | Tarinaky: OpenGL contexts don't react well to PrtSc. I use FRAPS for this. |
| 21:26 | <@Tarinaky> | McMartin: I meant in general. |
| 21:26 | <&Derakon> | There, resized. http://derakon.dyndns.org/~chriswei/games/mapmaker/png2.png |
| 21:26 | <&McMartin> | PrtSc tends to either do this or put a screen shot in the clipboard for pasting into Paint, depending on OS |
| 21:26 | <&McMartin> | OSX has a "Grab" utility for doing this that has hotkeys I never remember |
| 21:26 | <&Derakon> | In OSX, Cmd+Shift+3 puts a PNG of the entire display onto your desktop. |
| 21:27 | <&Derakon> | Cmd+Shift+4 gives you a cropping tool to screenshot only what you want (and also puts a PNG on your desktop). |
| 21:27 | <@Tarinaky> | Ah, right. Print Screen dumps an image in ~/Pictures. |
| 21:27 | <@Tarinaky> | Because that's obvious. |
| 21:27 | <&Derakon> | These are vastly superior to PrtScr because you don't have to faff about with pasting the clipboard. |
| 21:27 | <&McMartin> | ... which OS are you using? |
| 21:27 | <@Tarinaky> | lubuntu |
| 21:27 | <&Derakon> | Putting a screenshot in ~/Pictures seems reasonable. |
| 21:27 | <&McMartin> | Huh. Every Linux I've ever used PrtSc popped a dialog saying basically "OK, here's your screenshot, where do you want to save it?" |
| 21:27 | <&Derakon> | My desktop ends up cluttered with screenshots sometimes. |
| 21:27 | <@Tarinaky> | Derakon: Reasonable and obvious are different beasts :p |
| 21:28 | <&Derakon> | Read the docs~ |
| 21:28 | <&McMartin> | Docs are for parasites that don't contribute patches! |
| 21:28 | <@Tarinaky> | Or I could, you know, not. |
| 21:28 | <&jerith> | McMartin: This is a very small API, so I don't mind playing with versions that end up changing drastically. |
| 21:29 | <&McMartin> | Hoping to fiddle with Monocle some more this weekend. I've been retrohacking of late |
| 21:29 | <&Derakon> | If you get it working by the time I have maps I'm happy with, I wouldn't mind starting work on Jetblade inside Monocle. |
| 21:29 | <&jerith> | Excluding the cdef strings (which are copy/pasted from headers and then trimmed down a bit), pymonocle is ~200 loc and earthball is ~120. |
| 21:30 | <&Derakon> | I don't need to have separating-axis-theorem collision detection, and if I want it badly enough I can submit a patch~ |
| 21:30 | <&McMartin> | Heh |
| 21:30 | <&Derakon> | Monocle stands on top of SDL3, right? |
| 21:30 | <&jerith> | SDL2. |
| 21:30 | <&Derakon> | ...er, whatever the latest SDL is. |
| 21:30 | <&McMartin> | Yeah |
| 21:30 | <&jerith> | We'll probably need to wait another decade or two for SDL3.~ |
| 21:31 | <&McMartin> | SDL2 was solving a Problem SDL1 had |
| 21:31 | <&McMartin> | Hardware advancement needs to give SDL2 a similar Problem before SDL3 will start |
| 21:31 | <&jerith> | McMartin: I quite like the Monocle API so far. |
| 21:31 | <&Derakon> | Multi-window support! |
| 21:31 | <@Tarinaky> | Touch-screens |
| 21:32 | <&McMartin> | Multiwindow support, arbitrary GPU scaling, tighter control over GPU vs. CPU resources |
| 21:32 | <&jerith> | It's lower-level than I'm entirely comfortable with, but that's because it's doing low-level things. |
| 21:32 | <&McMartin> | Touchscreens, if they aren't already in where I wasn't looking, would be an SDL 2.1 not an SDL 3 |
| 21:32 | <&Derakon> | The nice thing about low-level stuff is that it makes few assumptions. |
| 21:32 | <&Derakon> | Which makes it easier to build your own toolkit on top. |
| 21:32 | <&McMartin> | jerith: Yeah, it is absolutely the case that I expect other wrappers to be higher level. |
| 21:32 | <@Tarinaky> | McMartin: Touchscreens are one of the Problems SDL2 fixes. |
| 21:32 | <&McMartin> | The C part is going to be "mechanism not policy" as far as I can make it, with a lot of other bits tacked on on the outside. |
| 21:33 | <&McMartin> | There will be an "official" C++ wrapper too and that will be where things like object inheritance actually happens. |
| 21:33 | <&McMartin> | The C API will be more like "an object has a list of kinds it is and a list of kinds it registers collisions with" |
| 21:34 | <&jerith> | McMartin: Will the C++ wrapper wrap the exposed C API or the C++ internals? |
| 21:34 | | Sam is now known as AnnoDomini |
| 21:34 | <&jerith> | I ask only out of curiosity, because I have very little experience with C++. |
| 21:34 | <&McMartin> | The former. It's a shell around it that someone would be using if they were writing a game in C++ using Monocle. |
| 21:34 | <&McMartin> | (Assuming I understand the question) |
| 21:35 | <&McMartin> | C++ does *not* link cleanly when you make a DLL out of C++ code, which is a major reason Monocle is All C. |
| 21:35 | <&jerith> | Ah, right. |
| 21:35 | <&McMartin> | If there's behavior Monocle Really Ought To Have but that can't be cleanly expressed in C, I'll move it to the shell and say "the shell does this. Maybe other languages will want to do it a different way." |
| 21:35 | <&Derakon> | The shell is a default high-level wrapper? |
| 21:35 | <&McMartin> | More or less. |
| 21:36 | <&McMartin> | I'm going to ship with, probably, four, though. |
| 21:36 | <&McMartin> | C++, C#, Python, and Scheme. |
| 21:36 | <&McMartin> | C++ and C# will look similar. Python might. Scheme won't. |
| 21:36 | <&Derakon> | Sounds fair. |
| 21:36 | <&jerith> | I don't mind maintaining the Python one if you don't mind reviewing it. :-) |
| 21:36 | | Kindamoody is now known as Kindamoody[zZz] |
| 21:36 | <&McMartin> | I'll be happy to. |
| 21:36 | <&jerith> | Also, I have no idea how to write tests for most of this stuff. |
| 21:37 | <&McMartin> | Yeah. |
| 21:37 | <&McMartin> | You'll notice a lack of unit tests outside of the most basic functionality. |
| 21:37 | <&jerith> | And writing code without tests makes me nervous. |
| 21:37 | <&McMartin> | This is one of those places where I'm trying to do interactive systemic tests that exercise everything by inspection. |
| 21:37 | <&McMartin> | I'm also running under valgrind when I can. |
| 21:37 | <&jerith> | Stuff like the resource handling and whatnot are easy enough to test. |
| 21:37 | <&McMartin> | Yeah; that's in rawtest.c |
| 21:38 | <&jerith> | The framebuffer and audio bits... less so. |
| 21:38 | | * Tarinaky is terribad at docstrings. |
| 21:38 | <&jerith> | I ran into a similar problem when I wrote a cffi ncurses wrapper for pypy. |
| 21:39 | | * Tarinaky deserves future me visiting him with an axe. |
| 21:39 | <&McMartin> | Earthball and Shoot The Thing (as yet unwritten) will be the basic systemic tests |
| 21:39 | <&jerith> | The CPython tests for the curses stuff called about half functions in the module and mostly just checked that they didn't throw exceptions. |
| 21:40 | <&jerith> | I ended up finding three or four third-party codebases that used Python's stdlib curses module and just manually poked at hose. |
| 21:40 | <&jerith> | *those |
| 21:40 | <&McMartin> | Tests that involve things not immediately visible (like, say, offscreen collisions) will probably need some hand tests. |
| 21:40 | <&McMartin> | But there's no way this gets a workable set of automated unit tests. |
| 21:40 | <&McMartin> | It's just too hard to validate. |
| 21:40 | <&McMartin> | *mechanically validate |
| 21:41 | <&jerith> | What's SDL's test coverage like? |
| 21:41 | <&jerith> | Actually, I'm not sure I really want the answer to that. |
| 21:42 | <&jerith> | I'd rather live in a blissfully optimistic universe in which most code has at least a halfhearted attempt at automated tests. |
| 21:43 | <&McMartin> | it has a pretty large test directory |
| 21:43 | <&McMartin> | That doesn't answer "coverage" for a couple of reasons, some of them intrinsic. |
| 21:44 | <&McMartin> | All the automated tests in the world won't catch "Matrox GPUs lie to you about their OpenGL capabilities and then silently ignore some of the options you set therein" |
| 21:44 | <&McMartin> | Not that UQM had to rewrite its renderer because of this back in the day, no |
| 21:48 | <&McMartin> | But I was using SDL2's test suite to confirm that the problems the SDL2 port of Monocle was having were not intrinsic to SDL2 but rather to my use of it |
| 21:49 | <&jerith> | Ah, cool. |
| 22:06 | | Vornicus [vorn@Nightstar-sn7kve.sd.cox.net] has joined #code |
| 22:06 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| 22:27 | <&McMartin> | Definitely still a stronger focus on systemic than on unit, though. |
| 22:27 | <&McMartin> | I am relatively convinced that this is intrinsic to the problem domain. |
| 22:27 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 22:49 | | celticminstrel [celticminst@Nightstar-gj43l1.dsl.bell.ca] has joined #code |
| 22:49 | | mode/#code [+o celticminstrel] by ChanServ |
| 22:49 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has joined #code |
| 22:49 | | mode/#code [+o himi] by ChanServ |
| 22:55 | | ErikMesoy is now known as ErikMesoy|sleep |
| 23:24 | <@Alek> | "Just got a file named JPEG.RAR.... containing JPEG.BMP" |
| 23:24 | | AverageJoe [evil1@Nightstar-dfmuir.ph.cox.net] has joined #code |
| 23:34 | <@Azash> | Alek: Amazing |
| 23:43 | <&Derakon> | http://derakon.dyndns.org/~chriswei/games/mapmaker/png3.png |
| 23:43 | <&Derakon> | Got the wall drawing working. This seems enough for a proof of principle; I can move on to generating tiles now. |
| 23:44 | <&Derakon> | Which means coming up with a design for farming out the generation of sub-room tiles based on the map layout. |
| 23:45 | <&Derakon> | Which in turn means I get to decide how expandable I want the game to be at this point. |
| 23:46 | <&Derakon> | I could do something like auto-load all modules in a specific directory, and have the modules register map-generation functions with a central authority when they're loaded. |
| 23:47 | <@Tarinaky> | Meanwhile, I'm having second thoughts about whether I want tiles. |
| 23:48 | <&Derakon> | My main concern with auto-loading code is that it leaves the door wide open for malicious plugins. |
| 23:48 | <&Derakon> | Buuuuuuuut I don't really see how you guard against that and still have a usable plugin system. |
| 23:48 | <&Derakon> | I guess caveat emptor. *shrug* |
| 23:49 | <@Tarinaky> | There's probably a sandbox for python somewhere. |
| 23:50 | <&Derakon> | Ehh, I don't think such an approach is likely feasible. |
| 23:51 | <&Derakon> | And I'd rather not lull the users into a false sense of security. |
| 23:58 | < RichyB> | I know of two sandboxes for Python |
| 23:59 | < RichyB> | there's one in PyPy, and I don't know how well it works but I'm skeptical and apparently using it requires that you lose the JIT which is kind of a lot of the point of using pypy⦠|
| --- Log closed Sat Nov 30 00:00:05 2013 |