| --- Log opened Sun Dec 01 00:00:21 2013 |
| 00:00 | < PhiltheTechie> | Thanks McMartin and Vornicus. |
| 00:00 | < PhiltheTechie> | Good advice. If you are around sometime in the future i'll let you know what i come up with. |
| 00:02 | < PhiltheTechie> | See you again. |
| 00:02 | | PhiltheTechie [PhiltheTech@Nightstar-0iohse.supportituk.co.uk] has quit [[NS] Quit: coding] |
| 00:18 | | Turaiel is now known as Turaiel[Offline] |
| 00:55 | | Stalker [Z@Nightstar-484uip.cust.comxnet.dk] has quit [Ping timeout: 121 seconds] |
| 01:07 | | You're now known as TheWatcher[T-2] |
| 01:11 | | You're now known as TheWatcher[zZzZ] |
| 01:44 | <@Azash> | Is there a way to create and execute a program in RAM without ever writing it to a disk? |
| 01:44 | <@Azash> | Without involving something bigger like making a ramdisk |
| 01:46 | <&ToxicFrog> | Azash: on a smaller scale (functions, not programs), this is what JITs do |
| 01:47 | <&ToxicFrog> | So, yes. |
| 01:48 | <&ToxicFrog> | Off the top of my head, the easiest way would probably be to write the program code to memory, then fork() and have the child jump into the generated code |
| 01:49 | <@Azash> | Yeah, I was pondering over how caching code is done |
| 01:50 | <@Azash> | Thanks though |
| 02:24 | <&McMartin> | This technique is sometimes also called "trampolines", but this means something else too. |
| 02:24 | <&McMartin> | Of course, the most enthusiastic users of this technique are malware writers exploiting buffer overflows |
| 02:24 | <&McMartin> | So you also have to explicitly mark that chunk of RAM as executable, these days. |
| 02:35 | <&McMartin> | ... heh, actually, I guess pucrunch counts too |
| 02:35 | <&McMartin> | That C64 demo I've been working on decompresses itself into place then runs itself. |
| 02:35 | <@Azash> | "Students build a whole compiler in C# for a given object-oriented language." |
| 02:35 | <&McMartin> | That's about a semester course, I think. |
| 02:35 | | * Azash wonders why the language to write the compiler in is preset |
| 02:36 | <@Azash> | McMartin: Nice |
| 02:36 | <@Azash> | pucruncz? |
| 02:36 | <&McMartin> | pucrunch is the self-extractor generator I used to make that happen. |
| 02:36 | <&McMartin> | I get no credit for using it, but maybe a little for making it properly interact with the BASIC interpreter |
| 02:37 | <&McMartin> | Azash: I suspect the language is preset to spare the TA's sanity when dealing with testing frameworks, and also because the right way to organize compilers varies drastically with implementation language. |
| 02:37 | <&McMartin> | (Like, which things are the objects and which things are the things the methods take are generally reversed for ML-like implementation languages and for Java-like ones.) |
| 02:38 | <&McMartin> | ... it occurs to me that thanks to delegates C# might be able to switch-hit more easily than other ones, too. |
| 02:38 | <@Azash> | The former is true, but I don't know if the latter necessarily applies as this is a project separate from the compilers course itself (which precedes it) |
| 02:38 | <&McMartin> | Ah, I see |
| 02:39 | <&McMartin> | I guess it depends on what language that course is taught in. :D |
| 02:39 | <&McMartin> | (Do you happen to know what the textbook is?) |
| 02:39 | <@Azash> | English, and no, as spring teaching isn't finalized yet |
| 02:40 | <&McMartin> | That wasn't actually my question -_- |
| 02:40 | <@Azash> | Oh, sorry, I'm tired |
| 02:40 | <&McMartin> | Unless you intend to mean "the compilers class does all its work with essay questions" which I guess I can see |
| 02:40 | <@Azash> | I somehow read it as the textbook being tied to the language |
| 02:41 | <@Azash> | The compilers theory course uses Scott M., Programming Language Pragmatics |
| 02:41 | <&McMartin> | Well, depends on the textbook |
| 02:41 | | * McMartin nods |
| 02:41 | <&McMartin> | Like, Appel's books are named things like "Modern Compiler Implementation in {insert language here}" |
| 02:41 | <@Azash> | Ah |
| 02:42 | <&McMartin> | (I had a compilers/program analysis focus in grad school, if you're wondering why I seem unusually interested in this >_>) |
| 02:42 | <@Azash> | Oh, nice |
| 02:42 | <@Azash> | I have the dragon book here, will probably at least browse through it in preparation |
| 02:42 | | * McMartin nods |
| 02:42 | <&McMartin> | Red, green, or purple? |
| 02:42 | <@Azash> | Purple |
| 02:43 | <&McMartin> | Nice. |
| 02:43 | <@Azash> | Pearson International 2nd Edition |
| 02:43 | <&McMartin> | A paper I contributed to is actually cited in its bibliography >_> |
| 02:43 | <&McMartin> | (I was one of Lam's students) |
| 02:44 | <@Azash> | Very nice |
| 02:45 | <@Azash> | I had a look, looks like the international ed lacks the bibliography, sadly |
| 02:45 | <&McMartin> | Heh. |
| 02:45 | <&McMartin> | I don't have my copy handy right now, I'm not sure which bit of it it really was. |
| 02:45 | <&McMartin> | It might have been some footnote or something. |
| 02:46 | <&McMartin> | (And it's a self-citation by Lam so it doesn't count =P) |
| 02:46 | <@Azash> | Haha |
| 02:47 | <@Azash> | The lecturer for this is the type that will give 4cr for 8cr of work |
| 02:47 | <&McMartin> | Elch. |
| 02:47 | <&McMartin> | Well, good luck. |
| 02:47 | <@Azash> | So I should do the dragon book and coursera course beforehand |
| 02:47 | <&McMartin> | IIRC the dragon book is more on "internals of parser generators" and less on "using parser generators to actually write compilers with" |
| 02:48 | <@Azash> | Ah, well, can't hurt to have a gander |
| 02:48 | <&McMartin> | And then the second half of the Dragon book is "compilers are boring, let's use the technology to try to deduce interesting things about programs" |
| 02:48 | <@Azash> | Haha |
| 02:49 | <&McMartin> | I certainly don't discourage you from flipping through it. Just be aware that it's more interested in the foundations of the tools you'd probably be using in that project, rather than being about how to do something like that using said tools |
| 02:49 | <&McMartin> | (Being able to wield flex or similar tools in your projects is actually pretty huge) |
| 02:50 | <@Azash> | Yeah |
| 02:51 | <@Azash> | Honestly the course subject + MSc level + the lecturer makes me want to quote Frank Drebin |
| 02:51 | <@Azash> | Paraphrased, you take a big risk sticking your face in a fan |
| 02:51 | <@Azash> | Which is pretty much what this will be |
| 03:02 | <&ToxicFrog> | Azash: here Compilers was C or Java (student's option) and the reason was twofold: first, because all of the tools needed for those including the parsing/lexing libraries are installed on all the lab machines, and second to spare the TA's sanity. |
| 03:02 | <&ToxicFrog> | Other languages were permitted by permission of the TA and professor. |
| 03:03 | <@Azash> | Mm |
| 03:04 | <&ToxicFrog> | (I did a hybrid C frontend/Lua backend design. Course was hella fun.) |
| 03:07 | | Harlow [Harlow@Nightstar-2dbe3d64.il.comcast.net] has joined #code |
| 03:21 | | Turaiel[Offline] is now known as Turaiel |
| 04:16 | | Kindamoody[zZz] is now known as Kindamoody |
| 04:56 | | VirusJTG [VirusJTG@Nightstar-6i5vf7.sta.comporium.net] has quit [[NS] Quit: Program Shutting down] |
| 05:00 | | AverageJoe [evil1@Nightstar-fb1kt4.ph.cox.net] has joined #code |
| 05:22 | | Derakon is now known as Derakon[AFK2] |
| 05:28 | | RichyB [RichyB@Nightstar-c6u.vd5.170.83.IP] has quit [[NS] Quit: Gone.] |
| 05:32 | | RichyB [RichyB@Nightstar-c6u.vd5.170.83.IP] has joined #code |
| --- Log closed Sun Dec 01 06:29:07 2013 |
| --- Log opened Sun Dec 01 06:40:34 2013 |
| 06:40 | | TheWatcher[zZzZ] [chris@Nightstar-ksqup0.co.uk] has joined #code |
| 06:40 | | Irssi: #code: Total of 40 nicks [16 ops, 0 halfops, 0 voices, 24 normal] |
| 06:40 | | mode/#code [+o TheWatcher[zZzZ]] by ChanServ |
| 06:41 | | Irssi: Join to #code was synced in 39 secs |
| 06:51 | | Kindamoody is now known as Kindamoody|afk |
| 07:01 | | celticminstrel [celticminst@Nightstar-gj43l1.dsl.bell.ca] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] |
| 07:11 | | Harlow [Harlow@Nightstar-2dbe3d64.il.comcast.net] has quit [[NS] Quit: BED] |
| 07:34 | | AverageJoe [evil1@Nightstar-fb1kt4.ph.cox.net] has quit [[NS] Quit: Leaving] |
| 08:10 | | Stalker [Z@Nightstar-484uip.cust.comxnet.dk] has joined #code |
| 08:15 | | Turaiel is now known as Turaiel[Offline] |
| 08:47 | | Vornicus [vorn@Nightstar-sn7kve.sd.cox.net] has quit [[NS] Quit: Leaving] |
| 09:47 | <&McMartin> | Man, I completely forget what I was doing. |
| 09:48 | <&jerith> | McMartin: Surely it's good to be able to look at the various coordinates on a sprite? |
| 09:48 | <&McMartin> | It's C. I can't make them read-only if I expose the struct. |
| 09:48 | <&McMartin> | The coordinates of where you are &c is part of Object, which is what I had half-designed. |
| 09:48 | <&McMartin> | And, uh, I think it was the wrong half. |
| 09:48 | <&jerith> | Oh, right. You're replacing the struct with a pile of functions? |
| 09:49 | <&McMartin> | Eventually. |
| 09:49 | <&McMartin> | But it's not going to be part of core, as it were. |
| 09:49 | <&jerith> | I started wrapping the data resource stuff and gave up because I couldn't come up with a nice Pythonic wrapper. |
| 09:50 | <&McMartin> | Yeah, that's going to be tricky. Are there standard Python JSON libraries? |
| 09:50 | < Syka> | McMartin: `import json` |
| 09:50 | <&jerith> | Yes, but they convert between the serialised form and standard Python types. |
| 09:51 | <&jerith> | Which is where I was going with my wrapper. |
| 09:51 | <&jerith> | It's just that there's a pile of work in the middle. |
| 09:51 | | * McMartin nods. |
| 09:51 | <&McMartin> | Raw could do with some of that too. |
| 09:51 | <&McMartin> | One advantage is that you don't have to convert *back*. |
| 09:52 | <&jerith> | The easiest thing I could come up with was to take the entire structure and turn it into nested dicts/lists/strings/ints/whatever. |
| 09:52 | <&McMartin> | That might honestly be good enough. |
| 09:52 | <&jerith> | I think I was trying to stay too close to C-land, though. |
| 09:52 | <&McMartin> | A lot of this garbage is because C has no acceptable standard libraries for this. |
| 09:52 | <&McMartin> | Yeah. |
| 09:53 | <&McMartin> | See also mncl_raw, which is 90% a half-assed reimplementation of module struct. |
| 09:53 | <&McMartin> | I think you could get a decent Python API there of "give it a resource name, get back a string full of bytes" |
| 09:54 | <&jerith> | pymonocle is py2.[67] only for now, btw. |
| 09:54 | <&McMartin> | Works for me |
| 09:54 | <&McMartin> | Hence, string, and not bytebuf~ |
| 09:54 | <&McMartin> | Anyway, I think I remember what I was up to here. |
| 09:55 | <&McMartin> | The "I'm reimplementing things better languages have in their stdlib" reminded me. I'm reimplementing an iterator interface and then hiding it. |
| 09:55 | <&jerith> | It shouldn't be /hard/ to make it work with 3.x as well, but it's a bit of a pain to do and it can wait until things are a little more settled. |
| 09:55 | | * McMartin nods. |
| 09:56 | <&jerith> | Apart from the syntax changes, text vs bytes is likely to be the only sticking point. |
| 09:58 | <&McMartin> | Man. |
| 09:58 | <&McMartin> | Do I even want to enforce inheritance hierarchies? |
| 09:58 | <&jerith> | Maybe the "extracting things from a bucket of bytes" functions need to not be core APIs? |
| 09:59 | <&McMartin> | Define "core" here. |
| 09:59 | <&jerith> | Why would you want to enforce inheritance hierarchies? |
| 09:59 | <&jerith> | McMartin: In Python I'd probably put them in a different module. |
| 09:59 | <&McMartin> | First question first: of the five languages I intend to bind, Python is the *only* one with an acceptable struct library. Everyone else will need those functions. |
| 10:00 | <&jerith> | Ah. |
| 10:00 | <&McMartin> | First question, addendum: C has no notion of namespaces; you gain literally nothing from breaking things into separate library files and lose much. |
| 10:00 | <&McMartin> | By having only one binary, I can enforce ABI conformance absolutely. |
| 10:00 | <&McMartin> | Within the library, that is. |
| 10:01 | <&jerith> | McMartin: Oh, I didn't mean split it out into its own library or whatever. |
| 10:02 | <&McMartin> | If you mean "multiple header files", I might, but it's mostly inconvenient. Right now I have two headers: "the one full of stuff that is exported, in include/" and "the one full of stuff that's used purely internally, in src/" |
| 10:02 | <&McMartin> | I do not consider having SDL.h be full of nothing but 90 sub-#includes to be a feature, even if it does keep individual file sizes down. |
| 10:02 | <&McMartin> | This *absolutely does not apply* to C++ or C#, which have sensible namespace mechanisms. |
| 10:03 | <&jerith> | I meant more along the lines of "document this group of functions as core resource management and that group as bytestream exctraction utilities". |
| 10:03 | <&McMartin> | Oh. |
| 10:03 | <&McMartin> | Yeah, the docs are in flux too. |
| 10:03 | <&McMartin> | My original vision of the design was flatly wrong. |
| 10:04 | <&McMartin> | On to the second question: There is a natural notion of inheritance amongst objects, but thinking about it possibly-not-enough is suggesting that this may be better represented as something closer to entity-trait. |
| 10:04 | <&jerith> | "Favour composition over inheritance." |
| 10:05 | <&McMartin> | I don't usually need to be told twice. |
| 10:05 | <&jerith> | I've been learning that the hard way in recent years. |
| 10:05 | <&McMartin> | This is a case where I'm worried that may be too anarchic. |
| 10:05 | <&jerith> | But there is a place for inheritance. |
| 10:05 | <&McMartin> | Right. |
| 10:06 | <&McMartin> | So, objects will ultimately have "kinds", which is why I'm calling classes so that they do not conflict with C++ or C# keywords. |
| 10:06 | <&McMartin> | *what I'm |
| 10:06 | <&McMartin> | In the most general case, a kind is a list of traits you have, and a list of traits where it is interesting if you have collided with an object with that trait. |
| 10:06 | | * jerith is reminded of a game engine he wrote which had "Item" and "Thing" as base classes. |
| 10:07 | <&McMartin> | I think C# might have "object" as a keyword, but MNCL_OBJECT * is going to be a System.IntPtr over there anyhow, so it will be exposed as something like ObjectID. |
| 10:08 | | You're now known as TheWatcher |
| 10:08 | <&jerith> | (Items are the representation of game ojects which deal with game logic interation. Things are representations of game objects that deal with UI stuff like drawing and clicking.) |
| 10:08 | <&McMartin> | Hmmm. |
| 10:09 | <&McMartin> | I should think about this some more. |
| 10:09 | <&McMartin> | I did ultimately answer the Suicide Koan from codelesscode using entity-trait in Scheme, after all. |
| 10:09 | <&jerith> | (Many game objects have Things but not Items, very few have Items but not Things.) |
| 10:09 | <&McMartin> | Heh. The latter is extremely common in Game Maker Studio. |
| 10:09 | <&McMartin> | Daniel Remar called them "sabots". |
| 10:10 | <&McMartin> | I called them "director" or "gamemaster" objects. |
| 10:10 | <&McMartin> | Hmm. |
| 10:10 | <&McMartin> | I have a half-formed thought that event subscription can be ultimately folded into traits. |
| 10:11 | <&McMartin> | Collisions *have to*, after all. |
| 10:11 | <&McMartin> | I'm holding off on that at first, though, if only because C has no acceptable way of passing lists/sets as arguments. |
| 10:11 | <&McMartin> | (This is a recurring theme.) |
| 10:12 | <&McMartin> | The hidden iterators are looking more like a Stream though. |
| 10:12 | <&McMartin> | But in such a case, an Item is something that has subscribed to at least one of the Update event, and a Thing is something that has subscribed to Draw. |
| 10:13 | <&McMartin> | (That may be too coarse; I know for a fact GM:S needed to add an extra bit for "never draw" vs "default draw" when you don't subscribe.) |
| 10:15 | <&jerith> | In my case, the splitting of game logic and UI stuff was mostly to allow me to write tests that exercised various game logic paths without having to involve pygame. |
| 10:15 | <&jerith> | (This was for a game we wrote in a week.) |
| 10:16 | <&McMartin> | Ah. |
| 10:16 | <&McMartin> | Yeah, I think the equivalent for that here is to synthesize event streams to mock out Monocle itself. |
| 10:16 | <&McMartin> | That's "one level out", I think. |
| 10:17 | <&jerith> | It had the nice side effect of allowing another team member to build a screen editor (the game's a point-and-click adventure) that didn't need to care about game logic when placing Things. |
| 10:17 | <&McMartin> | That is, the game written using Monocle should be written so that its game logic components can be tested independently of the parts that link Monocle. |
| 10:17 | <&McMartin> | Ah yes. |
| 10:17 | <&McMartin> | That's a problem Monocle is Officially Punting On. :D |
| 10:17 | <&McMartin> | The GM:S equivalent of this is Rooms. |
| 10:18 | <&McMartin> | There are too many correct answers. |
| 10:18 | <&jerith> | In our case that just mean not having to fake a bunch of stuff in objects passed to constructors to make the other half happy. |
| 10:18 | | * McMartin nods. |
| 10:18 | <&McMartin> | Well, once I get this design at least hobbling on crutches I'll push. |
| 10:19 | <&McMartin> | I'm aiming to start out by exporting as little as possible, and then expanding as needed. |
| 10:19 | <&jerith> | It *also* let us swap Things for a particular Item to indicate state changes or whatever. |
| 10:19 | <&McMartin> | This has the added advantage that if I have to redesign great swathes of it, I can do so without disrupting the external API as much. |
| 10:19 | <&McMartin> | Mmmm. |
| 10:19 | <&McMartin> | That's a thing I have to think about. |
| 10:19 | <&jerith> | Yup. External APIs should be as small as possible. |
| 10:20 | <&McMartin> | Morphing is a major part of all of these systems I've seen. |
| 10:20 | <&McMartin> | Morphing bugs me, though; I'd rather do a destroy-and-recreate. |
| 10:20 | <&jerith> | I wouldn't hold out Suspended Sentence's architecture as a great example of how to do this stuff. |
| 10:20 | <&McMartin> | Right |
| 10:21 | <&jerith> | It was, after all, written in a week by seven people for a single game. |
| 10:21 | <&McMartin> | I'm using the various systems I've used over the years as touchstones. |
| 10:21 | <&McMartin> | All of them that had a notion of objects had a notion of morphing (that is, transforming an object's type at runtime, possibly to something it wasn't originally castable to) |
| 10:21 | <&jerith> | And two of those people were sick for half the week, with one contributing almost no code because she drew all the pictures. |
| 10:22 | <&McMartin> | I *think* that translates to "you can dynamically add and remove traits from an object, in defiance of its kind", but I'm not sure I can do efficient event streams in the presence of that capability |
| 10:22 | <&jerith> | I don't have a good feel for the event system you're designing here. |
| 10:22 | <&McMartin> | One of my hard design requirements is "if you have 8,000 objects in the system and they cannot be part of event X, then when you're doing iteration over event X, adding objets of that type is O(0)" |
| 10:23 | <&McMartin> | Yeah, it's still a bit nebulous over here, too. |
| 10:23 | <&McMartin> | I'm starting with Just Update And Default Draw. |
| 10:23 | <&jerith> | The only game event system I'm really familiar with is pygame's, and that's very limiting. |
| 10:23 | <&McMartin> | If you have access to a Windows machine, I do recommend messing around with GM:S's demo. |
| 10:24 | <&McMartin> | Anyway, right now there's that event stream that Monocle has that basically steps through the various parts of a frame. |
| 10:24 | <&jerith> | I have very occasional access to my Young Lady's win8 machine and she's typically using that herself during the time I spend futzing about with code. |
| 10:25 | <&jerith> | Will sprite collisions be events? |
| 10:25 | <&McMartin> | I'm going to be enriching that stream with events like "This MNCL_OBJECT * needs to be updated/drawn" or "These two MNCL_OBJECT *s have collided" |
| 10:25 | <&jerith> | Ah. |
| 10:25 | <&McMartin> | *object* collisions will only be events if one's kind is registered to collide with a trait the other has. |
| 10:25 | <&jerith> | Oh, right. |
| 10:26 | <&McMartin> | Making that be efficient is the part I'm banging my head against. |
| 10:26 | <&McMartin> | I have a sketch of a plan, but I can't use it until I prove its worth on unary events like update and draw. |
| 10:26 | <&McMartin> | Oh right, "This MNCL_OBJECT * just got clicked on" would also be an event. |
| 10:26 | <&jerith> | Most of the time I mean "object" when I say "sprite", because pygame only has the former. |
| 10:27 | <&jerith> | But calls it a "sprite". |
| 10:27 | <&McMartin> | Yeah, IIRC, what pygame calls a sprite Monocle calls a spritesheet |
| 10:28 | <&McMartin> | Sprites include hitboxes and also break spritesheets into frames. |
| 10:28 | <&jerith> | A pygame Sprite object only actually has a rect. |
| 10:28 | <&jerith> | And it can belong to Groups. |
| 10:30 | <&jerith> | Oh, a Sprite has an image as well. |
| 10:30 | <&jerith> | But only one. |
| 10:30 | <&McMartin> | Ah, OK. Monocle Sprites are then a Group with a hitbox added. |
| 10:30 | <&McMartin> | The image in a sprite is a Spritesheet. |
| 10:31 | <&jerith> | A pygame Group is a higher level thing that lets you update or draw a bunch of sprites all at once. A Sprite is considered "alive" if it is in at least one Group. |
| 10:31 | <&McMartin> | Hrm. |
| 10:32 | <&McMartin> | OK, how is animation represented? |
| 10:32 | <&jerith> | It isn't. You do that by hand in a Sprite subclass. |
| 10:33 | <&jerith> | http://www.pygame.org/docs/ref/sprite.html |
| 10:34 | <&jerith> | We've never actually used Groups. |
| 10:35 | <&McMartin> | They seem like a very specialized use case. |
| 10:35 | <&jerith> | The docs actually say you should use Group membership instead of boolean attributes or whatever. |
| 10:37 | <&jerith> | So put your bullet sprites in a bullet group instead of having an is_bullet attr on them or whatever. |
| 10:38 | <&McMartin> | God damn I love treesets. |
| 10:39 | <&McMartin> | That doesn't seem like it lets you do things like say "Do bullets hit enemies" meaningfully; you want to know *which* bullet hit *which* enemy. |
| 10:39 | <&jerith> | What is a treeset's advantage over a hashset or something? |
| 10:39 | <&McMartin> | Automatic sorting, easier to prove correct |
| 10:40 | <&McMartin> | More tightly bound space usage, in exchange for O(lg N) cost on all operations forever, guaranteed |
| 10:40 | <&jerith> | Cool. |
| 10:40 | <&jerith> | That's pretty much what I thought. |
| 10:40 | <&McMartin> | Hash tables are O(1) time and variable space if you've got everything tuned perfectly, and if all your hash functions are also perfect |
| 10:41 | <&McMartin> | (The Monocular Vision(tm), incidentally, is that the designer can say "it's interesting when bullets hit enemies" and then you get "this enemy got shot with this bullet" folded into your event stream as needed) |
| 10:42 | <&jerith> | pygame has a spritecollide() function which takes a sprite and a group and returns a list of sprites in the group that the sprite you passed in collide with. |
| 10:43 | <&McMartin> | OK, that'll do the job. |
| 10:44 | <&jerith> | Also groupcollide() that takes two groups and returns a dict mapping sprites in the first group to any sprites in the second group they collide with. |
| 10:46 | <&jerith> | Both of those take "dokill" params which makes them remove colliding sprites from their groups. |
| 10:46 | <&McMartin> | That is almost never what you want. -_- |
| 10:46 | <&jerith> | It is if your use case is "bullets hit enemies" or something. |
| 10:46 | <&McMartin> | "Morph into explosion sprite"~ |
| 10:46 | <&McMartin> | Adjust health, score, etc. |
| 10:47 | <&McMartin> | As long as you have to do those things you might as well do the kill there too. |
| 10:47 | <&jerith> | Indeed. |
| 10:50 | <&McMartin> | My event phases need better names. |
| 10:51 | <&McMartin> | How does "pre-input", "pre-physics", and "pre-render" sound? |
| 10:51 | <&McMartin> | (Those are currently called "pre-update", "update" and "post-update", which is misleading because there's also an update that happens between update and post-update.) |
| 10:57 | <&McMartin> | Oh man, that is ugly >_< |
| 10:57 | <&McMartin> | I'm only supposed to do that kind of shit when hacking in assembler. |
| 10:57 | | * McMartin abuses fall-through. |
| 10:59 | <&McMartin> | mncl_pop_global_event is going to add several years to my sentence in Purgatory. |
| 11:01 | <&jerith> | pre-physics doesn't appeal to me because half the games I've written don't have any. |
| 11:02 | <&McMartin> | That's the one where the user is expected to record any changes to dx, dy, x, y, anim_speed, etc. before those deltas get applied to the position. |
| 11:02 | <&McMartin> | (It also happens before collision checks) |
| 11:05 | <&jerith> | If monocle's handling motion, pre-physics works. |
| 11:07 | <&McMartin> | Yeah, if you define no objects, pre-physics events will never fire. |
| 11:08 | <&McMartin> | Hrm. This draft is going to make me valgrind-unfriendly again. |
| 11:13 | <&McMartin> | (Clean uninitialization is *hard*.) |
| 11:16 | <&jerith> | McMartin: I'm slightly confused as to why earthball.c doesn't segfault when its resource file doen't exist but earthball.py does. |
| 11:16 | <&jerith> | I'm making exactly the same function calls in exactly the same places. |
| 11:18 | <&jerith> | (Neither version does error checking on the resource stuff unless I missed something in earthball.c.) |
| 11:19 | <&McMartin> | I have at least one unpushed patch for misbehavior there |
| 11:19 | <&jerith> | Ah. |
| 11:20 | <&McMartin> | Hrm. |
| 11:20 | <&McMartin> | Well, there's a bunch of NULLs that come back |
| 11:20 | <&McMartin> | But most of Monocle can accept NULL pointers. |
| 11:20 | <&McMartin> | Is cffi doing some forcible dereferencing? |
| 11:20 | <&jerith> | I *should* be passing those straight back in. |
| 11:21 | <&McMartin> | The bug I fixed is that if you try to load a nonexistent resource, it stays nonexistent even if you later add a resource directory/zipfile that can supply it. |
| 11:22 | <&jerith> | Thread 0 Crashed:: Dispatch queue: com.apple.main-thread |
| 11:22 | <&jerith> | 0 _cffi_backend.so 0x000000010db2bbee read_raw_signed_data + 55 |
| 11:22 | <&jerith> | 1 _cffi_backend.so 0x000000010db2ab91 convert_to_object + 31 |
| 11:22 | <&jerith> | 2 org.python.python 0x000000010d5fd3b1 0x10d5eb000 + 74673 |
| 11:22 | <&jerith> | 3 org.python.python 0x000000010d6045a9 PyEval_EvalFrameEx + 9244 |
| 11:22 | <&jerith> | Looks like cffi's doing something. |
| 11:23 | <&jerith> | Ah. |
| 11:24 | <&jerith> | Having added some breadcrumb prints I've discovered that it *is* happening in a place where earthball.py does things differently. |
| 11:25 | <&jerith> | Instead of hardcoding sizes and frame counts, I look them up on the sprite object. |
| 11:25 | | * McMartin nods |
| 11:25 | <&jerith> | Which is NULL. |
| 11:25 | <&McMartin> | The next push will hopefully remove all that logic out of earthball.c entirely. |
| 11:25 | <&jerith> | Mystery solved. |
| 11:25 | <&McMartin> | It'll just set anim_speed to 1.0f. |
| 11:26 | <&jerith> | Is that in frames or something? |
| 11:26 | <&McMartin> | frames per, uh, frame. |
| 11:26 | <&McMartin> | if you want to only update the sprite every other frame you set it to 0.5. |
| 11:27 | | * jerith nods. |
| 11:27 | <&McMartin> | (Everything in the object is floats, and they get truncated as needed in the render step inside the library.) |
| 11:27 | <&jerith> | Animation frames per render frame, rather than animation frames per second or somesuch. |
| 11:27 | <&McMartin> | Right. |
| 11:28 | <&jerith> | That will be exciting when your framerate varies. |
| 11:28 | <&McMartin> | Don't do that~ |
| 11:28 | <&McMartin> | Or, you know, go ahead and do that, but know what you're doing. |
| 11:29 | <&McMartin> | (Setting the timestep will be a global thing. You should probably only do that once.) |
| 11:29 | <&jerith> | I was thinking more of the case where you have a million sprites on the screen and they take longer to update/render than a timestep allows. |
| 11:30 | <&McMartin> | Yeah. I'm not interested in that case; doing that case right requires a significantly different operational theory. |
| 11:31 | <&jerith> | I only mention it because we've always had to do a bunch of surface format juggling to get pygame to draw our frames in a reasonable amount of time. |
| 11:32 | <&McMartin> | SDL2 is supposed to help with that a lot. |
| 11:32 | <&McMartin> | At least as long as you're using SDL_Textures instead of SDL_Surfaces, which I am. |
| 11:34 | <&McMartin> | (Since SDL_Textures live in the GPU) |
| 11:34 | | VirusJTG [VirusJTG@Nightstar-6i5vf7.sta.comporium.net] has joined #code |
| 11:38 | <&jerith> | Are you going to have an API for building images? |
| 11:38 | <&McMartin> | Probably not; imagemagick already exists. |
| 11:38 | <&McMartin> | (This is also why I'm punting on Rooms) |
| 11:39 | <&jerith> | More along the lines of "draw the background, then these two things, the sprites on top of that". |
| 11:39 | <&McMartin> | Oh. |
| 11:39 | <&McMartin> | Yeah, there are PRERENDER and POSTRENDER events for that. |
| 11:40 | <&McMartin> | "Draw the background then these two things" is pre-render, and then "draw the HUD" is POSTRENDER. |
| 11:40 | <&McMartin> | I need a scene sorter too but that's for later. |
| 11:40 | <&McMartin> | Objects have a depth. |
| 11:40 | <&jerith> | Or "give me a sprite with this spritesheet resource, but yellow". |
| 11:41 | <&McMartin> | Thinking about that |
| 11:42 | <&McMartin> | Not sure if I can do it without having to go out to OpenGL by hand. |
| 11:42 | <&jerith> | Basically, will I ever be blitting stuff myself? |
| 11:42 | <&McMartin> | Backgrounds will. That stuff is in the framebuffer chunk of the API. |
| 11:42 | <&McMartin> | If I can do color blending with SDL_Renderer, then I'll probably expose that. |
| 11:44 | <&McMartin> | mncl_draw_from_spritesheet is the custom blit. |
| 11:44 | <&jerith> | Our pygame code often builds a game object's image out of a base and zero or more overlays. |
| 11:44 | <&McMartin> | If you want to do something like that you "subscribe" to the Render event. |
| 11:44 | <&McMartin> | The obvious case here is that if you're a platformer you have to pick the facing-left vs facing-right sprite. |
| 11:45 | <&jerith> | Then we cache the constructed image and just blit it as necessary. |
| 11:46 | <&jerith> | "mirror horizontally" is one of our overlays. |
| 11:46 | <&McMartin> | Yeah, I don't expect to cover that, if only because reading out of the GPU is insanely expensive. |
| 11:47 | <&jerith> | This is stuff that would sit between the resource and the sprite or whatever. |
| 11:47 | <&McMartin> | Yeah, but that assumes I know about pixels. I don't. |
| 11:48 | <&McMartin> | Now, with raw OpenGL you can pick your vertices differently to do flips like that. |
| 11:48 | <&McMartin> | I haven't dug deep enough to see if I can get away with that |
| 11:48 | <&jerith> | It's certainly possible to pregenerate all of that, though. |
| 11:48 | <&McMartin> | Sure |
| 11:49 | <&McMartin> | That said, if I expose something like this, it'll be translating to still a pair of triangles sent to the renderer |
| 11:49 | <&jerith> | Although there's a use case for "pick an arbitrary colour for each team" or whatever. |
| 11:49 | <&McMartin> | Sure |
| 11:49 | <&McMartin> | I know how to do that with OpenGL too~ |
| 11:49 | <&McMartin> | But I don't want to use OpenGL until I have to. |
| 11:50 | <&McMartin> | Especially if SDL_Renderer has prizes |
| 11:51 | <&McMartin> | It looks like SDL_Get/SetTextureColorMod would let me do copies. |
| 11:51 | <&jerith> | This all falls into "construct the image/texture before doing anything with it" territory, so I suppose just having a way to hook into that would be sufficient. |
| 11:52 | <&jerith> | I don't actually know SDL at all. |
| 11:52 | <&McMartin> | I'm not seeing an easy way to encapsulate mirroring, though positive scaling is possible. |
| 11:52 | <&McMartin> | Whoop, there it is. |
| 11:52 | <&McMartin> | SDL_RenderCopyEx |
| 11:53 | <&McMartin> | This is all brand new stuff in SDL2. |
| 11:53 | <&jerith> | Does Monocle cut the spritesheet into separate images to hand to SDL? |
| 11:53 | <&McMartin> | SDL_RenderCopyEx *also* does arbitrary rotations. |
| 11:53 | <&McMartin> | No. Each spritesheet is a single SDL_Texture. |
| 11:53 | <&jerith> | Ah. |
| 11:54 | <&McMartin> | Then it calls SDL_RenderCopy, which lacks the roto- part of the rotozoom, and sets srcrect as demanded. |
| 11:54 | <&McMartin> | So what you describe could be added, but it will probably be for v1.1. |
| 11:56 | <&jerith> | What I'm describing is actually preprocessing the spritesheet rather than anything at render-time. |
| 11:56 | <&McMartin> | Right. |
| 11:56 | <&McMartin> | I'm saying "Instead of doing that I will instead expose the kind of tricks you can do with 2D accelerated rendering, like rotozoom and color tinting" |
| 11:57 | <&jerith> | Which is insufficient (and also inefficient) for the kind of stuff I've done in the past. |
| 11:57 | <&McMartin> | I strongly suspect that's because you were using software renderers. |
| 11:57 | <&jerith> | To be clear, I'm not asking for features here. |
| 11:58 | <&McMartin> | Right. I'm pointing out that you're thinking about this wrong. |
| 11:58 | <&jerith> | I could be. |
| 11:58 | <&McMartin> | To say "draw this but color it yellow", you do that by calling glColor3f(1.0, 1.0, 0.0) instead of glColor3f(1.0, 1.0, 1.0). |
| 11:59 | <&McMartin> | To do horizontal flip, you submit the vertices or the the texture coordinates for your quad in a different order. |
| 11:59 | | Stalker [Z@Nightstar-484uip.cust.comxnet.dk] has quit [Ping timeout: 121 seconds] |
| 11:59 | <&McMartin> | To mess with individual pixels, you have to lock GPU RAM and do a bunch of roundtrips with it, which is insanely expensive. |
| 12:00 | <&McMartin> | (And this is why the video aspects of SDL1 and SDL2 look so dissimilar.) |
| 12:00 | <&jerith> | This wouldn't touch GPU RAM at all. |
| 12:01 | <&McMartin> | You can create a spritesheet by feeding something a byte array with a PNG in it, though that isn't directly exposed at present. |
| 12:01 | <&McMartin> | Once you've fed it to the spritesheet constructor, though, that's basically all she wrote |
| 12:02 | <&jerith> | This would be "create an unarmored-chicken sprite from the base spritesheet and a chicken-with-kevlar-and-helmet sprite from the base spritesheet with these two overlays applied". |
| 12:02 | <&McMartin> | OK, "I don't believe you when you say that's too expensive, given that GML is basically Javascript" |
| 12:03 | <&jerith> | (I'm pretty sure that's how we did it in Operation Fox Assault back in 2009, except with individual images rather than spritesheets.) |
| 12:03 | <&McMartin> | Right. |
| 12:04 | <&McMartin> | So, SDL2's renderer is based on 3D acceleration, just without the 3D part. OpenGL or Direct3D, it AIUI has backends for both. |
| 12:04 | <&McMartin> | Every time you render a sprite you're drawing two textured triangles. |
| 12:04 | <&McMartin> | Even for an extremely busy scene I strongly suspect that your ultimate polycount will still be comically low. |
| 12:05 | <&McMartin> | And I'm only going to be convinced otherwise with demos showing it to be the bottleneck~ |
| 12:05 | <&jerith> | Ah. So you're saying that doing the composition at render time by drawing three sprites instead of one is actually a better idea? |
| 12:06 | <&McMartin> | Yes, because it's the equivalent of submitting six triangles, which is Basically Nothing. |
| 12:06 | <&jerith> | If so, I'm quite happy with that. |
| 12:07 | <&McMartin> | My reason for being pretty sure this is OK is because every brick in Spelunky is rendered as a sprite using an implementation language that is a JavaScript clone, *before* they wrote an industrial strength compiler for it. |
| 12:07 | <&McMartin> | That gives me some confidence that performance is unlikely to be an issue unless I stupidly require a lot of pointless iteration. |
| 12:07 | <&jerith> | Yeah. My only experience with this kind of thing has been pygame's software blitting. |
| 12:08 | <&McMartin> | (Which is why I'm fretting so much about kinds and traits, so that I can exclude stuff without ever looking at it at all) |
| 12:09 | <&jerith> | Can you explain the purpose of kinds and traits? |
| 12:09 | <&jerith> | (If you already did I've forgotten.) |
| 12:10 | <&McMartin> | kinds are basically classes. We want to be able to express the notion of "this is a player bullet" |
| 12:10 | <&McMartin> | Traits are what we have instead of inheritance. |
| 12:11 | <&McMartin> | Traits either subscribe you to a fixed event every frame (custom render, custom pre-physics step, etc), subscribe you to targeted user events (mouse clicks), or are involved with collisions. |
| 12:12 | <&jerith> | Maybe something similar to pygame's Groups would work here? |
| 12:12 | <&McMartin> | Traits are very similar to groups, but there is no requirement that an object belong to only one. |
| 12:12 | <&jerith> | A sprite knows which groups it belongs to and each group knows which sprites belong to it. |
| 12:12 | <&McMartin> | Each object belongs to exactly one kind, and each kind entails a set of traits it has and a set of traits it collides with. |
| 12:13 | <&McMartin> | These are specified in the resource JSON. |
| 12:13 | <&jerith> | pygame Sprites can belong to multiple groups. |
| 12:13 | <&McMartin> | Traits are very similar to groups, then, but their API is modified because while pygame can pass lists around, C APIs can't really do so, so they instead enrich the event stream you consume. |
| 12:14 | <&McMartin> | Certain traits function like groupcollide(), phase traits function more like for x in group.sprites() |
| 12:15 | <&McMartin> | And it's probably nicer to the user to have "invisible" be the trait instead of "defaultrender". |
| 12:15 | <&jerith> | Would you get an event per trait or an event per object with that trait? |
| 12:16 | <&McMartin> | For phase traits, event per object per trait. |
| 12:16 | <&McMartin> | If you register for pre-physics and pre-render, you get those callbacks in that order. |
| 12:16 | <&McMartin> | For collision traits, there is one collision event per "interesting" collision. |
| 12:17 | <&McMartin> | Which is to say, there is no notion of self/other in collision events. |
| 12:17 | | * jerith nods. |
| 12:17 | <&McMartin> | Within a phase, objects with that phase trait will get the events in an arbitrary but consistent order *except for render*, which will fire them off from back to front. |
| 12:18 | <&McMartin> | Because, well, scene sorting. |
| 12:18 | <&McMartin> | (The arbitrary but consistent order is actually based on comparison of their int_ptr_t values) |
| 12:19 | <&McMartin> | (This isn't guaranteed to mean anything in particular, but I believe there is a guarantee that the int_ptr_t of two distinct objects will be a different integer, and it won't be 0 unless the pointer is NULL.) |
| 12:20 | <&jerith> | Does the kind matter at all at runtime or is it just a way of applying sets of traits at creation time? |
| 12:20 | <&McMartin> | I am leaning strongly towards the latter, but I haven't developed this aspect of the design enough yet. |
| 12:21 | <&McMartin> | My intuition is that dynamically mutating object traits at run time is a gigantic can of worms. |
| 12:21 | <&jerith> | And traits are just labels that are used when setting up which events are interesting for which objects? |
| 12:21 | <&McMartin> | Largely so. |
| 12:22 | <&McMartin> | I'm pretty sure I'm going to require all kinds and traits be defined before the creation of your first object, because I'll be building some kind of crazy multilevel index based on then. |
| 12:22 | <&McMartin> | *them |
| 12:23 | <&jerith> | That doesn't seem entirely unreasonable. |
| 12:23 | <&jerith> | Hrm. |
| 12:24 | <&McMartin> | (Right now I have one master treeset that owns All The Objects, and then one treeset per phase that gets the objects added to them if their traits say they care about that phase) |
| 12:24 | <&jerith> | What you actually care about is which events involve which objects. |
| 12:24 | <&McMartin> | (And I haven't gotten to collisions yet but that will probably be an array of treesets of objects indexed by trait ID) |
| 12:24 | <&McMartin> | Right. |
| 12:24 | <&McMartin> | Oh, right. |
| 12:24 | <&McMartin> | Kinds *do* exist at runtime, in a trivial sort of way. |
| 12:25 | <&McMartin> | When you create a new object, you specify its traits by identifying its kind. |
| 12:25 | <&McMartin> | "Build me a new player bullet". It then racks it up appropriately and hands you a structure to fill in with initial position/velocity/etc. |
| 12:25 | <&McMartin> | Kinds may ultimately include sensible defaults for all these things (default sprite at the very least). |
| 12:26 | <&jerith> | I wasn't actually including "object creation time" in "runtime". It was a bad choice of phrasing. |
| 12:27 | <&jerith> | What I meant was "anything involving already-created objects". |
| 12:28 | <&jerith> | So the object doesn't actually need to know its kind, only its traits. |
| 12:28 | <&McMartin> | It actually doesn't even need to know that~ |
| 12:28 | <&McMartin> | The *event processor* needs to know the traits of all objects. |
| 12:29 | <&McMartin> | It will probably have wiped out the kind information while sorting that out, but if it turns out kinds are handy there, I won't hesitate to pull them in. |
| 12:29 | <&McMartin> | (It might, for instance, make sense to say "every kind is also the trait that means collisions with it are important") |
| 12:29 | <&McMartin> | Er, the name of every kind is also the name of a trait that &c |
| 12:31 | <&jerith> | Are events things that I provide callbacks for or things that I receive and inspect? |
| 12:32 | <&jerith> | Or are there both kinds of events? |
| 12:32 | <&McMartin> | The former. Languages with first-class functions are expected to provide some kind of callback mechanism as their exposed binding, though. |
| 12:32 | <&McMartin> | Er. |
| 12:32 | <&McMartin> | The latter, rather. |
| 12:33 | <&McMartin> | You get a stream of events you look at, and I intend the Scheme bindings to turn those into a series of calls to registered callbacks. |
| 12:33 | <&jerith> | So the event needs to provide trait information. |
| 12:33 | <&McMartin> | Mmm. Whyso? |
| 12:33 | <&McMartin> | You know what kind of event you're getting. |
| 12:33 | <&jerith> | It's important to differentiate between a collision with a wall and a collision with an enemy. |
| 12:33 | <&McMartin> | Sure. Collision events name two objects. |
| 12:34 | <&McMartin> | Mmm. |
| 12:34 | <&jerith> | Then the objects need to know their traits. |
| 12:34 | <&McMartin> | Right. |
| 12:34 | <&McMartin> | That's tricky. |
| 12:34 | <&McMartin> | If something is a wall *and* an enemy, there should still be only one collision event sent. |
| 12:35 | <&McMartin> | I think in this case it may make more sense for objects to know their kinds, and for kinds to be interrogatable. |
| 12:35 | <&McMartin> | That said, this may be something the wrapper handles, or even cuts more finely. |
| 12:35 | <&McMartin> | Each MNCL_OBJECT * will be associated with some C++ object in the C++ bindings, for instance, but there is no requirement that all objects with the same monocle "kind" be the same class in the C++ version. |
| 12:35 | <&jerith> | Do all objects have exactly one kind? |
| 12:36 | <&McMartin> | Yes. |
| 12:36 | <&McMartin> | (Since kinds only *definitely* exist as the object constructor, they are the equivalent of the constructed type.) |
| 12:37 | <&jerith> | There's a bunch of fuzziness here. |
| 12:37 | <&McMartin> | As I think I've mentioned multiple times; I haven't actually done the design here yet. |
| 12:38 | <&jerith> | I know. I'm trying to build a mental model of the shape of the thing. |
| 12:38 | <&jerith> | Probably prematurely. :-) |
| 12:38 | <&McMartin> | I'm not even 100% sure that kinds beyond the notational convenience end up being game-significant, or if that's handled by something in the bindings. |
| 12:39 | <&McMartin> | I'm also not sure if I have to solve the multiple dispatch problem. =P |
| 12:39 | <&jerith> | And the fuzziness I mentioned was in the problem, not the system. |
| 12:39 | <&McMartin> | Yeah. |
| 12:39 | <&McMartin> | I mean, some of the fuzziness here is "It's sensible to want collisions with walls to have a different callback than collisions with enemies" |
| 12:39 | <&jerith> | "enemy bullet" seems like a reasonable kind, but there might be twelve different flavours. |
| 12:40 | <&McMartin> | But then we're also leaning, due to our hatred of inheritance, towards "there is nothing stopping an object from being a wall *and* an enemy" |
| 12:40 | <&McMartin> | That's twelve kinds, and they all probably each cite the trait "hazard" |
| 12:41 | <&McMartin> | If you've got a more traditional object system, actually, you're probably going to have to turn single collision events into multiple method calls. |
| 12:41 | <&McMartin> | But, well, that's on you as the client. |
| 12:42 | <&McMartin> | This is where the question of whether enforcing inheritance is useful or not. |
| 12:42 | <&jerith> | So you'd be interested in collisions between objects with the "player" and "hazard" traits and then you'd look for traits like "explodes" or "laserbeam" on the hazard. |
| 12:42 | <&McMartin> | Right. |
| 12:42 | <&McMartin> | Actually, "player" is probably a special object whose value you have cached and know instantly. |
| 12:42 | <&McMartin> | So at this point you know "the player hit something important" |
| 12:42 | <&jerith> | Non-hazards could also have "explodes" or "laserbeam" in their traits. |
| 12:43 | <&McMartin> | Indeed. |
| 12:43 | <&McMartin> | Like, say, player weapons. |
| 12:43 | <&jerith> | If you build an object with both "laserbeam" and "explodes" traits on it, you get to decide what to do with the collision. |
| 12:44 | <&McMartin> | I'm not planning on ML bindings here. |
| 12:45 | <&McMartin> | But it would be super-natural to define your client to have some type where each trait involved in collisions is a constructor |
| 12:45 | <&McMartin> | And then just having one "collision x y" function with a mega-case. |
| 12:45 | <&McMartin> | ... that implies I ought to put a total ordering on traits. |
| 12:45 | <&McMartin> | Er |
| 12:45 | <&McMartin> | On kinds. |
| 12:46 | <&McMartin> | Hrm, that still doesn't help~ |
| 12:47 | <&jerith> | Chipmunk (the physics engine) solves the "enemy *and* wall" problem by requiring exactly one "collision type" per shape. |
| 12:48 | <&McMartin> | I dislike that, if only because I know GM:S didn't require it~ |
| 12:48 | <&McMartin> | It did, however, enforce strict single inheritance. |
| 12:48 | <&jerith> | I'm not sure what happens if you set handlers for both (a, b) and (b, a). |
| 12:48 | <&McMartin> | In the ML case, I think you'd have to, because there's no way to get a total order in the general case. |
| 12:49 | <&McMartin> | Talking through it, I'm leaning towards this, though: |
| 12:49 | <&jerith> | You can make traits sortable, though. |
| 12:49 | <&McMartin> | Sure. |
| 12:49 | <&jerith> | Well, ordered. |
| 12:49 | <&McMartin> | But you don't *get* traits. You get objects. |
| 12:49 | <&McMartin> | You aren't told - because it's not how subscription works - *which* traits were involved with the collision. |
| 12:49 | <&McMartin> | That may be a bad decision. |
| 12:50 | <&McMartin> | It might be better to fabricate one collision event for every trait with an interesting collision. |
| 12:50 | <&McMartin> | That is, player registers wall and hazard as interesting traits, hitting an acid floor fires two events. |
| 12:51 | <&McMartin> | Mmmm. |
| 12:51 | <&McMartin> | That reopens the self/other question, too. |
| 12:51 | <&jerith> | My proposal was to provide a list of the interesting trait-pairs in the evnt. |
| 12:51 | <&jerith> | *event |
| 12:51 | <&McMartin> | There is not an obvious gain there over just firing multiple events, and there is an obvious loss - the need to transfer lists across a C interface. |
| 12:52 | <&jerith> | So in your example you'd get a collision with the player, the acid wall and [(player, acid), (player, wall)]. |
| 12:52 | <&McMartin> | Right, this is where self/other gets interesting. |
| 12:52 | <&McMartin> | (Oh right; I have a secret goal here that doing collision detection and running the event streams should involve no heap allocation) |
| 12:53 | <&jerith> | The obvious gain over firing multiple events is that the client doesn't need to handle multiple events for the same collision. |
| 12:53 | <&McMartin> | ... It may be that it's 5 AM here, but this is not an obvious gain. |
| 12:54 | <&McMartin> | If you fire multiple events per interesting trait pair and order it "self/other", the client can handle it with "blind" double dispatch. |
| 12:54 | <&McMartin> | As long as the client knows the full set of traits (in C++ and C#), and can do so with hasattr trickery in Python completely generally. |
| 12:55 | <&McMartin> | If you return a complicated marshalled data type, the client handler has to interpret it and do all the forwarding itself |
| 12:56 | <&McMartin> | And my intuition now is that this will turn into making two function calls (player hits acid, player hits wall, wall gives no shits) and in the fully-multiplicative event case, that would have only been two events in the first place |
| 12:56 | <&McMartin> | (Since the acid-wall kind doesn't register any interesting collisions because it is a wall and gives no fucks) |
| 12:57 | <&jerith> | Hrm. |
| 12:57 | <&jerith> | That makes sense. |
| 12:57 | <&McMartin> | This then also makes the hypothetical ML case trivial |
| 12:58 | <&McMartin> | Self/Other in this case actually becomes Kind/Trait, come to think of it. |
| 12:58 | <&jerith> | Acid wall is probably a poor example, because "acid" is more likely to be a non-colliding trait that you look for when handling collisions. |
| 12:58 | <&McMartin> | Probably. |
| 12:58 | <&McMartin> | "Player" / "Hazard" is pretty solid as a general reaction though. |
| 12:59 | <&McMartin> | That's where you put the damage routine. |
| 12:59 | <&jerith> | "enemy" and "wall" is a more interesting one. |
| 12:59 | <&McMartin> | I'm strongly suspecting that any binding system is going to need some kind of map that uses MNCL_OBJECT * values as the key to look up game logic-specific data (like how much damage a bullet does) |
| 13:00 | <&jerith> | You may want to treat that object as a wall for collisions with players but an enemy for collisions with bullets. |
| 13:00 | <&McMartin> | If you have that case, I think your ontology needs some work. |
| 13:01 | <&McMartin> | Alternately: That enemy has to list what it's interested in collisions with. It'll have the trait that bullets care about that means "hit it"; walls probably have that trait too, really. |
| 13:01 | <&McMartin> | It will also have a flag that says "Let me know if I get hit with bullets so I can take damage appropriately" |
| 13:02 | <&McMartin> | Setting up inheriting *behavior* like that is the job of the client, though. |
| 13:02 | <&jerith> | Things like damage and such are entirely outside Monocle's domain, right? |
| 13:03 | <&McMartin> | Yeah. |
| 13:03 | <&jerith> | Will objects have a way to attach arbitrary data? |
| 13:04 | <&jerith> | Or will the game have to keep that separately? |
| 13:04 | <&McMartin> | No, because FFI. That's explicitly a job for Pymonocle/Monocle++/etc. |
| 13:04 | <&jerith> | Cool. |
| 13:04 | <&McMartin> | The int_ptr_t interpretation of MNCL_OBJECT * is intended to be used as the master key to get The Rest Of The Data. |
| 13:05 | <&McMartin> | But the right way to collect that data varies by bound language. |
| 13:05 | <&McMartin> | So Monocle kicks it out a level. |
| 13:05 | <&jerith> | What is int_ptr_t exactly? |
| 13:06 | <&McMartin> | It's the integral type guaranteed to be large enough that you can cast a pointer to it and back to a pointer of the same type without loss of information. |
| 13:06 | <&jerith> | So in this case you're using the memory address of the object as its identifier. |
| 13:06 | <&McMartin> | Correct. |
| 13:07 | <&jerith> | Python does that for objects. |
| 13:07 | <&McMartin> | Well, actually, it's the memory address of the mutable part of it. |
| 13:07 | <&McMartin> | Java also does this for objects; it's the System.identityHashCode() of the object. |
| 13:07 | <&jerith> | The downside is that identifiers are only guaranteed unique for objects with overlapping lifetimes. |
| 13:08 | <&McMartin> | This is acceptable, as Monocle will never destroy an object unless the client requests it. |
| 13:08 | <&McMartin> | The client should delete the relevent entry in its map when it makes that request. |
| 13:08 | <&jerith> | Cool. As long as you document that it should be fine. :-) |
| 13:08 | <&McMartin> | Yeah |
| 13:09 | <&McMartin> | A lot of this stuff will firm up as Monocle++ and PyMonocle evolve. |
| 13:09 | <&McMartin> | I am imagining that PyMonocle will be able to wrap a lot more stuff within itself, while Monocle++ will require the code structure and the resource structure to be closer. |
| 13:10 | <&jerith> | Python is a much higher-level language than C++, after all. |
| 13:10 | <&McMartin> | That's not the relevant part here, though. Objective-C lives at the same level that C++ does and it could do similar tricks. |
| 13:11 | <&McMartin> | It's that Python has much better introspection capabilities and also has Smalltalk-like method call semantics. |
| 13:11 | <&jerith> | Ah, right. |
| 13:13 | | ErikMesoy|sleep is now known as ErikMesoy |
| 13:14 | <&McMartin> | Well, this has helped a lot. :D |
| 13:14 | <&McMartin> | I have a firmer idea of the design. |
| 13:14 | <&McMartin> | I *don't* have a roadmap, though. |
| 13:15 | <&jerith> | Glad I could help. :-) |
| 13:17 | <&jerith> | I don't have the experience or the desire to dig around in the C/C++ code much (except maybe for debuggery when pymonocle does strange things), but I do enjoy API design. |
| 13:17 | <&jerith> | I realy want to use pymonocle for a pyweek game at some point, but that requires packaging madness. |
| 13:19 | <&McMartin> | I have a draft of the absolute basics for update/render objects, but it segfaults instantly. ;-) |
| 13:20 | <&jerith> | Do you have any bits in a pushable state yet? |
| 13:21 | <&McMartin> | No, because it segfaults instantly~ |
| 13:21 | <&McMartin> | Once I figure out what's not working, it'll be pushable. |
| 13:21 | <&jerith> | API removals and such, I mean. |
| 13:21 | <&jerith> | Or is that part of the object things? |
| 13:21 | <&McMartin> | Yeah, I don't; a lot of this is all of a piece. |
| 13:21 | <&jerith> | Cool. |
| 13:23 | <&McMartin> | Found it. |
| 13:23 | <&McMartin> | Bug was, of course, in the stopgap code. -_- |
| 13:24 | <&jerith> | Is there any C++ in Monocle yet? |
| 13:24 | <&McMartin> | So, no kinds, all objects define only the "pre-physics" trait, which is still called "update", and pointedly do not define "invisible" or "customrender" |
| 13:25 | <&jerith> | I've only looked at header files, but github lists it as 100% C. |
| 13:25 | <&McMartin> | Yeah. |
| 13:25 | <&McMartin> | That hasn't always been true. |
| 13:25 | <&McMartin> | There was originally some C++ in Monocle. |
| 13:26 | <&McMartin> | Then I tried to link anything else against it. |
| 13:26 | <&McMartin> | Then I spent a weekend implementing my own red-black trees. |
| 13:26 | <&McMartin> | (Because I didn't like the ones in FreeBSD.) |
| 13:26 | <&jerith> | So you've switched to pure-C instead of C++-with-a-C-API? |
| 13:26 | <&McMartin> | Yes. C++ has a number of intensely undesirable properties. |
| 13:27 | <&McMartin> | Or rather. |
| 13:27 | <&McMartin> | libstdc++ has a number of intensely undesirable properties. |
| 13:27 | <&McMartin> | I intend to link C++ *against* libmonocle in some of the demo programs, and this will include some code that people using C++ to interface to Monocle will be expected to co-opt. |
| 13:28 | <&McMartin> | But that is more in terms of "a skeletal framework to fill in". |
| 13:28 | <&jerith> | Cool. |
| 13:28 | <&McMartin> | C++ and shared libraries *do not mix*. |
| 13:28 | <&McMartin> | There are about 12 compiler options people set for various reasons in C++ and every single one of them breaks ABI compatibility. |
| 13:29 | <&jerith> | How do people use other people's C++ code, then? |
| 13:29 | <&McMartin> | By compiling their own copies of the C++ libraries from source, or by setting all their compiler options exactly the same as the code they are using. |
| 13:29 | <&McMartin> | One dictates terms for the other. |
| 13:29 | <&jerith> | Ah. |
| 13:29 | <&McMartin> | This is easier to do when, say, one runs a distro and can set all C++ projects to build with the same options. |
| 13:30 | <&jerith> | That sounds like a horrible environment. |
| 13:30 | <&McMartin> | Right, also, the .so will require you to use g++ to do the link step at the end so that everything is properly demangled, even though you didn't *think* you were exporting any of that. |
| 13:31 | <&McMartin> | And given that the only C++ things I was using were std::string and std::map... |
| 13:31 | <&McMartin> | ... oh hey, it's working now |
| 13:31 | <&McMartin> | Gonna run through what unit tests I have left and then gonna push. |
| 13:31 | <&jerith> | So Monocle++ will be source that build with your project instead of a library to link against or something? |
| 13:32 | <&McMartin> | Yeah. |
| 13:32 | <&jerith> | *that you build |
| 13:32 | <&jerith> | Not that I have any intention of ever writing a game in C++. |
| 13:32 | <&McMartin> | Shoot The Thing will probably be in C++. |
| 13:33 | <&jerith> | I can probably read C++ well enough to translate it to idiomatic Python. |
| 13:33 | <&jerith> | Assuming it's well-written and there isn't very much of it. |
| 13:34 | | * McMartin nods |
| 13:34 | <&McMartin> | Ideally, you would write your own game in pymonocle to ship as a demo instead of just porting whatever the other things are, though. :D |
| 13:37 | <&jerith> | I'm going to start with pymonocle implementations of whatever demos you write just to make sure I'm wrapping things sensibly. |
| 13:39 | <&jerith> | Also, I'm bad at coming up with ideas for demo-sized games. |
| 13:39 | < ErikMesoy> | Snake! |
| 13:39 | <&McMartin> | Snake isn't really awesome for Monocle, tbh. |
| 13:40 | <&jerith> | ErikMesoy: http://mutable-mamba.org/ |
| 13:40 | <&McMartin> | I mean, you could do it, but it doesn't actually use the library for much. |
| 13:40 | <&jerith> | Mine ended up being far from demo-sized. ;-) |
| 13:41 | <&McMartin> | It's pushed. |
| 13:41 | <&jerith> | McMartin: If Monocle gives me a better way to draw things to the screen and play music/sfx than pygame does, I'll consider it a win. |
| 13:41 | <&McMartin> | earthball.c is... different now |
| 13:42 | <&jerith> | I guess this is my cue to go rewrite pymonocle again. :-) |
| 13:42 | <&McMartin> | Maybe. |
| 13:43 | <&McMartin> | Unless you're hurting for things to do, it might behoove one to wait until kinds, traits, and collision detection existed |
| 13:44 | <&McMartin> | Also, I see github has decided that monocle_internal.h is C++ again. |
| 13:44 | <&McMartin> | I'm not really sure how it decides this. |
| 13:45 | <&jerith> | Maybe it's the "extern" thing. |
| 13:45 | <&McMartin> | Mmm. You could be right. |
| 13:45 | <&jerith> | And monocle.h doesn't trigger it because there's too much other stuff. |
| 13:46 | <&McMartin> | Heh. Actually, unless you have extern "C" behind an ifdef, it's 100% sure it's C++~ |
| 13:46 | | * McMartin ran into that earlier. |
| 13:47 | <&McMartin> | Anyway, of note is also that every phase gets an event fired with a "NULL" object if objects can have a phase trait for it |
| 13:47 | <&McMartin> | That's for dealing with global stuff. |
| 13:47 | <&McMartin> | The NULL event always happens first. |
| 13:50 | <&McMartin> | earthball.c looks a lot more like what I want it to ultimately look like, though. |
| 13:50 | <&McMartin> | The only part that's really left to change is that eventually there will be kinds it needs to define and use (and there will be one) |
| 13:51 | <&McMartin> | ... and it can probably have a slightly cleaner update function if it uses pre-render instead of pre-physics. |
| 13:51 | <&McMartin> | aaaaaactually, I don't need a pre-render step since only the global function can use that anyway, and it gets called first every time anyway. |
| 14:48 | <@Azash> | https://pbs.twimg.com/media/BaY1gMTIYAAnagt.png:large |
| 14:48 | <@Azash> | Makes sense |
| 14:48 | <@gnolam> | ? |
| 14:49 | <@Azash> | gnolam: The opened question in the FAQ |
| 14:49 | <@gnolam> | Yes? |
| 14:57 | <@Azash> | Also, roommate opened our rack UPS up to see how it was faring |
| 14:57 | <@Azash> | http://i.imgur.com/O0y3sUK.png |
| 15:03 | <&jerith> | McMartin: Some of your function declarations in monocle.h have a space between the function name and the opening paren. Is that deliberate? |
| 15:20 | <@Tarinaky> | There is an argument that there is a 'gotcha' with Tor that if one organisation runs the majority of the nodes it becomes possible for the organisation to build non-anonymous data or something. |
| 15:20 | <@Tarinaky> | I don't know Tor well enough to confirm or deny this though. |
| 15:28 | <@Tarinaky> | http://thecodelesscode.com/case/120 |
| 15:28 | < Syka> | if you own the entry nodes and the exit nodes and all the nodes, then yes |
| 15:29 | <@Tarinaky> | Syka: Well since even basic requests involve the sending of multiple packets - and the NSA asserts they only record who you're talking to and not what is said I imagine there must be some magic percentage where you get adequate coverage. |
| 16:05 | <&jerith> | I know exactly how this one is going to end: "A monk of the Laughing Monkey Clan was well acquainted with the software produced by the Charitable Temple of the Bristling Yak" |
| 16:06 | <&jerith> | And I was completely and utterly wrong. |
| 16:07 | | * jerith <3 thecodelesscode. |
| 16:07 | | Derakon[AFK2] is now known as Derakon |
| 16:11 | | celticminstrel [celticminst@Nightstar-gj43l1.dsl.bell.ca] has joined #code |
| 16:11 | | mode/#code [+o celticminstrel] by ChanServ |
| 16:30 | <@Azash> | Pretty sure the joke was the faulty logic |
| 16:31 | <@Azash> | Also concern of backdoors is warranted as that's some kind of third party peripheral for TOR access |
| 16:34 | <@Namegduf> | Tarinaky: This is why it does routing at the connection level, rather than the packet level, and prefers to reuse a circuit. |
| 16:34 | <@Namegduf> | Tarinaky: You can also configure a fixed route in your config file, and some people consider this safer. |
| 16:34 | <@Azash> | https://drupal.org/node/343414 |
| 16:35 | <@Tarinaky> | Namegduf: Makes sense. |
| 16:38 | < Xon> | <Azash> http://i.imgur.com/O0y3sUK.png |
| 16:38 | < Xon> | holy crap |
| 16:38 | <@Tarinaky> | Xon: What am I looking at? |
| 16:40 | < Xon> | bulging lead-acid batteries |
| 16:40 | < Xon> | the surface the APC sticker is on should be flat |
| 16:41 | < Xon> | basicly, it is a wonder there wasn't a fire or the batteries didn't start leaking |
| 16:41 | <@Tarinaky> | Err... that's not the battery bulging. |
| 16:41 | < Xon> | yes it is, you can see the plastic edges bulging up |
| 16:42 | < Xon> | the back-left one is really bad |
| 16:42 | <@Tarinaky> | I thought the plastic was seperate and slightly wider than the battery. |
| 16:42 | <@Tarinaky> | Hence, 'bulging'. |
| 16:43 | <@Tarinaky> | Or seperate and distorted by heat. |
| 16:43 | <@Tarinaky> | The black plastic underneath looks flat. |
| 16:44 | < Xon> | I've handled batteries just like that. the black plastic is a thin cover over the actual battery structure |
| 16:44 | < Xon> | no way in hell should there be /any/ buldging |
| 16:44 | < Xon> | bulging* |
| 16:44 | <@Tarinaky> | Okay. |
| 16:45 | < Xon> | http://www.youtube.com/watch?v=Vrqloduw-uY <- same battery |
| 16:46 | < Xon> | Azash, SMARTUPS 1500? http://torchwoodservices.com/2011/02/17/how-to-replace-the-batteries-on-an-apc-s martups-1500-rack-mount/ |
| 16:46 | < Xon> | (looks the same as your link) |
| 16:46 | <&ToxicFrog> | Hmm |
| 16:46 | <&ToxicFrog> | I think emufun needs a "reload" event |
| 16:55 | <@Azash> | Xon: Good call, might very well be it |
| 16:55 | <@Azash> | Xon: Any idea what this cable is? http://torchwoodservices.com/wp-content/uploads/2011/02/147.jpg |
| 16:55 | <@Azash> | I mean, sounds like you've encountered them before |
| 16:59 | <&jerith> | I thoroughly approve of Abbess Jinyu. |
| 17:31 | < Xon> | Azash, work server room had somethign similar and I've had low end APC lead acid batteries around in some personal UPSs. Read up on some of the failure modes =p |
| 17:34 | < Xon> | Azash, the cable coming out of that UPS looks like a custom cable to another battery pack. The red/black cable is from the battery pack. |
| 17:35 | < Xon> | hint; UPS extra battery packs may not be hot swapable =p |
| 17:37 | < Xon> | anyway, way to late in GMT+8. see ya |
| 17:38 | <@Azash> | Later |
| 17:38 | <@celticminstrel> | I seem to be failing at outputting a valid classfile. :/ |
| 17:41 | | ErikMesoy1 [Erik@Nightstar-ekm.o7n.203.80.IP] has joined #code |
| 17:42 | | ErikMesoy [Erik@Nightstar-ekm.o7n.203.80.IP] has quit [Ping timeout: 121 seconds] |
| 17:43 | | Turaiel[Offline] is now known as Turaiel |
| 17:55 | | Stalker [Z@Nightstar-484uip.cust.comxnet.dk] has joined #code |
| 18:01 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 18:13 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has joined #code |
| 18:13 | | mode/#code [+o himi] by ChanServ |
| 18:24 | | Vornicus [vorn@Nightstar-sn7kve.sd.cox.net] has joined #code |
| 18:24 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| 18:34 | <@Azash> | http://www.cs.helsinki.fi/u/oottela/TFC.pdf |
| 18:44 | | ErikMesoy1 is now known as ErikMesoy |
| 18:57 | | Turaiel is now known as Turaiel[Offline] |
| 19:33 | <@Tarinaky> | Eugh. University stresses me out so much, I don't know how I'm going to cope with a job :/ |
| 19:33 | <@Namegduf> | I found a job much less stressful myself. |
| 19:33 | <@Namegduf> | Better work/life balance. |
| 19:33 | <@Namegduf> | In that there is a work/life balance. |
| 19:40 | <@Tarinaky> | I'm going to be lucky to get out of this with a 2:2 :/ |
| 19:48 | | Kindamoody|afk is now known as Kindamoody |
| 20:11 | | Kindamoody is now known as Kindamoody[zZz] |
| 20:30 | <@celticminstrel> | Well, I managed to get a valid classfile, finally. |
| 20:30 | <@celticminstrel> | Unfortunately it doesn't work. |
| 20:33 | | Harlow [Harlow@Nightstar-2dbe3d64.il.comcast.net] has joined #code |
| 20:42 | <@celticminstrel> | Must be something wrong with my code generation... |
| 20:42 | | Reiv [NSwebIRC@Nightstar-95746c1f.kinect.net.nz] has joined #code |
| 20:42 | | mode/#code [+o Reiv] by ChanServ |
| 21:11 | | ErikMesoy is now known as ErikMesoy|sleep |
| 21:25 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has quit [Connection closed] |
| 21:35 | | AverageJoe [evil1@Nightstar-fb1kt4.ph.cox.net] has joined #code |
| 21:38 | | Derakon [chriswei@Nightstar-4k2ccr.ca.comcast.net] has quit [[NS] Quit: leaving] |
| 21:38 | | Derakon[AFK] is now known as Derakon |
| 21:57 | <&McMartin> | jerith: That's the (wrong~) UQM code style creeping in where it shouldn't |
| 21:59 | <&jerith> | McMartin: I suspected something of that sort. |
| 21:59 | <&jerith> | I just wanted to make sure it wasn't a particular style denoting something I'd missed. |
| 22:00 | <&jerith> | Also, I'd've finisehd updating pymonocle except I'm reading thecodelesscode which I'd somehow managed to miss all this time. |
| 22:01 | < simon> | when using web proxies for scalability in the number of simultaneous client connections, and these web proxies don't cache, then what could possibly go wrong? |
| 22:01 | < simon> | congestion? |
| 22:02 | <&jerith> | simon: I want to say http://thecodelesscode.com/case/96 is relevant, but it may not be. |
| 22:02 | <&jerith> | How do proxies give you scalability if they don't cache? |
| 22:04 | < simon> | jerith, I'm guessing it's because the root HTTP server has a limited number of file descriptors. |
| 22:04 | < simon> | jerith, or maybe the OS simply chokes from the overhead of creating new connections |
| 22:05 | < simon> | jerith, you overcome that by distributing the connections across a bunch of proxies that only do forwarding to some keep-alive connections..... *I think*! |
| 22:05 | <&jerith> | But the proxies are proxying all those connections anyway. I don't see how that buys anything usefil. |
| 22:05 | <&jerith> | *useful |
| 22:05 | < simon> | well, you can't ask all your incoming clients to pool up, but you can ask your proxies to be nice to the root HTTP server. |
| 22:05 | <&jerith> | It sounds fragile at best. |
| 22:06 | <&jerith> | And you're just trading one kind of bad behaviour for another. |
| 22:06 | < simon> | that you are. |
| 22:06 | <&jerith> | Rather fix the problem by running multiple webservers. |
| 22:06 | < simon> | but if your main server can't keep up with the number of connections made to it, but it isn't because of CPU or bandwidth bottlenecks, simply the number of connections, you would be able to solve it like that. |
| 22:06 | < simon> | well, this is really sort of doing that. |
| 22:07 | < simon> | but yeah, you could certainly also distribute more responsibility to these replicas. |
| 22:07 | <&jerith> | If the problem is that you can only handle N concurrent connections and you need to handle N+M, adding proxies doesn't help. |
| 22:08 | <&jerith> | You still need to handle N+M concurrent connections. |
| 22:09 | <&jerith> | Unless your proxies limit the number of connections /they/ make, in which case you're swapping the failures for latency. |
| 22:09 | <&jerith> | Or something. |
| 22:11 | < simon> | jerith, at one point you would be swapping your failures for latency, but what I'm thinking is this: your HTTP server may have the CPU and bandwidth capacity to handle all the requests, but it simply might not have enough available file descriptors at one point (which is really kind of a silly restriction I had the impression that is a limitation in the HTTP server's operating system). |
| 22:11 | <&McMartin> | I don't know much about middleware, but I'd gotten the impression that a number of web servers assign one thread per connection and that ones that fail to do this can handle significantly more. |
| 22:12 | <&jerith> | simon: CPU and bandwidth are irrelevant if you're limited by the number of file descriptors. |
| 22:12 | < simon> | McMartin, yeah. I've the impression that Apache's thread-pooling with a maximum number of threads is better, and nginx/lighttpd no-thread is even faster. |
| 22:13 | < simon> | jerith, yes, but I don't know if this is actually the limitation. I can't think of other reasons to employ "scaling" no-cache HTTP proxies. |
| 22:14 | < simon> | except maybe overhead from accepting connections, but compared to the bandwidth bottleneck of piping stuff through lightweight forwarding proxies seems somewhat unbelievable. |
| 22:14 | <&jerith> | I can't say for sure that it's a foolish idea, but I'd need some pretty compelling evidence to decide that it isn't. |
| 22:15 | <&jerith> | Now, if those proxies did load-balancing or something that's a different story. |
| 22:15 | < simon> | ah, distributing the load among several HTTP servers? |
| 22:15 | <&jerith> | Or if they terminated SSL connections and made unencrypted connections to the backend. |
| 22:15 | < simon> | certainly more plausible. |
| 22:17 | < simon> | thanks. :) |
| 22:18 | <&jerith> | The benefit of having a proxy do load balancing is that you can make it much cleverer about balancing load than the clients. |
| 22:18 | < simon> | client load balancing is handled through DNS RRs? |
| 22:19 | | * Vornicus fiddles with Vorntiers |
| 22:19 | <&jerith> | Or, as we do for some systems, the clients talk to a single proxy running on localhost (for each client machine) which then does load balancing. |
| 22:19 | <&jerith> | simon: RR DNS is a common way to do it. |
| 22:20 | < simon> | but yeah, proxies can deal with actual load and not just statistical likelinesses :) |
| 22:23 | < simon> | jerith, the reason you want to unwrap SSL before reaching your server is because the SSL encryption can be heavy for a large number of clients, right? |
| 22:23 | <&jerith> | simon: Yes, but also because you might not want your certs and stuff on all the backend machines. |
| 22:24 | <~Vornicus> | Okay. With the model being entirely saveable state, I need to find a home for view-side variables, that don't get saved because they're quite volatile. This includes stuff like indices into tables that contain sprites and so forth. |
| 22:24 | <&jerith> | Vornicus: Is there code we can look at? |
| 22:26 | <~Vornicus> | Not really; without a sense of where to put anything, I haven't been able to write code to match it. |
| 22:33 | <~Vornicus> | Right now, games load straight from a json file, and save the same way; I then add metatables (this is lua) to give them activity. But from here I have to figure out where to put the data that planets get that is entirely view-related. In particular, a planet renders itself by registering a sprite with a spritebatch, and that gives it an index. Later, if a planet's sprite changes (due to |
| 22:33 | <~Vornicus> | terraforming, for instance, or a catastrophe of some sort), it would use that index to modify its existing sprite info. |
| 22:39 | <@Tarinaky> | Shouldn't you be able to recalculate/infer the view-side variables from some model-state? |
| 22:40 | <~Vornicus> | Not the sprite registration IDs |
| 22:41 | <@Reiv> | That seems slightly convoluted. Why'd you choose to go that path? |
| 22:42 | <@Reiv> | It's not bad, just... nonintuitive, I suppose |
| 22:43 | | Stalker [Z@Nightstar-484uip.cust.comxnet.dk] has quit [Ping timeout: 121 seconds] |
| 22:44 | <@Tarinaky> | Vornicus: Maybe you should add some associated model-state that represents the same thing? |
| 22:45 | <@Tarinaky> | (From which you can infer the view-state) |
| 22:47 | | * Vornicus is unsure whether he's explained this properly, actually |
| 22:48 | <@Tarinaky> | Shouldn't you be starting with a new, empty, sprite batch and adding every planet to it on loading? |
| 22:48 | <@Tarinaky> | And having something in the model that says what type of planet it is. From which you can infer what sprite it was using. |
| 22:49 | <@Tarinaky> | (abusing the properties of pseudo-randomness if necessary) |
| 22:50 | | Turaiel[Offline] is now known as Turaiel |
| 22:51 | <~Vornicus> | Well, yeah, on loading, the sprite batch is empty and is then filled. But as I fill the sprite batch, the planets get back a registration ID -- the index in the sprite batch that it has attained. Note that this ID is not necessarily in the order of the planets in the savegame, particularly if the planets are originally concealed by fog of war and not visible until the player reveals them. |
| 22:52 | <~Vornicus> | (I don't control what registration ID each planet gets, in short) |
| 22:53 | <@Reiv> | (Could you?) |
| 22:54 | <@celticminstrel> | Hm, it seems to work now, yay. |
| 22:54 | <~Vornicus> | (not easily, no) |
| 22:54 | <@Reiv> | So where are your sprites coming from, files or procgen? |
| 22:56 | <~Vornicus> | The sprites come from a spritesheet, a single file with many planet images. The spritesheet loads into the spritebatch, and then to register a planet I tell it which sprite I wish to render, and where. |
| 22:58 | <@celticminstrel> | ...well mostly. |
| 22:58 | <@Reiv> | Do the sprites load from the spritesheet consistently? |
| 22:59 | <~Vornicus> | I'm not sure what you mean |
| 22:59 | <@Reiv> | Mostly I'm trying to figure whether there should be an issue with simply assigning a variable to the savestate of Sprite ID |
| 23:00 | <~Vornicus> | Oh. |
| 23:00 | <~Vornicus> | Location in the sprite sheet is not the same as sprite registration ID |
| 23:01 | <@Reiv> | I am wondering whether you cannot, uh, encourage it to do so more consistently. |
| 23:01 | <@Reiv> | Even if it demands that you thus register all sprites on loadup, fog of war be damned |
| 23:02 | <~Vornicus> | ...hm, possibly. I'm not sure I like it though |
| 23:03 | <@Reiv> | If you can force the SpriteID to load in a consistent manner, then you can match it better |
| 23:03 | <~Vornicus> | Certainly will not be the case with fleets though |
| 23:03 | <@Reiv> | Because what you need is a way to populate backwards with that info, one way or the other |
| 23:09 | | AverageJoe [evil1@Nightstar-fb1kt4.ph.cox.net] has quit [[NS] Quit: Leaving] |
| 23:17 | <~Vornicus> | Well, it'd also be nice to have view-specific data store somewhere anyway... actually... |
| 23:18 | <~Vornicus> | hm. There is another sprite batch here, and that one has a variable number of entities per planet. |
| 23:20 | <@celticminstrel> | This would be easier if VerifyError included the offset of the bad instruction. |
| 23:27 | <&ToxicFrog> | celticminstrel: are you writing a compiler that emits JVM bytecode or something? |
| 23:28 | <@celticminstrel> | Yeah. |
| 23:32 | | himi [fow035@Nightstar-q9amk4.ffp.csiro.au] has joined #code |
| 23:32 | | mode/#code [+o himi] by ChanServ |
| 23:33 | | * McMartin contemplates the teachings of the Temple of Three Stones. |
| 23:39 | | * jerith prepares the brass egg. |
| 23:41 | <&McMartin> | Oh good, you're still awake. |
| 23:41 | <&McMartin> | How does cffi handle callback data? Can you exclude stuff you pass in from garbage collection until you release it? |
| 23:42 | <&McMartin> | (Also note that the fable labled "Consequences" is the one I had in mind while I was working through the kind/trait design) |
| 23:43 | | RichyB [RichyB@Nightstar-c6u.vd5.170.83.IP] has quit [Ping timeout: 121 seconds] |
| 23:45 | < jeroud> | McMartin: Any memory allocated by cffi is only freed when the underlying object it's allocated to goes out of scope. |
| 23:46 | <&McMartin> | Right, so |
| 23:46 | <&McMartin> | Let's say I extend MNCL_OBJECT * with a void *, because what the Hell, 8 bytes per object |
| 23:46 | <&McMartin> | Can cffi bind to that so that the Python runtime doesn't cheerfully destroy the object after it vanishes into Monocle's guts? |
| 23:47 | <&McMartin> | (That is, if the object constructor now takes an object full of ancillary data) |
| 23:47 | <&McMartin> | In other other words, can I make it go "out of scope" with respect to the python program in the understanding that it may be handed back to me by the library later, because it's been pinned by the FFI mechanism? |
| 23:48 | <&McMartin> | (You can tell I don't have the vocabulary for this because I'm using different phrasings every time) |
| 23:48 | < jeroud> | I can shove a pointer to a Python object in there and hang onto a reference to it. |
| 23:48 | <&McMartin> | Mmmm. |
| 23:49 | <&McMartin> | And then break that reference when the object is destroyed |
| 23:50 | | RichyB [RichyB@Nightstar-c6u.vd5.170.83.IP] has joined #code |
| 23:50 | <&McMartin> | That'd save you one dictionary lookup per event, which is probably significant |
| 23:50 | <&McMartin> | (or set lookup, which is about the same) |
| 23:52 | < jeroud> | In this case, I'd either stick both the MNCL_OBJECT* and my userdata in my MonocleObject instance or shove the MonocleObject into the MNCL_OBJECT* as the userdata. Or something. |
| 23:53 | <&McMartin> | The latter is what I was hoping to enable. |
| 23:53 | <&McMartin> | But it's not clear to me if Python gains anything from this. |
| 23:57 | < jeroud> | I don't think Python really does, except that it might make it easier to get at MonocleObjects in places where it might be less than convenient to get at a mapping. |
| 23:57 | < jeroud> | The mapping from MNCL_OBJECT id to MonocleObject, that is. |
| 23:58 | <&McMartin> | I was kind of figuring that if one could swing it, the MNCL_OBJECT ids might never escape the pymonocle module. |
| 23:58 | < jeroud> | Like the bowels of the event subsystem wrapper or whatever. |
| --- Log closed Mon Dec 02 00:00:08 2013 |