| --- Log opened Sun Dec 08 00:00:13 2013 |
| 00:09 | <@Tarinaky> | 20:56 < redwire> Is it really _that_ good? << It doesn't need to be _that_ good. You must use half a dozen other standard libraries and APIs that do less than Twisted does and wouldn't think twice about it. |
| 00:16 | | VirusJTG [VirusJTG@Nightstar-6i5vf7.sta.comporium.net] has joined #code |
| 00:21 | | You're now known as TheWatcher[T-2] |
| 00:21 | < simon_> | in JUnit, when an assertion fails within a thread, I should propagate that exception back to the main thread and throw it there, right? |
| 00:22 | < simon_> | I'm not sure exactly how e.g. JUnit's fail() works and how much it can do. |
| 00:22 | < simon_> | or assert*() for that matter. |
| 00:28 | | You're now known as TheWatcher[zZzZ] |
| 00:29 | | VirusJTG_ [VirusJTG@Nightstar-6i5vf7.sta.comporium.net] has joined #code |
| 00:33 | | VirusJTG [VirusJTG@Nightstar-6i5vf7.sta.comporium.net] has quit [Ping timeout: 121 seconds] |
| 00:40 | | Orthia [orthianz@Nightstar-avg.1ee.224.119.IP] has quit [Ping timeout: 121 seconds] |
| 00:43 | | Turaiel[Offline] is now known as Turaiel |
| 01:16 | | Orthia [orthianz@Nightstar-avg.1ee.224.119.IP] has joined #code |
| 01:16 | | mode/#code [+o Orthia] by ChanServ |
| 01:53 | | Vornicus [vorn@Nightstar-sn7kve.sd.cox.net] has joined #code |
| 01:53 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| 02:59 | | VirusJTG_ [VirusJTG@Nightstar-6i5vf7.sta.comporium.net] has quit [[NS] Quit: Program Shutting down] |
| 04:03 | | Kindamoody[zZz] is now known as Kindamoody |
| 04:43 | | redwire [redwire@Nightstar-27dppb.nl.bellaliant.net] has quit [[NS] Quit: Textual IRC Client: www.textualapp.com] |
| 05:17 | | Derakon is now known as Derakon[AFK] |
| 06:20 | | RichyB [RichyB@Nightstar-c6u.vd5.170.83.IP] has quit [[NS] Quit: Gone.] |
| 06:23 | | RichyB [RichyB@Nightstar-c6u.vd5.170.83.IP] has joined #code |
| 06:28 | < jeroud> | McMartin: pygame-cffi is only wrapping SDL. It's just wrapping it in an API that we can look at and copy. |
| 06:30 | < jeroud> | Monocle is a more ambitious project than pygame and better designed. |
| 06:51 | | Stalker [Z@Nightstar-484uip.cust.comxnet.dk] has joined #code |
| 07:28 | <@Azash> | http://googleonlinesecurity.blogspot.fi/2013/12/further-improving-digital-certif icate.html |
| 07:31 | < McMartin> | jeroud: Speaking of which, I just pushed a change to put mncl_acquire_raw and mcnl_release_raw into the exported-symbol list. |
| 07:31 | < McMartin> | So that should let you get access to the original JSON. |
| 07:31 | <&jerith> | Cool, thanks. |
| 07:32 | <&jerith> | I assume I need to release explicitly when I acquire? |
| 07:32 | <&jerith> | How are you handling the *_resource memory, btw? |
| 07:33 | < McMartin> | You have to release explicitly when you acquire, yes. |
| 07:33 | < McMartin> | This is actually a manual ref-count system, so if you acquire the same file multiple times it recycles the array |
| 07:33 | < McMartin> | load_resmap and unload_resmap do mass-acquire and mass-release. |
| 07:33 | < McMartin> | And then the unexported uninit_raw_system picks up everything that's left |
| 07:34 | < McMartin> | In pointer management terms, the client does not own the pointers returned by *_resource, and they aren't "supposed" to keep them around for very long. |
| 07:35 | < McMartin> | In practice, that's "they can hang onto them until the resmaps are unloaded, at which point those pointers might have become garbage" |
| 07:36 | | ErikMesoy|sleep is now known as ErikMesoy |
| 07:36 | < McMartin> | It's currently an error to have objects that refer to spritesheets that are no longer part of any loaded resmap, but that restriction may fall in the future. That part isn't exported so I might be able to replace those with permanent handles that can repair themselves if it's reloaded later. |
| 07:36 | <&jerith> | Does that mean my spritesheet image is allocated when I call load_resmap? |
| 07:36 | < McMartin> | Yes. |
| 07:36 | <&jerith> | Or only when I call sprite_resource()? |
| 07:36 | <&jerith> | Ah. |
| 07:36 | < McMartin> | load_resmap is the expensive operation, basically. |
| 07:37 | <&jerith> | So if I have lots of resources and want to limit the lifetime of some of them I should put them in different resmaps. |
| 07:37 | < McMartin> | Right. |
| 07:37 | < McMartin> | Merging and unmerging is *supposed* to work but almost certainly doesn't yet since this is not heavily tested. |
| 07:37 | < McMartin> | (Though rawtest.c does a tiny bit of that) |
| 07:38 | <&jerith> | Merging and unmerging? |
| 07:38 | <&jerith> | Of the resource locations? |
| 07:38 | < McMartin> | If two resmaps define the same resource unloading one of the resmaps should not unload that resource. |
| 07:38 | <&jerith> | Ah. |
| 07:38 | < McMartin> | I'm almost positive that doesn't work right now, but if the resmaps are disjoint unload_resmap does targeted removals. |
| 07:39 | <&jerith> | Cool. |
| 07:39 | < McMartin> | The equivalent behavior in the raw subsystem has been tested and I'm moderately confident in it, though. |
| 07:40 | <&jerith> | Can resources change underneath me if I call add_resource_zipfile() or something and I've already called sprite_resource()? |
| 07:40 | < McMartin> | Sort of. |
| 07:41 | < McMartin> | You aren't supposed to do that while the file is still open. |
| 07:41 | < McMartin> | (By which I mean I don't intend to specify the behavior as a thing I commit to keeping consistent.) |
| 07:42 | < McMartin> | If you unload everything that it refers to, then add new resource locations, then load again, that will work as you expect. |
| 07:42 | < McMartin> | Shadowing is explicitly part of rawtest. |
| 07:42 | < McMartin> | But remember, when you load the resmap, from that point on the resources are *in memory*, so they'll stick around until you wipe the structures out. |
| 07:43 | < McMartin> | I'll be honest; this is a corner I'm not putting a lot of work into until post-1.0. |
| 07:43 | < McMartin> | I'm not putting guardrails in in part because I don't want these restrictions to be a permanent part of the API |
| 07:43 | < McMartin> | But the only protocol I guarantee will work now and going forward is: |
| 07:44 | < McMartin> | - Set up all resource directories/zipfiles/etc. |
| 07:44 | < McMartin> | - Load all resmaps |
| 07:44 | < McMartin> | - Do things that involve resources |
| 07:44 | < McMartin> | - Unload all resmaps (optional) |
| 07:44 | < McMartin> | - call mncl_uninit() |
| 07:45 | < McMartin> | Some things will be loaded as-needed and not cached in memory. |
| 07:45 | < McMartin> | BGM tracks, for instance. |
| 07:45 | < McMartin> | Right now, I think it's *only* BGM tracks. |
| 07:46 | < McMartin> | (These get loaded into memory when the song starts, and are kicked out of memory when the BGM is stopped or changed to something else) |
| 07:47 | < McMartin> | With this latest push, raw resources that aren't listed in the resmap are also loaded when the refcount goes from 0 to 1. |
| 07:47 | < McMartin> | And are unloaded when it goes from 1 to 0. |
| 07:48 | <&jerith> | I'm less concerned about the things managed by Monocle than I am about things that I bypass Monocle for, like the proposed "load the resmap as raw bytes and call json.loads()" plan to avoid dealing with your clunky-because-it's-C JSON API. |
| 07:49 | < McMartin> | Right. |
| 07:49 | < McMartin> | Best thing to do there is acquire it, copy the bytes into a Python string, and then release it. |
| 07:49 | < McMartin> | That might actually be a better thing to export in PyMonocle than directly exporting acquire/release_raw, even. |
| 07:50 | < McMartin> | (And then the Data component can use that to get the relevant JSON, maybe as part of your wrapper around load_resmap) |
| 07:50 | <&jerith> | Actually, that's not really an issue because it's part of the resmap and therefore can't change. |
| 07:50 | <&jerith> | Although it means the data can outlive the resmap it comes from. |
| 07:50 | < McMartin> | Well, yes, but you'll need to remember *where the resmap was* |
| 07:51 | <&jerith> | Which isn't really a problem. |
| 07:51 | < McMartin> | Right |
| 07:51 | < McMartin> | Just saying that it might make sense to do that parsing at the time you're loading up the resmap anyhow |
| 07:51 | <&jerith> | That's my plan. |
| 07:51 | <&jerith> | Actually, it isn't. |
| 07:51 | <~Vornicus> | I keep reading that as "re-smap" |
| 07:51 | < McMartin> | You smap the *shit* out of those suckers again, boy |
| 07:52 | <&jerith> | Oh, wait. I've missed a bit in my thinking. |
| 07:52 | <&jerith> | Because yes, I need to know where the resmap comes from. |
| 07:52 | | Kindamoody is now known as Kindamoody|afk |
| 07:54 | <&jerith> | Actually, this means keeping track of things that Monocle is meant to be keeping track of for me. |
| 07:54 | < McMartin> | Well |
| 07:55 | <&jerith> | Because I now need to know which which file to look in for the data resource I'm loading. |
| 07:55 | < McMartin> | PyMonocle doesn't get the guarantee that the C layer does all the work necessary for a smooth Python experience. |
| 07:55 | < McMartin> | Only the people using PyMonocle get that guarantee. |
| 07:56 | <&jerith> | The problem is that if you change how overlapping resmaps work or whatever, pymonocle's behaviour stops matching the underlying API's. |
| 07:56 | < McMartin> | My thought here was that as a side effect of the Python function that ultimately calls load_resmap, it would also take that filename it got as an argument and run it through a JSON parser |
| 07:57 | < McMartin> | Mmm. That is true, but it *does* live in the same repository. |
| 07:57 | < McMartin> | If I change the contract I may have to change the bindings. I'm currently roughly OK with that, especially at 0.x. |
| 07:57 | <&jerith> | Sure, but that's not the same as being updated at the same time. |
| 07:57 | < McMartin> | It's an added set of work. |
| 07:57 | < McMartin> | Up to you, I suppose. |
| 07:58 | <&jerith> | I think it might actually just be better to wrap Monocle's data API. |
| 07:58 | < McMartin> | The other "sensible" alternative is to do the marshalling into Proper Python Data Types. |
| 07:58 | < McMartin> | Yeah, that way. |
| 07:58 | <&jerith> | I've basically already done that except for the KV stuff. |
| 07:58 | < McMartin> | But people who want to use Data resources in PyMonocle really shouldn't be having to worry about the mncl_data_* calls. |
| 07:59 | <&jerith> | (And I've done it in a clunky way because it was the minimum necessary to get instructions back in earthball.) |
| 07:59 | < McMartin> | KV here is a straight-up map<string, JSON_VALUE*> |
| 07:59 | < McMartin> | Mmm. I might not be exposing enough of it, though. |
| 08:00 | < McMartin> | Unless you can produce something that will work as a MNCL_KV_VALUE_FN. |
| 08:00 | <&jerith> | I can write a callback function easily enough. |
| 08:00 | <&jerith> | I don't know if that's true for other FFI libraries. |
| 08:01 | < McMartin> | OK. Get something you can hand to mncl_kv_foreach and you can do your enumeration. |
| 08:01 | | * jerith writes that bit now. |
| 08:02 | < McMartin> | C callbacks are a pretty fundamental thing, so I'm seeing a certain amount of that being common. |
| 08:02 | < McMartin> | Gambit has it cut both ways, actually. |
| 08:03 | < McMartin> | There's c-lambda, for defining Scheme functions that are really C calls, and there's c-define, for producing Scheme functions that can be called as if they are C. |
| 08:03 | < McMartin> | So I think Gambit will be able to do a c-define and pass that to mncl_kv_foreach. |
| 08:13 | < McMartin> | That's good, because I *really* do not want to expose the MNCL_KV internals. |
| 08:13 | < McMartin> | And C's approach to data hiding is... unsubtle |
| 08:13 | < McMartin> | You hide data by having it *not be in the file* |
| 08:14 | <&jerith> | There's another thing I need to do that I somehow mised. |
| 08:14 | <&jerith> | *missed |
| 08:15 | <&jerith> | Proper update event callbacks. |
| 08:15 | <&jerith> | Hrm. |
| 08:15 | < McMartin> | I'd hold off on that until I get subscription and kinds in. |
| 08:15 | < McMartin> | Also, I'm kind of changing the list of events right now |
| 08:15 | <&jerith> | Do objects need to be explicitly destroyed? |
| 08:16 | < McMartin> | Ordinarily yes |
| 08:16 | < McMartin> | Except for shutdown, Monocle will never destroy an object unless you tell it to die. |
| 08:16 | <&jerith> | McMartin: The main thing there is looking up the right Python object for a Monocle object. |
| 08:16 | < McMartin> | Yeah. |
| 08:17 | < McMartin> | I'm going to extend MNCL_OBJECT to let you initialize it by loading up a void * |
| 08:17 | < McMartin> | ISTR you thought it would be easier to just maintain a map from MNCL_OBJECT * to Python Object. |
| 08:17 | < McMartin> | (The latter is kind of what I'm envisioning will be used by anyone that doesn't want to package up the relevant bits in a void * that C can put its grubby hands on) |
| 08:17 | <&jerith> | cffi actually has handy utilities for stashing pointers to Python objects in C-land and getting them back again. |
| 08:18 | < McMartin> | OK. |
| 08:18 | | Turaiel is now known as Turaiel[Offline] |
| 08:18 | < McMartin> | If so, then I intend to set one of those bad boys up, but if you can't also say "hold off on garbage collecting this until I unlock it" it won't be much use |
| 08:18 | < McMartin> | (Since it will go out of scope instantly~) |
| 08:18 | <&jerith> | The only caveat is that you need to keep a reference to any objects you do this with in Python-land so they don't get garbage collected. |
| 08:18 | | * McMartin nods |
| 08:18 | < McMartin> | So you need the map anyway. |
| 08:19 | < McMartin> | And unlike C++, Python dicts are O(1) access anyway. |
| 08:19 | <&jerith> | Well, it can just be a set that I shove things in and remove them from. |
| 08:19 | | * McMartin nods |
| 08:19 | <&jerith> | (A set basically being a dict with no values. I think under the hood it's just a dict with all values set to None.) |
| 08:20 | < McMartin> | Would not surprise me. In languages with dicts but no sets I tend to map values to true. |
| 08:20 | <&jerith> | Then it can be a global "keep these Python objects alive" bag and I don't need to worry about lookups at all. |
| 08:20 | | * McMartin nods. |
| 08:21 | | Harlow [Harlow@Nightstar-2dbe3d64.il.comcast.net] has joined #code |
| 08:22 | <&jerith> | MNCL_OBJECT doesn't have that userdata pointer yet, nor does it have a destructor function. |
| 08:22 | < McMartin> | These are both true things. |
| 08:22 | <&jerith> | So I can't really do what I want to do here anyway. |
| 08:23 | < McMartin> | My immediate things to do list is: |
| 08:23 | < McMartin> | - Fix the event sequence |
| 08:23 | < McMartin> | - Let objects subscribe to specific events, not just PREPHYSICS |
| 08:23 | < McMartin> | - Implement kinds so that you can actually do this without direct calls to internals |
| 08:24 | < McMartin> | Putting userdata in goes between those two steps, since it's trivial. |
| 08:24 | < McMartin> | Monocle thinks objects are immortal right now. |
| 08:24 | < McMartin> | I won't make objects destroyable until I have putting objects in all the relevant event queues working |
| 08:24 | < McMartin> | (Since destroying an object *mostly* means removing them from those queues, from the client's standpoint) |
| 08:25 | < McMartin> | The client will have to take note of any user data the object has before passing it off for destruction so it may behave appropriately |
| 08:25 | < McMartin> | Monocle will never touch the value in user_data, neither reading nor writing it. |
| 08:25 | | * jerith nods. |
| 08:26 | < McMartin> | While this is not a full guarantee, it is likely that it will never even *copy* it, since MNCL_OBJECTs are in fixed locations on the heap their whole lives. |
| 08:26 | <&jerith> | Destruction either needs to be explicitly manual or there needs to be a callback for it. |
| 08:26 | < McMartin> | The current plan is "it is explicitly manual" |
| 08:27 | < McMartin> | But it is also "objects are presently immortal because the fun part of object destruction involves operations in parts of the code that haven't had their design nailed down yet" |
| 08:28 | <&jerith> | By the way, can we get lookup functions for sprite attributes now that their struct is opaque? |
| 08:28 | < McMartin> | Yeah, that's on the list |
| 08:28 | <&jerith> | That sounds like a thing I can actually do. |
| 08:29 | < McMartin> | I may end up de-opaquing it, too, but making the sprite pointer const. |
| 08:35 | <&jerith> | I suppose you could have a funtion that returns a struct containing a copy of the sprite's data. |
| 08:35 | <&jerith> | *function |
| 08:35 | < McMartin> | Bleh. I'd sooner use accessors. |
| 08:35 | < McMartin> | There are few things where assigning them should have other side effects, and I'm debating whether to hide those behind accessors (probably the best thing to do) or to keep secret copies of them and compare them for changes at the point where it matters |
| 08:36 | <&jerith> | I think accessors would be better. |
| 08:36 | < McMartin> | Yeah. |
| 08:36 | <&jerith> | That way you could explode when an invalid value is set rather than some arbitrary time later. |
| 08:36 | < McMartin> | (This is the object's Z-order, basically. If any objects are created, destroyed, or have their depth changed, the scene graph needs to be resorted) |
| 08:36 | < McMartin> | As it happens, literally any integer is valid here~ |
| 08:38 | <&jerith> | The accessor could just set a dirty flag that you check later for that. |
| 08:38 | < McMartin> | That is indeed the idea, yes. |
| 08:38 | < McMartin> | .. hmmm. |
| 08:39 | < McMartin> | OK, that's a complication |
| 08:39 | | * McMartin realizes he may have to defer object destruction, but that's going to be a real problem. |
| 08:39 | <&jerith> | Defer it? |
| 08:42 | < McMartin> | Maybe I can avoid that, but... |
| 08:42 | < McMartin> | ... the semantics are a bit unclear regarding what should happen if an object participates in multiple collision events, and the client reacts to the first such event by ordering the deletion of that object. |
| 08:43 | <&jerith> | Hrm. |
| 08:43 | < McMartin> | I think the correct answer, given that we need the client to initiate all deletions and the client has some work of its own to do as part of that, is to say "if you do this, the object participates in no further collisions." |
| 08:44 | < McMartin> | I think that's the right answer because you can also get the other behavior given this: "If you want it to participate in all collisions anyway, set a bit in your data and have it do the destruction at pre-render." |
| 08:44 | | celticminstrel [celticminst@Nightstar-m7v.4bu.92.174.IP] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] |
| 08:44 | <&jerith> | That sounds reasonable. |
| 08:45 | < McMartin> | Whereas it's quite a bit more obnoxious to try to simulate "die instantly" with deferred destruction. |
| 08:46 | <&jerith> | Are collision events sent during collision detection or collected and fired at the end? |
| 08:46 | < McMartin> | That's the question, isn't it~ |
| 08:46 | <&jerith> | I suppose that doesn't actually matter since event handling is async anyway. |
| 08:46 | < McMartin> | I think I'm forced to send them during collision detection if I want to make sure that stale pointers never appear in the event stream. |
| 08:46 | <&jerith> | Unless you block on the event being handled. |
| 08:46 | < McMartin> | Er |
| 08:46 | < McMartin> | I sort of do |
| 08:47 | < McMartin> | Monocle is single-threaded |
| 08:47 | <&jerith> | Oh, right. |
| 08:50 | < McMartin> | You know what, while I'm at it I'm going to change the hardcoded subscription so earthball.c looks nicer. |
| 08:50 | < McMartin> | It'll all come out in the resource files anyway once that part works. |
| 08:51 | <&jerith> | Which I cannot play because I don't have easy access to a Windows machine. |
| 08:51 | <&jerith> | Oh, wrong channle. |
| 08:51 | < McMartin> | you like a channel |
| 08:51 | <&jerith> | *channel |
| 08:52 | <&jerith> | That channel and this one are right next to each other in my client and I accidentally hit M-e instead of M-w. |
| 08:53 | <&jerith> | Also, both of them currently have several lines if "McMartin" at the bottom. :-) |
| 08:54 | < McMartin> | It's been known to happen. -_- |
| 09:19 | < McMartin> | Pushed again. userdata field is in, and the event enum has been modified, and earthball now subscribes to PRERENDER instead of UPDATE^WPREPHYSICS |
| 09:21 | | Harlow [Harlow@Nightstar-2dbe3d64.il.comcast.net] has quit [[NS] Quit: BED] |
| 09:32 | <&jerith> | I think I'm going to have to substantially refactor pymonocle. |
| 10:23 | | You're now known as TheWatcher |
| 10:56 | | * jerith pushes the shiny new pymonocle. |
| 10:56 | <&jerith> | I guess I should wrap events nicely now. |
| 11:01 | < McMartin> | Hmm. And I've realized I've been doing event subscriptions all wrong. |
| 11:01 | < McMartin> | Right now I'm creating object iterators based on the phase. |
| 11:01 | < McMartin> | I need to do it based on trait, and every subscribable phase needs a trait to go with it. |
| 11:01 | < McMartin> | That also means I'm going to need a trait->small integer mapping. |
| 11:02 | < McMartin> | This implies traits can never be destroyed, which I'm pretty sure I'm OK with. |
| 11:07 | | Vornicus [vorn@Nightstar-sn7kve.sd.cox.net] has quit [[NS] Quit: Leaving] |
| 12:17 | | VirusJTG [VirusJTG@Nightstar-6i5vf7.sta.comporium.net] has joined #code |
| 13:03 | | Pandemic [VirusJTG@Nightstar-6i5vf7.sta.comporium.net] has joined #code |
| 13:03 | | mode/#code [+o Pandemic] by ChanServ |
| 13:19 | | Kindamoody|afk is now known as Kindamoody |
| 13:33 | | Stalker [Z@Nightstar-484uip.cust.comxnet.dk] has quit [[NS] Quit: If the world didn't suck, we'd all fall off.] |
| 14:45 | | Stalker [Z@Nightstar-ro94ms.balk.dk] has joined #code |
| 15:18 | | VirusJTG [VirusJTG@Nightstar-6i5vf7.sta.comporium.net] has quit [[NS] Quit: Program Shutting down] |
| 15:18 | | VirusJTG [VirusJTG@Nightstar-6i5vf7.sta.comporium.net] has joined #code |
| 15:19 | | Orthia [orthianz@Nightstar-avg.1ee.224.119.IP] has quit [Ping timeout: 121 seconds] |
| 15:36 | | redwire [redwire@Nightstar-27dppb.nl.bellaliant.net] has joined #code |
| 16:33 | | Derakon[AFK] is now known as Derakon |
| 17:33 | | celticminstrel [celticminst@Nightstar-gj43l1.dsl.bell.ca] has joined #code |
| 17:33 | | mode/#code [+o celticminstrel] by ChanServ |
| 18:01 | | iospace is now known as io\PACKERS |
| 18:46 | | RichyB [RichyB@Nightstar-c6u.vd5.170.83.IP] has quit [Ping timeout: 121 seconds] |
| 18:56 | | RichyB [RichyB@Nightstar-c6u.vd5.170.83.IP] has joined #code |
| 19:08 | | RichyB [RichyB@Nightstar-c6u.vd5.170.83.IP] has quit [Ping timeout: 121 seconds] |
| 19:19 | | RichyB [RichyB@Nightstar-c6u.vd5.170.83.IP] has joined #code |
| 19:43 | | Vornicus [vorn@Nightstar-sn7kve.sd.cox.net] has joined #code |
| 19:43 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| 20:39 | | Kindamoody is now known as Kindamoody[zZz] |
| 20:44 | | Stalker [Z@Nightstar-ro94ms.balk.dk] has quit [Ping timeout: 121 seconds] |
| 20:58 | | io\PACKERS is now known as io\WOOO |
| 21:05 | <&ToxicFrog> | argh this is all a horrible mess |
| 21:05 | <&ToxicFrog> | I hate being configurable |
| 21:13 | | Stalker [Z@Nightstar-484uip.cust.comxnet.dk] has joined #code |
| 21:49 | | Stalker [Z@Nightstar-484uip.cust.comxnet.dk] has quit [Ping timeout: 121 seconds] |
| 21:51 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 21:59 | | ErikMesoy is now known as ErikMesoy|sleep |
| 22:18 | | Vornicus [vorn@Nightstar-sn7kve.sd.cox.net] has quit [[NS] Quit: Leaving] |
| 22:35 | | Orthia [orthianz@Nightstar-avg.1ee.224.119.IP] has joined #code |
| 22:35 | | mode/#code [+o Orthia] by ChanServ |
| 22:36 | | redwire is now known as redwire|afk |
| 22:36 | | redwire|afk [redwire@Nightstar-27dppb.nl.bellaliant.net] has quit [[NS] Quit: My MacBook has gone to sleep. ZZZzzzâ¦] |
| 22:36 | | Turaiel[Offline] is now known as Turaiel |
| 22:53 | | io\WOOO is now known as iospace |
| 22:53 | | redwire [redwire@Nightstar-ndf5i0.wst.mun.ca] has joined #code |
| 22:59 | | redwire [redwire@Nightstar-ndf5i0.wst.mun.ca] has quit [[NS] Quit: My MacBook has gone to sleep. ZZZzzzâ¦] |
| 23:10 | | redwire [redwire@Nightstar-tsfae1.wst.mun.ca] has joined #code |
| 23:28 | | himi [fow035@Nightstar-q9amk4.ffp.csiro.au] has joined #code |
| 23:28 | | mode/#code [+o himi] by ChanServ |
| 23:58 | <@Tarinaky> | I have this horrible feeling that trying to my dungeon generator in a square-tile base is actually making it harder to get my head-around than if I came up with a more... abstract way of storing maps. |
| 23:59 | <@Tarinaky> | Feels like I'm trying to do too much at once :/ |
| --- Log closed Mon Dec 09 00:00:29 2013 |