| --- Log opened Wed Jun 10 00:00:33 2009 |
| 00:00 | <@Consul> | I can't remember any of my mnemonics anymore. LDA is "load accumulator", STA I remember using a lot, JSR is "jump to subroutine"... |
| 00:01 | | * gnolam pokes Consul in the 53280. |
| 00:01 | | UndeadAnno [AnnoDomini@Nightstar-29141.neoplus.adsl.tpnet.pl] has quit [Quit: "General! Strike me down, then have every last man, woman and child put to the sword. There's no point going on anymore, not now that it's all gone..." "At once, sire."] |
| 00:01 | <@gnolam> | Consul: STA = STore Accumulator. |
| 00:01 | | * Consul 's screen border changes color |
| 00:02 | <@Consul> | Okay, so LDA loaded the accumulator with a value, STA stored the value in the accumulator elsewhere? |
| 00:02 | <@gnolam> | Yup. |
| 00:02 | <@Consul> | Ah, okay. |
| 00:02 | | jess_ [~jess@Nightstar-6870.dsl.teksavvy.com] has joined #code |
| 00:02 | <@gnolam> | But 6502 is still evil. |
| 00:02 | | * gnolam hugs the 68k. |
| 00:02 | | SmithKurosaki [~Jenn@Nightstar-7213.cpe.net.cable.rogers.com] has quit [Ping Timeout] |
| 00:02 | <@McMartin> | $D020 hex = 53280 decimal |
| 00:03 | <@McMartin> | That was "turn the screen black and clear it" |
| 00:03 | | jess_ is now known as SmithKurosaki |
| 00:03 | | S_Kurosaki [~Jenn@Nightstar-7213.cpe.net.cable.rogers.com] has joined #code |
| 00:08 | <@Consul> | I used to have a routine that would copy the kernel memory to its underlying RAM and flip the bit at $0000 (I think, or $0001) to shut off the ROM so I could mess with some of the system defaults. |
| 00:09 | <@TheWatcher> | gnolam: sensible chap |
| 00:09 | <@TheWatcher> | 68k = <3 |
| 00:09 | < ToxicFrog> | Yay 68k |
| 00:09 | < ToxicFrog> | It's the chip I learned assembler on |
| 00:10 | <@Consul> | The 6510 had no multiply or divide commands. I had to write my own of those, too. |
| 00:10 | <@McMartin> | Consul: $00 and $01, IIRC. |
| 00:10 | | You're now known as TheWatcher[T-2] |
| 00:10 | <@McMartin> | Yup |
| 00:10 | | * McMartin actually has a bunch of 6502 routines still sitting around. |
| 00:10 | <@McMartin> | Comparing the 68k to the 65xx is cheating, especially since the 68k is all but a spiritual successor. |
| 00:11 | <@McMartin> | Well, nephew. |
| 00:11 | <@McMartin> | The 65xx being a lawyer-friendly version of the 6800, IIRC. |
| 00:12 | | You're now known as TheWatcher[zZzZ] |
| 00:14 | <@Consul> | I just remember the blazing 1Mhz speed. |
| 00:17 | <@Consul> | Even when the C64 was brand new, there were faster procs than that. |
| 00:59 | | Derakon is now known as Derakon[AFK] |
| 01:23 | | Derakon[AFK] is now known as Derakon |
| 01:38 | | gnolam [lenin@Nightstar-1382.A163.priv.bahnhof.se] has quit [Quit: Z?] |
| 03:35 | | Syloqs-AFH [Syloq@ServicesAdmin.Nightstar.Net] has quit [Connection reset by peer] |
| 03:44 | | Syloqs_AFH [Syloq@Admin.Nightstar.Net] has joined #code |
| 03:45 | | Syloqs_AFH is now known as Syloqs-AFH |
| 03:51 | | * Chalain twiddles his thumbs and waits for the Windows binary of Erlang to download. |
| 03:59 | | * Chalain suddenly realizes that this exercise leads to setting up a development environment in Windows again, which in addition to being excruciating, is just a whole hell of a lot of no fun. |
| 03:59 | | * Chalain gives up and wanders off to play with Erlang on his MBP. |
| 04:13 | < ToxicFrog> | Pfft |
| 04:19 | | * Derakon eyes the code for his Player class. |
| 04:20 | <@Derakon> | 486 lines long, and it's a mishmash of general physics-enabled code, general terrestrial-creature code, and player-specific code. |
| 04:20 | <@Derakon> | And with 16 constants. ¬.¬ |
| 04:20 | < ToxicFrog> | ;.; |
| 04:21 | < ToxicFrog> | Sounds like it's time to break out the Refactor Tractor |
| 04:21 | <@Derakon> | Before I can do that, I'll need to come up with an actual design. |
| 04:21 | <@Derakon> | This calls for a long, rambling LJ post! |
| 04:41 | | Reiv [~82d94c4d@Nightstar-29731.dsl.in-addr.zen.co.uk] has joined #Code |
| 04:51 | <@Derakon> | Long, rambling LJ post made; I haven't resolved anything, but I think I've lined up what needs to be resolved. |
| 05:12 | | SmithKurosaki [~jess@Nightstar-6870.dsl.teksavvy.com] has quit [Quit: Leaving] |
| 05:16 | | S_Kurosaki is now known as SmithKurosaki |
| 05:16 | < SmithKurosaki> | thats better |
| 05:23 | <@Chalain> | jerith: (or other Erlangers!) Why does this work from a file but crash when typed into the interactive shell: |
| 05:24 | <@Chalain> | sum([], N) -> N; sum([H|T], N) -> sum(T, H+N). |
| 05:25 | <@Chalain> | Fails with this error: * 1: syntax error before: '->' |
| 05:50 | | SmithKurosaki [~Jenn@Nightstar-7213.cpe.net.cable.rogers.com] has quit [Client exited] |
| 05:51 | | SmithKurosaki [~Jenn@Nightstar-7213.cpe.net.cable.rogers.com] has joined #code |
| 05:57 | | Reiv [~82d94c4d@Nightstar-29731.dsl.in-addr.zen.co.uk] has quit [Quit: Or rather, hometiem anyway~] |
| 06:01 | | Syloqs-AFH [Syloq@ServicesAdmin.Nightstar.Net] has quit [Connection reset by peer] |
| 06:30 | | * McMartin battles the forces of .mpkg |
| 06:32 | <@McMartin> | Seriously. Worst of all worlds. |
| 06:44 | < ToxicFrog> | mpkg? |
| 06:46 | <@McMartin> | Mac metapackage format. |
| 06:46 | <@McMartin> | All the disadvantages of .msi without its sole redeeming feature |
| 06:47 | <@McMartin> | Pollutes a global repository but does *not* include any uninstall mechanism, and the standard "drag .app to Trash" leaves the effluvium behind. Bra-vo. |
| 06:48 | <@McMartin> | Uninstallers must be included in the .dmg file; hope you kept it around after installing it! |
| 07:15 | | UndeadAnno [AnnoDomini@Nightstar-29141.neoplus.adsl.tpnet.pl] has joined #Code |
| 07:15 | | mode/#code [+o UndeadAnno] by ChanServ |
| 07:15 | <@Vornicus> | I still wonder why Mac and Windows haven't made package managers yet. |
| 07:16 | <@Derakon> | Politics surrounding access to the manager, I suspect. |
| 07:16 | <@McMartin> | Windows's Add/Remove Programs basically *is* a package manager. |
| 07:16 | <@McMartin> | It's why there's an uninstall process. |
| 07:16 | <@McMartin> | Mac is Just Better because there isn't one! You just drag the app to the trash! |
| 07:16 | <@McMartin> | </3 |
| 07:17 | <@McMartin> | Except that doesn't actually cut it anymore. =P |
| 07:17 | <@McMartin> | If, indeed, it ever did, of which I am now skeptical now that I see what you can't do with it. |
| 07:17 | <@McMartin> | Like, StartupItems, which go back to Classic OS v.Old. |
| 07:19 | <@Vornicus> | Technically you should be able to just install the app by dragging it to the place you want it to live, but... |
| 07:19 | < jerith> | Chalain: Function definitions (and, I believe, macros) aren't supported in the shell. |
| 07:19 | <@McMartin> | Vorn: Yes, the .pkg is for when that isn't enough. |
| 07:19 | <@McMartin> | And .mpkg is for when one .pkg isn't enough |
| 07:19 | <@McMartin> | And it's still not enough for all installation procedures. |
| 07:19 | < jerith> | Chalain: You can do something like: Sum = fun([], N) -> N; ... |
| 07:20 | < jerith> | I thinks. |
| 07:20 | <@McMartin> | In particular, if you need to touch two volumes, you are SOL |
| 07:20 | <@McMartin> | And if a program requires installing kernel extensions or other daemon services, those too cannot simply be "drag to Applications to install" |
| 07:21 | <@McMartin> | (Which is what .pkg is for; it's a .zip with a fancy UI and the ability to run setup scripts before and afterwards) |
| 07:21 | <@McMartin> | (What there *isn't* is a way to have a "push here to reverse what this pkg did" button, even one provided by the dev.) |
| 07:21 | <@McMartin> | (So we have installers, which end up touching global state like /System/Library and /Library/Receipts, but no uninstaller.) |
| 07:33 | | Derakon is now known as Derakon[AFK] |
| 07:39 | | SmithKurosaki [~Jenn@Nightstar-7213.cpe.net.cable.rogers.com] has quit [Operation timed out] |
| 07:40 | | SmithKurosaki [~Jenn@Nightstar-7213.cpe.net.cable.rogers.com] has joined #code |
| 08:08 | < ToxicFrog> | Re: windows add/remove programs: it's "uninstall process" basically boils down to "the installed program must register an arbitrary command to be used as an uninstaller" |
| 08:09 | < ToxicFrog> | So if it didn't, or if it did but the uninstaller doesn't work correctly, you're hosed. |
| 08:17 | <@McMartin> | Yes. |
| 08:17 | <@McMartin> | But it is possible to register something and the normal application lifecycle includes a place for it. |
| 08:17 | <@McMartin> | An equivalent for the Mac would be for there to be a magic executable in Contents/ somewhere that is run upon deletion. |
| 09:09 | | You're now known as TheWatcher |
| 09:35 | | gnolam [lenin@Nightstar-1382.A163.priv.bahnhof.se] has joined #Code |
| 09:35 | | mode/#code [+o gnolam] by ChanServ |
| 09:46 | | Vornicus is now known as Vornicus-Latens |
| 09:58 | | gnolam [lenin@Nightstar-1382.A163.priv.bahnhof.se] has quit [Quit: Rebooting] |
| 10:00 | | gnolam [lenin@Nightstar-1382.A163.priv.bahnhof.se] has joined #Code |
| 10:00 | | mode/#code [+o gnolam] by ChanServ |
| 10:25 | | Attilla [~The.Attil@Nightstar-9147.cdif.cable.ntl.com] has joined #code |
| 10:25 | | mode/#code [+o Attilla] by ChanServ |
| 10:44 | | Rhamphoryncus [~rhamph@Nightstar-7168.ed.shawcable.net] has quit [Quit: Rhamphoryncus] |
| 11:05 | | UndeadAnno [AnnoDomini@Nightstar-29141.neoplus.adsl.tpnet.pl] has quit [Ping Timeout] |
| 11:08 | | UndeadAnno [AnnoDomini@Nightstar-29502.neoplus.adsl.tpnet.pl] has joined #Code |
| 11:08 | | mode/#code [+o UndeadAnno] by ChanServ |
| 11:39 | | Attilla [~The.Attil@Nightstar-9147.cdif.cable.ntl.com] has quit [Quit: <Insert Humorous and/or serious exit message here>] |
| 12:02 | | gnolam [lenin@Nightstar-1382.A163.priv.bahnhof.se] has quit [Quit: SP2] |
| 12:38 | | Tarinaky [~Tarinaky@88.83.110.ns-10776] has quit [Operation timed out] |
| 12:40 | | Tarinaky [~Tarinaky@88.83.110.ns-10776] has joined #code |
| 13:51 | | UndeadAnno [AnnoDomini@Nightstar-29502.neoplus.adsl.tpnet.pl] has quit [Ping Timeout] |
| 13:52 | | UndeadAnno [AnnoDomini@Nightstar-29502.neoplus.adsl.tpnet.pl] has joined #Code |
| 13:52 | | mode/#code [+o UndeadAnno] by ChanServ |
| 14:41 | | Orthia [~Orthianz@Nightstar-8852.xdsl.xnet.co.nz] has quit [Quit: ] |
| 14:46 | | gnolam [lenin@Nightstar-1382.A163.priv.bahnhof.se] has joined #Code |
| 14:46 | | mode/#code [+o gnolam] by ChanServ |
| 15:55 | | UndeadAnno [AnnoDomini@Nightstar-29502.neoplus.adsl.tpnet.pl] has quit [Connection reset by peer] |
| 15:55 | | AbuDhabi [AnnoDomini@Nightstar-29502.neoplus.adsl.tpnet.pl] has joined #Code |
| 16:06 | | Syloq [Syloq@NetAdmin.Nightstar.Net] has joined #code |
| 16:07 | | Syloq is now known as Syloqs-AFH |
| 16:32 | | Derakon[AFK] is now known as Derakon |
| 17:41 | < ToxicFrog> | McMartin: aah. |
| 18:53 | | * Derakon ponders his Player class. |
| 18:54 | | * ToxicFrog ponders the client-side event hanlder |
| 18:55 | < ToxicFrog> | At the moment, it handles all events explicitly, and passes some to the ui with lc.message |
| 18:55 | < ToxicFrog> | But the more I play with this layout the less I like it. |
| 18:55 | < ToxicFrog> | lc should be part of the ui module, not part of the program core. |
| 18:55 | < ToxicFrog> | As a trivial example, consider a graphical version that needs to see the game events to choose which animations to play. |
| 18:56 | < ToxicFrog> | So, new design proposal. |
| 18:56 | <@Derakon> | Okay, I have a function checkHeadroom() that looks at blocks directly above/below the player (yeah, great function name huh?). I do this for two reasons: in handleInput(), to check if the player is allowed to stand up when they release the crouch button; in getAction() to make players fall when they run out of ground while crawling. |
| 18:56 | < ToxicFrog> | Upon recving an event, the client checks to see if it has an event handler for it. If it does, it calls that handler. |
| 18:56 | < ToxicFrog> | It then passes the event unmodified to the UI with ui.event() |
| 18:57 | < ToxicFrog> | It is then up to the UI to decide if, and how, to represent it. |
| 18:59 | <@Derakon> | Sounds plausible. |
| 19:00 | < ToxicFrog> | Good. |
| 19:00 | < ToxicFrog> | This means the UI sees more of the guts of the protocol, but also greatly reduces coupling between the client and the UI. |
| 19:01 | <@Derakon> | You could make a protocol-abstracter. *shrug* |
| 19:02 | | ToxicFrog [~ToxicFrog@Admin.Nightstar.Net] has quit [Killed (Services.Nightstar.Net (Too many invalid passwords (#Test)))] |
| 19:03 | < SmithKurosaki> | wtf just happened to tf |
| 19:03 | <@Vornicus-Latens> | He was doing Science. |
| 19:03 | <@Derakon> | He failed some kind of security check. |
| 19:03 | < Namegduf> | He forgot a password and kept trying, and services killed him after he put the invalid one in too many times. :P |
| 19:04 | < SmithKurosaki> | annoying, you think he would have it auto identift |
| 19:04 | < Namegduf> | (I would hazard a guess at "the channel password for #Test") |
| 19:04 | <@Vornicus-Latens> | This was actually Intentional. |
| 19:04 | | ToxicFrog [~ToxicFrog@Admin.Nightstar.Net] has joined #code |
| 19:04 | | mode/#code [+o ToxicFrog] by ChanServ |
| 19:04 | < SmithKurosaki> | *identify |
| 19:04 | < SmithKurosaki> | ahh |
| 19:04 | < Namegduf> | Ah, I see. |
| 19:04 | < SmithKurosaki> | to see if he would get kicked? |
| 19:04 | < Namegduf> | Checking it did that for channel passwords too? |
| 19:04 | < Namegduf> | Neat. :P |
| 19:05 | <@Vornicus-Latens> | We were discussing the consequences of screwing up a channel pass too many times. |
| 19:06 | < SmithKurosaki> | ahh, and tf ended up the guinea pig? |
| 19:06 | <@ToxicFrog> | I poked the defence systems one time too many. |
| 19:06 | <@ToxicFrog> | Derakon: more so than it is already? The UI will be seeing things like { event = "say"; who = "The Player"; text = "What they said") |
| 19:07 | < SmithKurosaki> | so, you were checking a password locked channel to see what would happen if you fucked up the pw too much? |
| 19:07 | <@ToxicFrog> | Pretty much. |
| 19:07 | <@Derakon> | TF: gotcha. |
| 19:07 | < SmithKurosaki> | interesting |
| 19:07 | <@ToxicFrog> | The actual on-the-wire stuff is handled just above the socket library itself; all most of the program sees is event structs. |
| 19:08 | < SmithKurosaki> | makes sense thats what it does though, if its a bot trying to brute force a channel.... |
| 19:08 | <@ToxicFrog> | (in particular, the read and write primitives return and take events) |
| 19:09 | <@ToxicFrog> | And it occurs to me that as the protocol is written, every event on the wire is something that may require a UI update anyways |
| 19:10 | < SmithKurosaki> | yay? |
| 19:11 | <@Derakon> | Okay, I stopped talking earlier so TF could say his bit...now it's my turn again. :) |
| 19:11 | <@Derakon> | So I have code that examines the terrain to see if the player is allowed to stand up, and if they should stop falling. |
| 19:11 | <@Derakon> | Both of these are very specific to the player right now. |
| 19:12 | < SmithKurosaki> | right |
| 19:12 | <@Derakon> | Specifically, they assume that the object they're checking for is 1 block wide, unless the player is crawling (where their sprite is about 2 blocks wide), in which case they assume that there's only 1 block they care about and it's offset from the player's actual position. |
| 19:13 | <@Derakon> | I want to genericize this so that I can have less special logic in the player's code |
| 19:13 | <@ToxicFrog> | Makes sense. |
| 19:13 | <@Derakon> | So imagine a large quadruped, and compare it to the player. |
| 19:14 | <@Derakon> | Both need to be checking a certain tile to know if they've walked off an edge. |
| 19:14 | <@Derakon> | How do I determine which tile it is? |
| 19:14 | <@Derakon> | And what's the right way to handle checking for headroom? |
| 19:16 | <@ToxicFrog> | Have the class specify getWidth() and getHeight(), which the physics code uses to check? |
| 19:16 | <@Derakon> | I need to be able to say "This is the center, or critical point, or whatever, of this creature", I guess. And as long as that point is above solid ground they won't fall? |
| 19:16 | <@ToxicFrog> | Aah. |
| 19:16 | <@Derakon> | TF: trick there is that width and height vary with your current animation. |
| 19:16 | <@ToxicFrog> | That's why they're methods. |
| 19:18 | <@Derakon> | But practically speaking, I can't use the same approach for checking for headroom -- I'd need to check every square that the standing creature could hit, which is more than 1 column even for the player. |
| 19:18 | <@Derakon> | So assume we ditch using checkHeadroom() for actually, y'know, checking headroom. ¬.¬ |
| 19:19 | <@Derakon> | I guess with standing up, we just let the creature do it, and then if they hit their heads, force them to crouch again? |
| 19:20 | < SmithKurosaki> | that sounds ok to me |
| 19:21 | < SmithKurosaki> | (im a newbie to programming, kind of) |
| 19:21 | <@Derakon> | Heh. |
| 19:21 | <@ToxicFrog> | This isn't just programming - it's PHYSICS! |
| 19:21 | < SmithKurosaki> | :science: |
| 19:21 | <@Derakon> | Well, it's an imitation of physics, anyway. |
| 19:21 | <@Derakon> | It bears little relation to the real thing. |
| 19:21 | <@ToxicFrog> | It's physics, it's just not our physics. |
| 19:22 | < SmithKurosaki> | :science: |
| 19:22 | < SmithKurosaki> | that is all that needs to be said |
| 19:22 | <@Vornicus-Latens> | I would say your best bet is to Try It and see if it works, and then if it fails don't commit that change. |
| 19:22 | <@Derakon> | Heh. Yeah. |
| 19:26 | | * Derakon eyes his code. "Yeah, way to iterate over an array the size of the entire map every draw cycle, idiot." |
| 19:27 | <@ToxicFrog> | Oops |
| 19:27 | <@Derakon> | (The drawing code for environmental effects was sorely unoptimized) |
| 19:30 | | Rhamphoryncus [~rhamph@Nightstar-7168.ed.shawcable.net] has joined #code |
| 19:31 | <@Derakon> | Hrm...this is not a good test case, though it reveals another special case I need to handle which I'll need terrain analysis for. |
| 19:31 | <@Derakon> | http://derakon.dyndns.org/~chriswei/games/jbrl/collision/climb1.png |
| 19:31 | <@Derakon> | That's the tail end of the climbing animation, which doesn't consider that the player might be climbing onto a sloped surface. |
| 19:32 | <@Derakon> | It occurs to me, I don't think that Metroid Fusion or Metroid Zero Mission ever had slopes turn into cliffs like this, probably to dodge this very issue. |
| 19:34 | <@ToxicFrog> | Pretty sure Fusion did, at least |
| 19:34 | <@ToxicFrog> | But Fusion also didn't let you climb arbitrary surfaces |
| 19:34 | <@ToxicFrog> | And all the climbable walls did end in flat ground. |
| 19:34 | <@Derakon> | Hmm? It let you grab ledges, which is all this is. |
| 19:35 | <@ToxicFrog> | Hmm |
| 19:45 | <@Vornicus-Latens> | Metroid Fusion I don't think has any slope-to-cliff conversions. |
| 19:45 | <@Derakon> | I'm watching the MF 100% TAS right now and not seeing any. |
| 19:46 | <@Vornicus-Latens> | I'm scrolling over the map at vgmaps.com |
| 19:46 | <@Derakon> | Smart. |
| 19:46 | <@Derakon> | In any event, aside from requiring two climb-up animations, I don't think it's that huge a deal. In order to hang, I need to know if the block is a slope block or not anyway, since you grab the bottom of a slope block but the top of a square block. |
| 19:46 | | Syloqs-AFH is now known as Syloqs |
| 19:46 | <@Derakon> | It's just another one of thoses annoying little details... |
| 19:47 | <@Derakon> | (That said, for now, a straightforward modification of my block mapping system should eliminate slope-to-cliff transitions) |
| 19:48 | <@Vornicus-Latens> | sectors 0-4 are devoid of them. |
| 19:48 | | Syloqs is now known as Syloqs-AFH |
| 19:49 | <@Derakon> | Yeah, that did the trick. |
| 19:49 | <@Derakon> | I love my block selection system. It's so easy to use. <3 |
| 19:50 | <@Vornicus-Latens> | All right, that's all of them. There are no places in Metroid Fusion where a cliff ends in a slope at the top. |
| 19:50 | <@Derakon> | Thanks for checking. |
| 19:55 | <@Derakon> | Urgh...okay, the whole action <=> sprite relationship needs to be reworked. |
| 19:55 | <@ToxicFrog> | ;.; |
| 19:55 | <@Derakon> | I think I may have to just rip out most of the Player code and rewrite it from scratch. |
| 19:55 | < SmithKurosaki> | why the crying tf? |
| 19:56 | <@Derakon> | It's only 491 lines...shouldn't take too long. |
| 19:57 | <@ToxicFrog> | SmithKurosaki: <Derakon> Urgh...okay, the whole action <=> sprite relationship needs to be reworked. |
| 19:57 | <@Derakon> | This is what happens when you grow a class organically instead of designing it. |
| 19:58 | <@Derakon> | Hell, it happens sometimes even when you design things. |
| 19:58 | < SmithKurosaki> | :( |
| 19:58 | <@Derakon> | S'part of development. Doesn't mean I have to like it. |
| 19:58 | | * SmithKurosaki hugs Derakon |
| 19:58 | <@Derakon> | Aww. :) |
| 19:58 | < SmithKurosaki> | u try |
| 19:58 | < SmithKurosaki> | *i try |
| 19:58 | <@Derakon> | Rather different meanings there. :) |
| 20:00 | <@Derakon> | Of course, while I'm rewriting everything I may as well do the design I wrote up yesterday. |
| 20:00 | < SmithKurosaki> | good luck |
| 20:01 | <@Derakon> | And doing that properly requires lunch. |
| 20:01 | <@Derakon> | I shall return later. |
| 20:01 | | Derakon is now known as Derakon[fuud] |
| 21:28 | | Derakon[fuud] is now known as Derakon |
| 21:28 | <@Derakon> | Okay, that was more than just getting lunch, but I'm back now. |
| 21:29 | <@Derakon> | Now, the terrain-hugging logic used by terrestrial creatures requires modifying collision ejection vectors so that, for example, they don't slide down slopes. What I'm thinking is that at the base, "physics-enabled class", I'll do all collision handling; however, the class will call self.modifyEjectionVector(vector), and children of the class can make any necessary changes. |
| 21:29 | <@Derakon> | Oh, I need a class name for physics-enabled game objects. |
| 21:33 | < SmithKurosaki> | physics_objs? |
| 21:33 | <@Derakon> | Oddly enough that's basically what I decided on. PhysicsObject, in physicsobj.py. |
| 21:33 | < SmithKurosaki> | :) |
| 21:39 | <@Derakon> | ...right, the existing handleCollisions function is 120 lines long. And it's a mess. |
| 21:44 | | * Derakon chops out 80 lines of stuff that doesn't belong at the PhysicsObject level. |
| 21:46 | | Vornicus-Latens is now known as Vornicus |
| 21:55 | | Syloqs-AFH [Syloq@NetAdmin.Nightstar.Net] has quit [Connection reset by peer] |
| 22:02 | <@Derakon> | Right, very basic "won't let you intersect with objects" PhysicsObject class made. |
| 22:06 | | Syloqs_AFH [~Syloq@Admin.Nightstar.Net] has joined #code |
| 22:07 | | Syloqs_AFH is now known as Syloqs-AFH |
| 22:13 | | SK [~Smith@Nightstar-6870.dsl.teksavvy.com] has joined #code |
| 22:14 | <@Vornicus> | Speaking of which, i must write physics. |
| 22:14 | <@Derakon> | You want my Polygon class? |
| 22:14 | < SK> | physics! |
| 22:15 | <@Vornicus> | No, I don't think it will be very useful. |
| 22:15 | <@Vornicus> | As I'm not useing any polygons. Yet. |
| 22:15 | <@Derakon> | What are you using, then? |
| 22:15 | <@Vornicus> | Square tiles, a circular dude, and SAT. |
| 22:16 | <@Derakon> | ...circular dude. |
| 22:16 | <@Derakon> | Okay, fair enough. |
| 22:16 | <@Vornicus> | He's a ball! |
| 22:16 | <@Derakon> | Oh, right, duh. |
| 22:16 | <@Derakon> | Yeah, my SAT implementation is strictly polygon-polygon; no curves. |
| 22:16 | <@Derakon> | Of course, you can implement a ball as a polygon with, say, 20 verts. |
| 22:17 | <@ToxicFrog> | SAT? |
| 22:18 | <@Vornicus> | Separating Axis Theorem |
| 22:18 | <@Derakon> | Convex polygon collision detection algo. |
| 22:18 | <@Vornicus> | Given two convex shapes, they intersect iff all projections onto a line of the two shapes intersect. |
| 22:19 | <@Derakon> | So as soon as you find a line where they don't intersect (as they probably don't), you can stop. |
| 22:19 | <@Vornicus> | FOr polygons you only have to check projections parallel to existing edges; for circles you check something else. |
| 22:19 | <@Derakon> | And if you do find an intersection, then the ejection vector is the one with the largest overlap of their projections. |
| 22:19 | <@Derakon> | Perpendicular, I thought it was... |
| 22:19 | <@Vornicus> | Er, something. |
| 22:20 | < SK> | shiny |
| 22:20 | <@Derakon> | It's handy. |
| 22:20 | <@ToxicFrog> | Something to keep in mind if I'm ever writing a physics engine, then. |
| 22:21 | <@McMartin> | IIRC, I actually use something like it for Sable. |
| 22:21 | <@Derakon> | I don't know what you use in 3D. |
| 22:21 | <@McMartin> | For OBB collision checks. |
| 22:21 | <@McMartin> | OBB checks are very similar, IIRC. |
| 22:22 | <@ToxicFrog> | Object Bounding Box? |
| 22:22 | <@Derakon> | Oriented bounding box. |
| 22:22 | <@ToxicFrog> | Aah. |
| 22:22 | <@Derakon> | As opposed to an AABB, axis-aligned. |
| 22:23 | | SK [~Smith@Nightstar-6870.dsl.teksavvy.com] has quit [Client exited] |
| 22:25 | | SK [~Smith@Nightstar-6870.dsl.teksavvy.com] has joined #code |
| 22:25 | <@Vornicus> | Part of my problem is spin. |
| 22:27 | <@Derakon> | Hm. Spin should convert ejection vectors that are perpendicular to the surface to ones that are slightly non-perpendicular, and drain part of the spin in the process. |
| 22:27 | <@Derakon> | Or rather, they should give a boost to your velocity in the direction of spin, perpendicular to the ejection vector. |
| 22:28 | <@Vornicus> | ...actually now that I think about it I know how to handle spin. |
| 22:28 | <@Derakon> | Do tell. |
| 22:28 | <@Vornicus> | Spin gives an additional velocity component coming in. |
| 22:28 | <@Derakon> | Your velocity is irrelevant for SAT. |
| 22:28 | <@Vornicus> | True, but the bounce vector cares about velocity. |
| 22:28 | <@Derakon> | Unless you're trying to do swept polygons or something like that. |
| 22:29 | <@Derakon> | Sure, so modify the bounce vector based on spin. |
| 23:04 | | SmithKurosaki [~Jenn@Nightstar-7213.cpe.net.cable.rogers.com] has quit [Operation timed out] |
| 23:04 | | SmithKurosaki [~Jenn@Nightstar-7213.cpe.net.cable.rogers.com] has joined #code |
| --- Log closed Wed Jun 10 23:21:06 2009 |
| --- Log opened Wed Jun 10 23:21:11 2009 |
| 23:21 | | TheWatcher [~chris@Nightstar-29731.dsl.in-addr.zen.co.uk] has joined #code |
| 23:21 | | Irssi: #code: Total of 24 nicks [10 ops, 0 halfops, 0 voices, 14 normal] |
| 23:21 | | mode/#code [+o TheWatcher] by ChanServ |
| 23:22 | | Irssi: Join to #code was synced in 59 secs |
| 23:22 | | * Derakon repeats what he just said, for TW's benefit. |
| 23:22 | <@Derakon> | Suggestions for handling "rules" for movement? E.g. maximum runspeed, jump velocity, rate of slowdown when running, etc. |
| 23:22 | <@Derakon> | I want to use the same code for all terrestrial creatures, so this needs to be configurable somehow. Just make a class for it or something? |
| 23:24 | | AbuDhabi is now known as UndeadTroll |
| 23:30 | <@Vornicus> | I would say have a bunch of numbers. |
| 23:31 | <@Derakon> | And how are these numbers handled? |
| 23:32 | | * TheWatcher ponders |
| 23:34 | <@Vornicus> | I'd say each critter gets, along with all his normal goodies, a JSON thing that says all the various toys you need. This of course depends on your physics, but in EV for instance you have turn rate, acceleration, max velocity, jump speed, mass, crew complement, and a few others. |
| 23:35 | | * TheWatcher would be tempted to suggest that you have one class for movement rules that slurps settings from xml files, with some kind of include facility in the xml. So for say, critter1 you have something like <movement><include>terrestrial.xml</include><turnrate>4</turnrate></movement> so that you can have a set of base defaults for critters, and can override them on a per-critter-type basis... |
| 23:36 | <@ToxicFrog> | XML ;.; |
| 23:36 | <@Derakon> | I've been handling config by importing python files that contain dicts. |
| 23:36 | <@Derakon> | It's simpler than XML. |
| 23:36 | <@TheWatcher> | Fairynuff |
| 23:36 | <@Derakon> | I'm operating on the assumption that every critter will need to make its own class for AI, though. |
| 23:36 | <@Derakon> | So such numbers may as well be stored in that class. The question is, how. |
| 23:42 | | You're now known as TheWatcher[T-2] |
| 23:46 | | You're now known as TheWatcher[zZzZ] |
| --- Log closed Thu Jun 11 00:00:47 2009 |