| --- Log opened Thu Apr 02 00:00:13 2009 |
| 00:00 | <@gnolam> | Now with textured hands as well: http://www.cyd.liu.se/~torha229/RadiaX/rad_dorm0001.jpg |
| 00:00 | <@Derakon> | Are you doing the model yourself? |
| 00:01 | <@MyCatVerbs> | gnolam: now I'm going to panic about antlions bursting through the windows every time I pick up a Geiger counter :D |
| 00:02 | <@gnolam> | Derakon: Nah. We've appointed a modeling serf for that. |
| 00:02 | <@gnolam> | MyCatVerbs: Hah. I'm more worried about radscorpions, actually. |
| 00:04 | <@gnolam> | And we're seriously trying to work in headcrabs somehow. |
| 00:05 | | AnnoDomini [~farkoff@Nightstar-28858.neoplus.adsl.tpnet.pl] has quit [Quit: There's a fine line between "twinkling with mirth" and "burning with satanic rage."] |
| 00:07 | | Laura110 [~Mesias7.4@87.235.128.ns-4188] has joined #code |
| 00:08 | | Laura110 [~Mesias7.4@87.235.128.ns-4188] has quit [Client exited] |
| 00:17 | | Orthia [~Orthianz@Nightstar-22968.xdsl.xnet.co.nz] has joined #Code |
| 00:51 | <@Reiver> | Enraged local wildlife. |
| 00:52 | <@MyCatVerbs> | Grey Mesa, Black Mesa's little inner-city cousin. |
| 01:05 | <@gnolam> | I hear South Africa used to have two of those facilities. One Black Mesa and one White Mesa... |
| 01:06 | | * gnolam hides. |
| 01:11 | <@Vornicus> | >_< |
| 01:26 | | * Derakon makes player sprites and just shoves one into the final output. http://derakon.dyndns.org/~chriswei/games/jbrl/player1.png |
| 01:27 | <@Derakon> | I may need to brighten that up a bit, but it's more or less to-scale. |
| 01:30 | <@Vornicus> | Waaay too dark. |
| 01:38 | <@McMartin> | There's a style mismatch, it feel slike. |
| 01:40 | <@Derakon> | http://derakon.dyndns.org/~chriswei/games/jbrl/player1b.png |
| 01:40 | <@Derakon> | Brightened it up a bit. |
| 01:40 | <@Derakon> | As for style mismatches, well, bright and shiny armor in a dirt and grass area is a mismatch. |
| 01:48 | <@gnolam> | I'm getting a bit of a "Shadow of the Beast" feeling here. |
| 01:48 | <@Derakon> | I'm missing a reference here... |
| 02:47 | | Alek [~omegaboot@Nightstar-24672.dsl.emhril.sbcglobal.net] has quit [Ping Timeout] |
| 02:49 | <@gnolam> | Classic Amiga game. |
| 02:49 | <@gnolam> | Something in that shot just reminds me of it. |
| 02:51 | | Consul [~consul@Nightstar-634.dsl.sfldmi.ameritech.net] has quit [Ping Timeout] |
| 02:55 | | Alek [~omegaboot@Nightstar-317.dsl.emhril.sbcglobal.net] has joined #code |
| 02:56 | | Consul [~consul@Nightstar-634.dsl.sfldmi.ameritech.net] has joined #code |
| 02:56 | | mode/#code [+o Consul] by ChanServ |
| 03:03 | | gnolam [lenin@Nightstar-1382.A163.priv.bahnhof.se] has quit [Quit: Z?] |
| 03:11 | | * Derakon figures out why his player was paralyzed. |
| 03:11 | <@Derakon> | I was forgetting to call the update function. >.> |
| 03:13 | | Reiv [82d94c4d@Nightstar-15286.mibbit.com] has joined #Code |
| 03:15 | < Reiv> | Yeuch, this client is notsogood. Plan B it is. |
| 03:15 | | Reiv [82d94c4d@Nightstar-15286.mibbit.com] has quit [Quit: http://www.mibbit.com ajax IRC Client] |
| 03:21 | | Reiv [~82d94c4d@Nightstar-29731.dsl.in-addr.zen.co.uk] has joined #Code |
| 03:30 | | * Derakon ponders how to handle collision detection for the player. |
| 03:31 | <@Derakon> | I could associate a rectangle with each set of animations...I'm certainly not going to have different hitboxes for each frame, though. |
| 03:50 | | Reiv [~82d94c4d@Nightstar-29731.dsl.in-addr.zen.co.uk] has quit [Quit: CGI:IRC (EOF)] |
| 04:35 | <@ToxicFrog> | Ok, this is a cool bug in my compiler. |
| 04:36 | <@ToxicFrog> | Callconv is that function return values are in r0. |
| 04:36 | <@ToxicFrog> | However, after the call, it doesn't copy the value somewhere safe. |
| 04:36 | <@ToxicFrog> | So if you have an expression like: |
| 04:36 | <@ToxicFrog> | x = foo() + bar(); |
| 04:36 | <@ToxicFrog> | It generates code to call foo, and then records that the LHS is in r0. |
| 04:36 | <@ToxicFrog> | Then it generates code to call bar, and records that the RHS is in r0. |
| 04:36 | <@ToxicFrog> | Then it does x <- r0+r0 |
| 04:45 | <@ToxicFrog> | Fixed! |
| 04:45 | <@ToxicFrog> | And recursion is go |
| 05:05 | | ToxicFrog [~ToxicFrog@Admin.Nightstar.Net] has quit [Ping Timeout] |
| 05:16 | <@Derakon> | ...oh, wait, doing this properly requires bounding box collision detection. |
| 05:16 | <@Derakon> | And I'm in no shape to be implementing that just now. So it'll have to wait for tomorrow. |
| 05:17 | <@Derakon> | s/box/polygon/ |
| 05:25 | | ToxicFrog [~ToxicFrog@Admin.Nightstar.Net] has joined #code |
| 05:25 | | mode/#code [+o ToxicFrog] by ChanServ |
| 05:26 | <@ToxicFrog> | Ok. |
| 05:26 | <@ToxicFrog> | Everything is done now except arrays, which are giving me some trouble. |
| 05:35 | <@Derakon> | Format for mapping sprites to bounding polygons: spriteName:p1x,p1y:p2x,p2y:p3x,p3y:etc. |
| 05:35 | <@Derakon> | Seem reasonable? |
| 05:35 | <@Vornicus> | Sounds good. |
| 05:35 | <@Vornicus> | TF: what kind of trouble? |
| 05:36 | <@Derakon> | They keep slipping off-harness and bucking his assembler. |
| 05:37 | <@ToxicFrog> | Vornicus: for globals they're easy; address of element == base + index |
| 05:38 | <@ToxicFrog> | Similarly for locals; base is FP-relative, but that just changes one field in the opcode (use r5 rather than r0 as the basis register) |
| 05:38 | <@ToxicFrog> | However, for arguments, they're passed by pointer rather than by copy. |
| 05:39 | <@ToxicFrog> | So I need to either distinguish between "arrays which are arguments" and "arrays which aren't", or store all arrays as pointers. |
| 05:39 | <@Derakon> | And I take it you'd rather not do the latter? |
| 05:40 | <@ToxicFrog> | Yeah, because then I need to change the local/global layout code so each array is actually a pointer to a seperately allocated block of memory and it's just a mess |
| 05:40 | <@ToxicFrog> | However, it's not like distinguishing between arguments and everything else is less of a mess |
| 05:40 | <@ToxicFrog> | Although it will generate faster runtime code |
| 05:41 | <@Vornicus> | I always wondered how gcc and the like did that. |
| 05:46 | <@Derakon> | I'm glad I checked Pygame's drawing functions before I wrote this function... |
| 05:46 | <@Vornicus> | It already exists? |
| 05:46 | <@Derakon> | Turns out there's already a method for drawing a polygon given a set of points. |
| 05:55 | <@Derakon> | Okay, loading and display of polygons is done...tomorrow I can tackle colliding them. http://derakon.dyndns.org/~chriswei/games/jbrl/player/player2.png |
| 05:58 | <@Vornicus> | I recommend going over the Metanet tutorials, they're very good. |
| 05:58 | <@Derakon> | I have them open right now, as it happens. |
| 05:58 | <@Derakon> | They're what I used back when I was working on Niobium. |
| 05:59 | <@Derakon> | It'll be interesting to see how much easier they are to implement when I'm a) not trying to implement concave polygon collision detection, and b) much more clueful about programming in general. |
| 06:01 | <@Vornicus> | Even most advanced physics systems don't bother with concave detection. |
| 06:01 | <@Derakon> | Yeah. |
| 06:01 | <@McMartin> | Any reason why "collection of hitboxes" won't be good enough? |
| 06:01 | <@Derakon> | Generally once you start getting complex shapes like that, you also start building your creatures/mechs/whatever out of multiple components that can each get its own polygon. |
| 06:01 | <@Derakon> | McM: Niobium basically tried to automate making the collection of polygons. |
| 06:02 | <@Derakon> | (I can't use hitboxes for JBRL because of sloped terrain) |
| 06:02 | <@McMartin> | (OBBs?) |
| 06:02 | <@Derakon> | (Only work if you can guarantee that any sloped block has non-sloped blocks on its back sides to handle the overlap) |
| 06:03 | <@Derakon> | (I'm pretty certain I have that, but then again I also want you to be able to make arbitrary maps using a map editor without having the physics go all wonky) |
| 06:03 | | Syloqs-AFH [Syloq@Admin.Nightstar.Net] has quit [Connection reset by peer] |
| 06:15 | <@Derakon> | Hrmph...I suppose I could probably get away with combining OBBs and AABBs (i.e. all of the overlap from the OBB falls outside the AABB), but that sounds like it's getting kinda complicated. |
| 06:21 | <@Derakon> | Hrmph. Did some refactoring and my new file can't use constants.py properly. |
| 06:22 | <@Derakon> | Same code as was working in a different file, but doing "constants.imagePath" gets me the error "AttributeError: 'module' object has no attribute 'imagePath'". |
| 06:22 | <@Derakon> | And yes, I'm doing "import constants" |
| 06:23 | <@Vornicus> | Very strange. |
| 06:24 | <@Vornicus> | Before you get to that line, fire off a constants.__dict__ |
| 06:24 | <@Vornicus> | print it that is |
| 06:24 | <@Derakon> | Right. |
| 06:25 | <@Derakon> | ...okay, that's good to know. |
| 06:25 | <@Vornicus> | The results should look an awful lot like the actual module. If not, then there's something wrong. |
| 06:25 | <@Vornicus> | ?? |
| 06:25 | <@Derakon> | "from pygame import *" apparently takes over the "constants" name. |
| 06:25 | <@Vornicus> | This is why you don't use from foo import * |
| 06:26 | <@Derakon> | Yeah. |
| 06:26 | <@Derakon> | Okay, back in action. |
| 06:27 | <@Derakon> | The main reason to do it is to avoid dealing with things like "pygame.K_a", "pygame.KEYDOWN", etc. |
| 06:27 | <@Derakon> | But I don't need that outside of constants.py itself (where I map such concepts to more semantic stuff). |
| 06:32 | | * McMartin prepares to leave the office. |
| 06:32 | <@Derakon> | Your job is insane, McM. |
| 06:44 | <@ToxicFrog> | ben@leela:~/cminus$ tm-simulator/tm gcd.asm |
| 06:44 | <@ToxicFrog> | TM simulation (enter h for help)... |
| 06:44 | <@ToxicFrog> | Enter command: g |
| 06:44 | <@ToxicFrog> | Enter value for IN instruction: 36 |
| 06:44 | <@ToxicFrog> | Enter value for IN instruction: 15 |
| 06:44 | <@ToxicFrog> | OUT instruction prints: 3 |
| 06:44 | <@ToxicFrog> | HALT: 0,0,0 |
| 06:44 | <@ToxicFrog> | w00t |
| 06:44 | | * Derakon smiles and nods. |
| 06:44 | <@ToxicFrog> | GCD via euclid's algorithm. |
| 06:44 | <@Derakon> | Ah. |
| 06:44 | <@Vornicus> | YEY |
| 06:44 | <@ToxicFrog> | Written in C- and compiled into TM assembler via my compiler, then executed on a TM emulator. |
| 06:45 | <@ToxicFrog> | I've also done fibbonachi. |
| 06:45 | <@ToxicFrog> | (with added while loop goodness!) |
| 06:46 | <@Derakon> | That's the most inventive spelling of Fibonacci I've seen in a while~ |
| 06:46 | <@Derakon> | Sounds...Japanese. |
| 06:47 | <@ToxicFrog> | It's 2am, give me a break~ |
| 06:47 | <@Derakon> | Heh. |
| 06:47 | <@Vornicus> | I'm actually surprised that pygame doesn't have a keys namespace for its key values. |
| 06:47 | <@Derakon> | Vorn: I suppose I could do "from pygame.key import *" |
| 06:48 | <@Vornicus> | oh it does? |
| 06:48 | <@Vornicus> | ok |
| 06:48 | <@ToxicFrog> | I also have a selection sort implementation here, but I need array support to actually compile it~ |
| 06:48 | <@ToxicFrog> | (as it stands, passing an array to a function basically means that the function treats its stack as the array, with hilarious and tragic results) |
| 06:51 | <@Derakon> | Hee. |
| 06:51 | <@Derakon> | When's this due? |
| 06:54 | <@ToxicFrog> | Friday afternoon. |
| 06:54 | <@ToxicFrog> | All that's left is array support and documentation+testing. |
| 06:54 | <@ToxicFrog> | And I'm gradually constructing a test suite for it. |
| 06:55 | <@ToxicFrog> | Including every single construct that has broken previous versions of it, and various flavours of outright illegal code. |
| 06:55 | <@ToxicFrog> | (I've managed to find one input that causes it to assert after reporting the syntax errors, which I still can't track down >.<) |
| 06:57 | <@ToxicFrog> | Ok, first cut at array support. |
| 06:58 | <@ToxicFrog> | At the moment allocated symbols have two pieces of information associated - address and fp_relative |
| 06:58 | <@ToxicFrog> | The latter is true if the address is relative to the frame pointer rather than to the bottom of data memory. |
| 06:59 | <@McMartin> | Yay home. |
| 06:59 | <@McMartin> | Totally not showing up to work tomorrow until 11. =P |
| 06:59 | <@ToxicFrog> | ...wait, shit |
| 06:59 | <@Vornicus> | A principled stand~ |
| 06:59 | <@ToxicFrog> | Code like: |
| 06:59 | <@ToxicFrog> | int x[4]; |
| 06:59 | <@ToxicFrog> | int y[8]; |
| 06:59 | <@ToxicFrog> | x = y; |
| 06:59 | <@ToxicFrog> | is lega |
| 07:00 | <@ToxicFrog> | *legal (x and y now point to the same array, and the old x is inaccessible) |
| 07:00 | <@ToxicFrog> | So all arrays have to be stored as pointers >.< |
| 07:00 | <@McMartin> | I am totally cool with that causing nasal demons. |
| 07:00 | <@McMartin> | Especially since char *x and char x[] are not the same thing at global scope hooray :wrists: |
| 07:01 | <@Vornicus> | nasal demons? |
| 07:01 | <@ToxicFrog> | Oh, hang on |
| 07:01 | <@ToxicFrog> | The spec says "a var is either a simple (int0 |
| 07:01 | <@ToxicFrog> | The spec says "a var is either a simple (int) variable, or a subscripted array" |
| 07:02 | <@McMartin> | Vornicus: It's a standin for "undefined behavior from the compiler" |
| 07:02 | <@ToxicFrog> | So the fact that my compiler accepts the code I gave above is in fact a bug in the validator~ |
| 07:02 | <@Vornicus> | Okay. |
| 07:02 | <@Vornicus> | But... nasal demons? |
| 07:02 | <@ToxicFrog> | (C- doesn't have pointer types, and it's undefined how arrays are stored internally) |
| 07:02 | <@McMartin> | From a comment on the C standardization minutes along the lines of "if you do this, a compiler could make demons fly out your nose and still be standards-compliant" |
| 07:02 | <@McMartin> | Cue followup comment shorthanding to nasal demons and a new term of art is born! |
| 07:03 | <@McMartin> | Aha, here we go. It was Usenet, though. http://www.catb.org/~esr/jargon/html/N/nasal-demons.html |
| 07:04 | <@ToxicFrog> | So. Back to array support: new piece of information, indirect. This is true for arguments of array type (but not for globals, which are allocated at the bottom of memory at program startup, or non-argument locals, which are allocated on the stack in their entirety) |
| 07:04 | <@ToxicFrog> | This changes variable address calculation thusly: for something that's not fp_relative, it's address+r0; for something that is fp_relative but not indirect, it's address+r5. |
| 07:05 | <@ToxicFrog> | For something that's indirect, it's address+r5 and then ld the result. |
| 07:09 | <@ToxicFrog> | Sanity? |
| 07:11 | | * Vornicus is lost, really. |
| 07:11 | <@McMartin> | The latter is basically exactly the 6502's (ZP), Y addr mode. |
| 07:13 | <@ToxicFrog> | Hmm. It occurs to me that this also changes the generated code for variable access. |
| 07:13 | <@ToxicFrog> | For direct access, it can emit constants; for indirect, it has to use a register and then ld/st 0(r) |
| 07:19 | <@McMartin> | You can use n(r) when n is a constant too, right? |
| 07:19 | <@ToxicFrog> | n is always a constant. |
| 07:20 | <@McMartin> | x[i] is illegal C-? |
| 07:20 | <@ToxicFrog> | There are two instruction formats: OP reg,reg,reg and OP reg,const(reg); in both cases the first reg is a destination register. |
| 07:20 | <@McMartin> | Yeah, that wasn't my question. |
| 07:20 | <@ToxicFrog> | It's legal, it just needs a bit more hoop-jumping. |
| 07:21 | <@ToxicFrog> | Load x's baseaddress into a register r; load i into another register s; add r,r,s; now r contains the address of that array element. |
| 07:22 | <@McMartin> | Right. |
| 07:22 | <@McMartin> | That's how you're compiling "indirect" |
| 07:23 | <@McMartin> | What I meant was, in addition to (ZP), Y, 6502 also has addr, Y in which you just add the index register to the address and read the memory at the sum |
| 07:23 | <@McMartin> | Instead of treating the sum as the location of a pointer to dereference, which is what "indirect" would be |
| 07:24 | <@ToxicFrog> | Aah. Yes. |
| 07:25 | <@ToxicFrog> | In that case the instruction you use is ld/st r,const(s) where const is the baseaddress and s is the index register. |
| 07:25 | <@McMartin> | Ee-yep. |
| 07:25 | <@ToxicFrog> | And that's how direct array usage is currently being compiled. |
| 07:25 | <@McMartin> | Good times. |
| 07:26 | <@ToxicFrog> | (and direct non-array usage, for that matter, using r0 as the index register - it's always 0 except in certain specific (and non-overlapping) circumstances) |
| 07:26 | <@McMartin> | This assembler feels very ARMy. |
| 07:26 | <@ToxicFrog> | Never used ARM, I'm afraid. |
| 07:27 | | AnnoDomini [~farkoff@Nightstar-28858.neoplus.adsl.tpnet.pl] has joined #Code |
| 07:27 | | mode/#code [+o AnnoDomini] by ChanServ |
| 07:28 | <@McMartin> | I've only read it when disassembling GBA startup code. |
| 07:28 | | Derakon is now known as Derakon[AFK] |
| 07:32 | <@ToxicFrog> | It's a very simple processor, which is nice, but it also means I need to do a lot of stuff by hand - in particular there is no stack and no CALL/RETURN. |
| 07:33 | <@McMartin> | That's pretty standard for RISC architectures, and tracks ARM (I think) and MIPS (definitely). |
| 07:33 | <@McMartin> | I'm guessing you use Jump-and-Link for CALL and Jump-Register for RETURN? |
| 07:35 | | Orthia [~Orthianz@Nightstar-22968.xdsl.xnet.co.nz] has quit [Connection reset by peer] |
| 07:35 | <@ToxicFrog> | I'm not familiar with either of those terms, or at least I don't recall them at this time of night. |
| 07:35 | <@McMartin> | JAL and JR are the MIPS mnemonics |
| 07:36 | <@McMartin> | All MIPS instructions are 4 bytes wide. |
| 07:36 | <@ToxicFrog> | The calling convention I'm using is that r6 and r5 are sp and fp respectively; caller pushes arguments, then ip, then jumps to callee |
| 07:36 | <@McMartin> | OK, so, no JAL. |
| 07:36 | <@ToxicFrog> | Callee pushes fp and then sets fp == sp. |
| 07:36 | | * Vornicus is reminded that he wanted to write DisARM |
| 07:36 | <@McMartin> | JAL addr puts IP+4 (all instructions are four bytes wide) into r31 and jumps to addr. |
| 07:37 | <@ToxicFrog> | Return convention puts the RV in r0, then releases the stack frame by resetting sp to fp, popping fp and then popping ip. |
| 07:37 | <@McMartin> | JR r copies r to IP. |
| 07:37 | <@ToxicFrog> | Yeah, doesn't have either. |
| 07:37 | <@ToxicFrog> | JR equivalent is LDA ip,0(r) |
| 07:38 | <@McMartin> | That means it does have it~ |
| 07:38 | <@McMartin> | Just only as a pseudo-instruction. |
| 07:38 | <@McMartin> | (Similarly, MIPS doesn't technically have MOV; it instead has ADDI d, s, 0) |
| 07:38 | <@ToxicFrog> | JAL is LDA r,4(ip); LDA ip,addr(0) # assuming r0 contains zero |
| 07:39 | <@ToxicFrog> | Er, actually, that latter should be LDC ip,addr(_) |
| 07:40 | <@ToxicFrog> | (and that 4 is actually 1, because addresses are in memory cells, not bytes, and one instruction fits in one memory cell exactly) |
| 07:40 | <@ToxicFrog> | Hmm. |
| 07:41 | <@ToxicFrog> | AIUI the way JAL is used is that when you call, you get the old ip in a register; if you then want to make another call, you push that register and restore it afterwards? |
| 07:41 | <@McMartin> | Yeah. |
| 07:41 | <@McMartin> | MIPS's only memory access format is basically LD d, r1(r2) |
| 07:41 | <@ToxicFrog> | ...that might actually simplify matters for me. |
| 07:41 | <@McMartin> | Though MIPS also has no stack |
| 07:42 | <@McMartin> | Er. sorry. MIPS's LD is exactly like your target machine's. |
| 07:42 | <@ToxicFrog> | Use r0 as the saved IP register; then I can return by releasing the entire stack frame (including arguments), pushing the RV and copying r0 into ip. |
| 07:42 | <@McMartin> | But that means locals are, say, -4(SP). |
| 07:42 | | Orthia [~Orthianz@Nightstar-22968.xdsl.xnet.co.nz] has joined #Code |
| 07:43 | <@ToxicFrog> | More generally, add r0 to the general-purpose register pool, but each function begins with r0 marked in use; it'll automatically be stacked when a function is called or that register is needed for other temporaries. |
| 07:44 | <@ToxicFrog> | Yeah. Here locals are relative to FP, because keeping track of the shifting relative offsets as SP moves around is a pain. |
| 07:44 | <@ToxicFrog> | (although the generated machine code would be faster) |
| 07:44 | <@ToxicFrog> | (since I could ditch FP entirely and have another register to use before I have to hit stack) |
| 07:46 | <@ToxicFrog> | The stack layout is currently: [arguments][old ip][old fp][locals][temporaries] |
| 07:46 | <@ToxicFrog> | With fp pointing to the start of [locals] and sp to the cell after the end of [temporaries] |
| 08:38 | | Vornicus [Vornicus@Admin.Nightstar.Net] has quit [Quit: ] |
| 09:36 | | Orthia [~Orthianz@Nightstar-22968.xdsl.xnet.co.nz] has quit [Ping Timeout] |
| 09:44 | | Rhamphoryncus [~rhamph@Nightstar-7184.ed.shawcable.net] has quit [Quit: Rhamphoryncus] |
| 10:26 | | somnolence [~somnolenc@203.160.1.ns-3171] has quit [Ping Timeout] |
| 10:59 | | Orthia [~Orthianz@Nightstar-20794.xdsl.xnet.co.nz] has joined #Code |
| 12:24 | | Tarinaky [~Tarinaky@Nightstar-16638.plus.com] has joined #code |
| 14:10 | | gnolam [lenin@Nightstar-1382.A163.priv.bahnhof.se] has joined #Code |
| 14:10 | | mode/#code [+o gnolam] by ChanServ |
| 14:36 | | Orthia [~Orthianz@Nightstar-20794.xdsl.xnet.co.nz] has quit [Ping Timeout] |
| 15:38 | | Tarinaky [~Tarinaky@Nightstar-16638.plus.com] has quit [Client exited] |
| 16:03 | | Syloqs_AFH [Syloq@Admin.Nightstar.Net] has joined #code |
| 16:05 | | Syloqs_AFH is now known as Syloqs-AFH |
| 16:16 | | KBot [~karma.bot@Nightstar-29147.neoplus.adsl.tpnet.pl] has joined #Code |
| 16:16 | | AnnoDomini [~farkoff@Nightstar-28858.neoplus.adsl.tpnet.pl] has quit [Ping Timeout] |
| 16:17 | | KarmaBot [AnnoDomini@Nightstar-28858.neoplus.adsl.tpnet.pl] has quit [Ping Timeout] |
| 16:19 | | KBot is now known as KarmaBot |
| 16:23 | | Tarinaky [~Tarinaky@Nightstar-16638.plus.com] has joined #code |
| 16:23 | | AnnoDomini [~farkoff@Nightstar-29147.neoplus.adsl.tpnet.pl] has joined #Code |
| 16:23 | | mode/#code [+o AnnoDomini] by ChanServ |
| 16:45 | | Derakon[AFK] is now known as Derakon |
| 17:04 | | ToxicFrog [~ToxicFrog@Admin.Nightstar.Net] has quit [Ping Timeout] |
| 17:20 | | ToxicFrog [~ToxicFrog@67.204.58.ns-13619] has joined #code |
| 17:20 | | mode/#code [+o ToxicFrog] by ChanServ |
| 17:50 | | * Derakon facepalms. |
| 17:50 | <@Derakon> | This is not helpful. http://doc.spatial.com/r19/index.php/HowTo:Project_a_point_onto_a_line%3F |
| 17:51 | <@Derakon> | I suppose it would be helpful if I were using their tools, mind. |
| 18:34 | | Rhamphoryncus [~rhamph@Nightstar-7184.ed.shawcable.net] has joined #code |
| 19:07 | | * Derakon eyes this code snippet. |
| 19:07 | <@Derakon> | auto s = [&pos,l] (int a,int b) { return a + (b-a)*pos/l; }; |
| 19:07 | <@Derakon> | This is C/C++, mind you. :( |
| 19:21 | <@ToxicFrog> | ...I can't read that at all. |
| 19:21 | <@McMartin> | It's got some extensions in it, I think, which are non-standard. |
| 19:22 | <@McMartin> | I bet the [&pos,l] is some kind of compiler specific way of saying "these vars are at these memory locations" |
| 19:22 | <@Derakon> | Yeah, he says it's "C++0x". |
| 19:22 | <@Derakon> | Here's the thread in question: http://tasvideos.org/forum/viewtopic.php?p=195752 |
| 19:23 | <@McMartin> | That means it's standard-but-not-yet. |
| 19:23 | <@McMartin> | OH |
| 19:24 | <@McMartin> | That's the new lambda syntax, then. |
| 19:24 | <@McMartin> | I think they're reusing "auto" for something, too, but I don't know what |
| 19:24 | <@Derakon> | You can see why I found the thread interesting, anyway. :) |
| 19:30 | <@gnolam> | Oh, don't get me started on C++'s "Oh, but inventing new symbols and keywords would break some existing, easily-fixed programs. So let's completely change the meaning of standard ones!" mentality. |
| 19:31 | <@McMartin> | You forgot the more awesome "Never use overloading to change the meaning of standard operators the way we do ourselves in the library" |
| 20:17 | <@ToxicFrog> | At least it doesn't actually enforce that. |
| 20:17 | <@ToxicFrog> | Unlike Java, which overloads standard operators and then doesn't let you do the same. |
| 20:25 | <@Derakon> | :.,+9g/print/s/^/# |
| 20:25 | <@Derakon> | I love vim. |
| 20:27 | <@ToxicFrog> | ;.; |
| 20:27 | <@Derakon> | "For this and the next nine lines, do the following: if a line matches the string 'print', replace the beginning of the line with '#'" |
| 20:30 | <@Derakon> | What's the Python function I need to implement for "print myClassInstance" to do something useful? |
| 20:31 | <@Derakon> | Oh, found it. __str__ |
| 22:03 | | * Derakon tries to remember how to handle collision with multiple blocks in the same frame. |
| 22:04 | <@Derakon> | For example, the player is straddling two blocks. I know the required displacement to eject the player from each block, but I shouldn't apply both displacements because that'd move the player too far. |
| 22:04 | <@Derakon> | On the flipside, I don't want a "while player is colliding with terrain, move player out of terrain" approach either. |
| 22:06 | <@gnolam> | Why not? That approach is pretty much standard... |
| 22:07 | <@Derakon> | I'm slightly worried about the potential for infinite loops. |
| 22:30 | <@ToxicFrog> | Fuck mod_python in hell, forever |
| 22:31 | <@Derakon> | Hm. Well, on the one hand, this is progress...on the other hand, it still clearly needs a lot of work. http://derakon.dyndns.org/~chriswei/games/jbrl/collision/player4.gif |
| 22:45 | <@PinkFreud> | ToxicFrog: we're using it here. what's your problem with itt? |
| 22:46 | <@ToxicFrog> | PinkFreud: caches everything. |
| 22:46 | <@ToxicFrog> | Documentation claims it will automatically reload changed modules. This is a vicious and blatant lie. |
| 22:46 | <@ToxicFrog> | As we speak it is executing scripts that no longer exist and using settings that I changed hours ago. |
| 22:47 | <@PinkFreud> | you sure you don't have compiled versions of those scripts lying around? |
| 22:52 | <@ToxicFrog> | Yep. |
| 22:52 | | gnolam [lenin@Nightstar-1382.A163.priv.bahnhof.se] has quit [Quit: Z?] |
| 22:52 | <@PinkFreud> | hmm |
| 22:53 | <@PinkFreud> | I can ask our devs about it tomorrow |
| 23:35 | <@Derakon> | :.,.+19g/#/s/=//g |
| 23:42 | | * Derakon ponders this situation: http://derakon.dyndns.org/~chriswei/games/jbrl/collision/player5.png |
| 23:43 | <@Derakon> | Specifically, the fact that the block that's entirely interior to the terrain is determining where the player goes. |
| 23:43 | <@AnnoDomini> | The player has left the building! |
| 23:43 | <@Derakon> | Should such interior blocks be ineligible for collision detection? |
| 23:44 | | AnnoDomini [~farkoff@Nightstar-29147.neoplus.adsl.tpnet.pl] has quit [Quit: Reading is tech.] |
| 23:45 | <@Derakon> | Should such interior blocks be ineligible for collision detection? |
| 23:46 | <@Derakon> | Keeping in mind that mazes allow for a block with 7 adjacent blocks to still be accessible. |
| 23:48 | | Tarinaky [~Tarinaky@Nightstar-16638.plus.com] has quit [Quit: Leaving] |
| --- Log closed Fri Apr 03 00:00:25 2009 |