| --- Log opened Wed Jun 27 00:00:07 2012 |
| --- Day changed Wed Jun 27 2012 |
| 00:00 | < Rhamphoryncus> | oh, they're being less dickish now |
| 00:00 | <&jerith> | Personal Package Archive, IIRC. |
| 00:03 | | Attilla [Obsolete@Nightstar-da0302d8.as43234.net] has joined #code |
| 00:04 | | You're now known as TheWatcher[T-2] |
| 00:05 | | Derakon[AFK] is now known as Derakon |
| 00:06 | | You're now known as TheWatcher[zZzZ] |
| 00:09 | | Attilla [Obsolete@Nightstar-da0302d8.as43234.net] has quit [Ping timeout: 121 seconds] |
| 00:10 | < Rhamphoryncus> | aaaaand I've removed my viewport in blender :P |
| 00:11 | < Rhamphoryncus> | automatically saved no less |
| 00:14 | | * Rhamphoryncus restores! |
| 00:15 | | Attilla [Obsolete@Nightstar-7cc45170.as43234.net] has joined #code |
| 00:28 | < celticminstrel> | On a random note, is there any reason to bother reducing framerate form 66.6 to a nicer integer number like 60 fps? |
| 00:28 | < celticminstrel> | ^from |
| 00:28 | <@Alek> | yes. to get less complaints from fundies. XD |
| 00:28 | < Rhamphoryncus> | Preferably you want to match vsync |
| 00:28 | < celticminstrel> | ^-number, because that's redundant when used with integer. |
| 00:28 | <&McMartin> | ^--- |
| 00:29 | <&McMartin> | Also, fixed integral framerate allows for certain engine simplifications. |
| 00:29 | < celticminstrel> | Does it? |
| 00:29 | < Rhamphoryncus> | Unfortunately you can't count on framerate exactly matching anything (or even being constant), but you may not care about the really subtle variations |
| 00:30 | < Rhamphoryncus> | Actually, I take that back |
| 00:30 | < Rhamphoryncus> | I don't know enough to say if you can ignore it rather than making sure you sync to it |
| 00:30 | < celticminstrel> | Also, why match vsync? |
| 00:30 | < Rhamphoryncus> | vsync is monitor update rate |
| 00:30 | <&McMartin> | On a PC: Avoids graphical tearing effects |
| 00:30 | <&McMartin> | On a console: still necessary to work at all, most often |
| 00:30 | < Rhamphoryncus> | So regardless if what you render you WILL display at the monitor's refresh rate |
| 00:31 | < celticminstrel> | Which for me is 60Hz. I suppose that's where 60 fps comes from. |
| 00:32 | < celticminstrel> | What's this graphical tearing effects? |
| 00:32 | < celticminstrel> | And why does a fixed integral framerate allow for engine simplifications? |
| 00:33 | <&McMartin> | 60 fps comes from the NTSC standard, idly |
| 00:33 | <&McMartin> | Its what North American and Japanese standard definition televisions had. |
| 00:33 | < celticminstrel> | (I didn't intentionally sit down and work out 66.6 fps; rather, I worked out intervals between frames which ended up coming out to 66.6 fps.) |
| 00:33 | <&McMartin> | Graphical tearing effects; if you had, say, 120 FPS, to make it obvious... |
| 00:34 | <&McMartin> | ... then the top half of the screen and the bottom half of the screen would be showing different frames. |
| 00:34 | < celticminstrel> | Huh, interesting. |
| 00:34 | <&McMartin> | If you're doing something like a continuous horizontal scroll, this produces a case where there's this line of displacement. |
| 00:35 | <&McMartin> | Deliberately exploiting this effect is an old 8-bit trick - if your console only supported 8 sprites, say, you could draw 8 sprites at the top of the screen, wait for the electron gun to move past then, move those sprites to the bottom of the screen, and get 16 sprites per frame. |
| 00:35 | <&McMartin> | (Then you'd move them back up to the top at VBLANK.) |
| 00:36 | < celticminstrel> | Heh. |
| 00:36 | <&McMartin> | The Atari 2600's "sprites" were actually only one scanline high - you were *expected* to reassign it every scanline to get sprites of any size. |
| 00:36 | < celticminstrel> | (fps and Hz are the same unit, yes?) |
| 00:36 | <&McMartin> | (Sort of: Hz is strictly speaking just the "ps" part of "fps") |
| 00:36 | <&McMartin> | (But yes) |
| 00:37 | <&McMartin> | Anyway, the gain is from a fixed framerate - if you have a variable framerate you are pretty much committing to an engine that can simulate various amounts of time per update. |
| 00:37 | <&McMartin> | With a fixed framerate you can have a concept of an "update tick" and set game world speeds in terms of things like pixels per tick. |
| 00:38 | <&McMartin> | With that, if the system overloads you get lag. |
| 00:38 | <&McMartin> | With the former, if the system overloads you get skipping/rubberbanding. |
| 00:38 | < celticminstrel> | Ah, but that doesn't seem to depend on the "integral" part... |
| 00:39 | <&McMartin> | No, not really. |
| 00:39 | <&McMartin> | For PC, vsync speeds vary between 50 Hz and 85 Hz, though, so variable-tick engines are often a good idea anyway |
| 00:40 | < celticminstrel> | Pretty sure I'm assuming fixed framerate. |
| 00:42 | <~Vornicus> | (note that if your physics rate is variable with video framerate, physics works differently depending on rendering speed) |
| 00:43 | < Rhamphoryncus> | Which leads to varying degrees of stupid |
| 00:43 | < celticminstrel> | My logic is pretty much "if 15ms have passed, do something". |
| 00:44 | < celticminstrel> | (Which gets a bit messed up after pausing; I need to address that later.) |
| 00:45 | < Rhamphoryncus> | celticminstrel: is that just a 15 ms sleep between frames? Or do you compensate for how long the frame took? |
| 00:45 | < celticminstrel> | It's a timer; every frame I restart it, and then keep checking until 15ms have passed. |
| 00:45 | < celticminstrel> | So I'd say I'm not compensating for anything like how long the frame took. |
| 00:46 | < celticminstrel> | That'd probably be why stuff wasn't quite as smooth as I wanted until recently. |
| 00:46 | < celticminstrel> | For example, at one point it took longer than 15ms to update the screen. |
| 00:46 | <~Vornicus> | You may wish to change your thing so it just waits for vsync |
| 00:47 | < celticminstrel> | Perhaps. |
| 00:47 | < gnolam> | Yeah, that method of timing is pretty much equivalent to doing Sleep(foo) between frames and Doesn't Work. |
| 00:48 | < celticminstrel> | That said... I do also have a constant in there which the 15ms is multiplied by. Currently it's fixed at 1, but I had contemplated allowing it to be adjusted a bit. |
| 00:48 | <~Vornicus> | This takes the sleep wait out of your hands; then you use the FIx Your Timestep physics trick. |
| 00:48 | < gnolam> | (It gets you wildly different game speeds on different computers.) |
| 00:48 | < celticminstrel> | gnolam: I'm aware it has issues, which is why I had plans to work on it at some point. |
| 00:48 | < celticminstrel> | (You're talking about the method I'm using, right?) |
| 00:48 | < gnolam> | (Yes) |
| 00:49 | < celticminstrel> | Vorn: I dunno what "Fix Your Timestep" is? |
| 00:49 | < gnolam> | If you're not vsyncing or using variable delta time, the normal method is to have a thread whose only job is to tick at a constant rate. |
| 00:49 | <&McMartin> | If you cache the current time after your wait finishes and then wait for 15 ms past *that* |
| 00:49 | <&McMartin> | You will actually do pretty OK. |
| 00:49 | < gnolam> | Basically just incrementing a counter saying how many frames behind you are. |
| 00:50 | <&McMartin> | But that's still "you will lag on hard frames" |
| 00:50 | < celticminstrel> | That's pretty much what I was doing, McM... |
| 00:50 | <&McMartin> | OK, that is *not* equivalent to "sleep(15)" |
| 00:50 | <&McMartin> | Which is Always Wrong |
| 00:50 | < celticminstrel> | No, I wasn't doing a sleep. |
| 00:51 | <&McMartin> | The sleep is safe on everything but Linux as long as it's a sleep to target time |
| 00:51 | < celticminstrel> | I do a sleep in one place where I want the user to see something that otherwise would pop up for barely long enough to see. |
| 00:51 | <&McMartin> | Linux has this problem that many Linux distros use a 10ms timestep which is WAY TOO MUCH |
| 00:51 | <~Vornicus> | "Fix Your Timestep" basically goes like this: you have a fixed physics timestep, and after each graphics frame you step your physics. |
| 00:51 | < celticminstrel> | But that's the only place. |
| 00:51 | < gnolam> | The second method is sort of what McMartin described, to keep track of "has enough time passed for me to do another tick". |
| 00:51 | <~Vornicus> | But you step your physics a number of times according to how much time has passed |
| 00:51 | < celticminstrel> | ...which is what I was doing, gnolam... |
| 00:51 | < gnolam> | Whose naive implementation has the disadvantage of allowing the game to slow down. |
| 00:52 | < gnolam> | A fixed timestep is the way to go. |
| 00:52 | <~Vornicus> | http://gafferongames.com/game-physics/fix-your-timestep/ |
| 00:52 | < celticminstrel> | Not sure I understand it... I suppose I'll do some Goo- or just click the link, sure. |
| 00:53 | <&McMartin> | gnolam: well, you're really just picking your failure mode there. |
| 00:53 | <&McMartin> | Either you're letting it slow down, or you're letting it rubberband/skip around. |
| 00:53 | <&McMartin> | There it depends hugely on your game type |
| 00:54 | < gnolam> | Well, no. |
| 00:54 | <&McMartin> | The more precise the input you demand from the player, the more "lag" becomes mandatory. |
| 00:54 | <&McMartin> | Because otherwise you risk saying "I require input from you at a point I didn't present to you" |
| 00:54 | < gnolam> | Which is usually not a problem. |
| 00:55 | <&McMartin> | It is, noticably, what meant I couldn't beat Super Metroid for years though, so when it *is* a problem it's a big fat one |
| 00:57 | <&McMartin> | Now, if you can do threads, the best world is... yeah, to decouple physics and rendering entirely, like the article says |
| 00:58 | <&McMartin> | But if you're making a game like Super Meat Boy, Fixed Delta locked to controlled framerate is pretty much mandatory for an acceptable play experience. |
| 00:59 | <&McMartin> | Also any fighting game with frame-level precision, which is all of them |
| 01:00 | < celticminstrel> | I don't need frame-level precision. |
| 01:00 | <&McMartin> | Then yeah, pretty much whatever |
| 01:00 | < celticminstrel> | I'm only checking player input every sixteen frames, I think. |
| 01:00 | <~Vornicus> | mcwhat |
| 01:00 | <&McMartin> | In fact, if you're mostly spinning on input, you can have basically arbitrary ticks; use vsync to avoid artifacts and for easiness. |
| 01:01 | <~Vornicus> | you'd better not be checking key state for that |
| 01:01 | < celticminstrel> | Why? |
| 01:01 | <~Vornicus> | Because it means that you'll miss most inpurts |
| 01:01 | <&McMartin> | Sixteen frames is, like, four cups of tea |
| 01:01 | < celticminstrel> | How so? |
| 01:01 | <~Vornicus> | How long do you think it takes to type a letter. |
| 01:02 | <&McMartin> | If you're looking at key state and not filtering the event stream, the key can go down and come up in 16 frames very easily. |
| 01:02 | < celticminstrel> | Ah, right. |
| 01:02 | <~Vornicus> | At my typing speed, a key can go down and come up in 16 frames /5 times/ |
| 01:03 | < celticminstrel> | Oh, I'm checking every 8 frames. |
| 01:03 | <~Vornicus> | Still. |
| 01:03 | <&McMartin> | Yeah, seriously, *one* frame is slow enough you can't trust this. |
| 01:03 | <&McMartin> | (In one fighting game forum, a certain move had a 1/15 second window you could do it in - the consensus was that this was insanely long. The line was "You could have a cup of tea and still have time to make the counter") |
| 01:03 | <&McMartin> | (Thus: 4 frames = 1 cup of tea) |
| 01:03 | <~Vornicus> | at 120 wpm you're getting 10 to 13 keypresses a minute. |
| 01:04 | <~Vornicus> | er, a second. |
| 01:04 | <&McMartin> | And that counts finger motion. |
| 01:04 | < celticminstrel> | I'm processing key events and checking current key state. |
| 01:04 | <&McMartin> | The former should be completely obviating the latter. |
| 01:05 | <&McMartin> | (Depending on OS bugs it might not be, but) |
| 01:05 | <~Vornicus> | If I'm mashing, I can beat 20 presses a second. |
| 01:05 | < celticminstrel> | I disabled key repeat, so I don't get events for held keys. |
| 01:05 | <&McMartin> | Not what I meant. |
| 01:06 | <~Vornicus> | Your key events tell you key state. |
| 01:06 | < gnolam> | McMartin: if you require "hit the exact frame, and every frame must be presented" precision, there /is/ no right way to go about it unless you have absolute control over the platform. |
| 01:06 | <&McMartin> | You can build a "held" from the event stream by filtering it, or count falling edges, depending on what it is you need. |
| 01:06 | | io|gone is now known as iospace |
| 01:06 | <&McMartin> | gnolam: That turns out to not be terribly difficult in practice. |
| 01:06 | < celticminstrel> | Oh true. |
| 01:07 | <&McMartin> | Hence my "every console ever" qualifier on that one. |
| 01:07 | <&McMartin> | Which is generally fixed-tick |
| 01:07 | <&McMartin> | Also, hilariously shitty NTSC/PAL ports -_- |
| 01:08 | <&McMartin> | More seriously, the actual answer there becomes "put your physics tick at either 25 or 30 FPS and and you're guaranteed to display what's needed even on interleaved displays" |
| 01:08 | <~Vornicus> | McM: the Cup of Tea thing reminds me of Diablo 1 |
| 01:09 | <~Vornicus> | where the window for duping was really short, and then the Hellfire expansion made duping trivial. |
| 01:11 | <~Vornicus> | (in diablo 1, to dupe an item, you put that item on the ground and an item of no consequence in your inventory. Close your inventory, walk away, then click the target item so you'll start to walk over and pick it up, open your inventory, and at the exact moment you pick up the item, click the no consequence itiem. You should end up with one copy of the item in your inventory and one copy on |
| 01:11 | <~Vornicus> | your cursor.) |
| 01:12 | <~Vornicus> | (this was most useful for spell books and ability boosters - though it should be noted that at maximum level you hit exactly all your ability caps anyway) |
| 01:12 | < celticminstrel> | "and one copy on"... I assume the ground? |
| 01:13 | <~Vornicus> | on your cursor. |
| 01:13 | < celticminstrel> | Oh. <_< |
| 01:13 | <~Vornicus> | But in the original it's very difficult, and in Hellfire the timing is about ten times as forgiving. |
| 01:13 | <~Vornicus> | I was never sure why. |
| 01:14 | < celticminstrel> | ie, easier in Hellfire? |
| 01:14 | <~Vornicus> | By a lot. |
| 01:15 | <&McMartin> | 15 frames is 250ms - that's within good human reaction time for something they *aren't expecting and aren't trying to sync with* |
| 01:15 | < celticminstrel> | ? |
| 01:15 | <~Vornicus> | I could almost reliably succeed at it. |
| 01:31 | < celticminstrel> | I still wish I could have an operator-> for an enum type. |
| 01:31 | | * celticminstrel is also still wondering about McM's comment. |
| 01:32 | <&McMartin> | In terms of what counts as a tea party in a game. |
| 01:32 | <~Vornicus> | celmin: which means that for my dupe case I was probably hitting a window of about three frames wide. |
| 01:32 | <&McMartin> | 15 frames means "you don't even need a visible wind-up" |
| 01:33 | < celticminstrel> | Is this any kind of reference to what I was saying, or is it something else? |
| 01:33 | <~Vornicus> | people playing DDR are in fact hitting single-frame targets. |
| 01:34 | <&McMartin> | Right, but those targets have a considerable wind-up |
| 01:34 | <&McMartin> | That's "syncing with 13ms precision" |
| 01:34 | <&McMartin> | Which is much, much easier than "reacting within 13ms", which doesn't really happen. |
| 01:35 | <&McMartin> | mean simple reaction time is 190ms and response time is longer depending on whether it's go/no-go or a full choice. |
| 01:51 | <@ToxicFrog> | Vornicus: Hellfire also adds the Cornerstone of the World, which makes it trivial even if you have no reflexes~ |
| 01:52 | <~Vornicus> | That I don't recognize. |
| 01:52 | <@ToxicFrog> | In the Crypt, there is a square. Drop an item on it and it's replicated across all of your saves. |
| 01:53 | <@ToxicFrog> | Abusing this to create infinite copies of any item requires two characters with access to the Cornerstone and about thirty seconds. |
| 01:53 | <&McMartin> | Is this a bug or a feature |
| 01:54 | <@ToxicFrog> | The replication is a feature; the fact that it makes things more easily dupable is a bug, but one that's hard to avoid. |
| 01:54 | <@ToxicFrog> | ...actually, come to think of it, it would have been easy to just make it slightly harder so it at least requires external file twiddling~ |
| 01:55 | <@ToxicFrog> | (basically, you can easily end up in a situation where the item exists on the cornerstone and in someone's inventory) |
| 01:55 | <~Vornicus> | I'm still trying to figure out whether Hellfire's expanded dupe window is intentional or not |
| 01:55 | <~Vornicus> | I can't think of any way for it to be unintentional. |
| 01:56 | <@ToxicFrog> | The drawback, of course, being that it requires two characters with access to the Cornerstone, whereas traditional duping can be done with 50gp worth of belt items and nothing else. |
| 01:56 | <@ToxicFrog> | I could see it being a side effect of some other change to input processing. |
| 01:56 | <~Vornicus> | Actually |
| 01:57 | <~Vornicus> | You can dupe using single gold pieces as your inconsequential item. |
| 01:57 | <@ToxicFrog> | AIUI, what causes the dupe to happen is "pick up item from belt" and "pick up item from ground" happening on the same tick. |
| 01:57 | <@ToxicFrog> | ....you can put gold in your belt? |
| 01:57 | <~Vornicus> | no, you don't need the morphed item to be on your belt |
| 01:57 | <@ToxicFrog> | Oh |
| 01:57 | <@ToxicFrog> | I've only ever done it using the belt |
| 01:58 | <~Vornicus> | My procedure is shown above. |
| 01:59 | <@ToxicFrog> | Aah, so |
| 02:01 | <@ToxicFrog> | ...you can't hit max stats without boosters, though |
| 02:01 | <@ToxicFrog> | not in everything |
| 02:01 | <@ToxicFrog> | Needs about 70 levels, D1 tops out at 50. |
| 02:02 | | * Vornicus checks again |
| 02:03 | <~Vornicus> | huh, I could've sworn |
| 02:12 | | Tamber [tamber@furryhelix.co.uk] has quit [Ping timeout: 121 seconds] |
| 02:17 | | Tamber [tamber@furryhelix.co.uk] has joined #code |
| 02:17 | | mode/#code [+o Tamber] by ChanServ |
| 02:17 | | Attilla [Obsolete@Nightstar-7cc45170.as43234.net] has quit [Ping timeout: 121 seconds] |
| 02:27 | | Orthia [orthianz@3CF3A5.E1CD01.C6689C.33956A] has joined #code |
| 02:46 | | Kindamoody[zZz] is now known as Kindamoody |
| 03:02 | | Tamber [tamber@furryhelix.co.uk] has quit [[NS] Quit: *rasmfrasm*] |
| 03:02 | | Tamber [tamber@furryhelix.co.uk] has joined #code |
| 03:02 | | mode/#code [+o Tamber] by ChanServ |
| 03:08 | | Attilla [Obsolete@Nightstar-7cc45170.as43234.net] has joined #code |
| 03:16 | | Attilla [Obsolete@Nightstar-7cc45170.as43234.net] has quit [[NS] Quit: ] |
| 03:24 | | SmithKurosaki [smith@Nightstar-1748d158.home1.cgocable.net] has joined #code |
| 03:25 | < celticminstrel> | I dunno... is there any other way for me to handle keypresses? Checking more frequently doesn't seem possible. |
| 03:26 | < Tarinaky> | Other than what? |
| 03:27 | < gnolam> | What are you using? SDL? |
| 03:27 | < gnolam> | (The answer is usually "events") |
| 03:31 | < celticminstrel> | Basically what I did was, whenever an arrow key is pressed (ie, I receive a key down event), I store that it was pressed. Then when I need to know which direction the player moves, I call a function which checks the current key state to see if a key is down, and if not, checks the cache of keypresses, which it then clears before returning the direction. It works for the most part, the only minor artifact being that sometimes |
| 03:31 | < celticminstrel> | the player will move one space when starting the game because a key was pressed prior to this (but this is easily fixable by clearing the aforementioned cache). I can't just check the key state, because I'm only checking every 16 frames and it's quite easy for a key press-and-release to fit between checks; for similar reasons, simply processing events doesn't work either since it may be the case that the frame in which the |
| 03:31 | < celticminstrel> | event was received is not a frame in which the player object is deciding on a direction. And I can't see a reasonable way to check for input more frequently. |
| 03:37 | <&Derakon> | Why only check every 16 frames? |
| 03:37 | < celticminstrel> | Because that's when the player gets to move. |
| 03:38 | < Tarinaky> | This sounds dodgy. |
| 03:38 | < celticminstrel> | It does a bit. |
| 03:38 | <&Derakon> | That means that, assuming 60 frames per second, any input that lasts less than a quarter of a second is ignored. |
| 03:38 | < Tarinaky> | The best way is to have keypresses -and- key-releases entered into a queue. |
| 03:39 | < Tarinaky> | When a key is pressed you set some flag to indicate it's down. |
| 03:39 | < Tarinaky> | When a key is released you unset that flag to indicate it's up. |
| 03:39 | < celticminstrel> | Well, the way I've done it does work; input isn't ignored due to the cache generated by keydown events. |
| 03:39 | < celticminstrel> | But hm, okay. |
| 03:39 | < Tarinaky> | When you do a tick/update if a cardinal direction is in a down state you know to apply accelleration in that direction. |
| 03:40 | < Tarinaky> | Disclaimer: Don't do anything I say. |
| 03:40 | < Tarinaky> | I'm terrible |
| 03:40 | < celticminstrel> | I didn't try entering keydown and keyup into a queue; what I tried was just the setting/unsetting of the flag. I dunno how the queue would make it any different though. |
| 03:41 | <&McMartin> | The queue is more important for things like menus, where you want to detect the "falling edge" - if the key goes down and up within a single tick, for moving something around you want to do nothing |
| 03:41 | <&McMartin> | But for menu navigation etc you want to track that as a single press. |
| 03:42 | < celticminstrel> | Nothing? What? |
| 03:42 | < celticminstrel> | If the key goes down and up quickly, I want to move one space. |
| 03:43 | < celticminstrel> | I suppose the queue could work if it's only processed when a key is needed, but... that feels like it would either tend to ignore a lot of stuff or just let the queue grow faster than it's emptied. |
| 03:44 | < celticminstrel> | Neither of which would be a good thing, I think. |
| 03:45 | < celticminstrel> | Maybe I should just leave it since it pretty much works... |
| 03:46 | < Tarinaky> | Good idea. |
| 03:47 | < celticminstrel> | Heh. |
| 03:47 | < Tarinaky> | It sounds like you might have coupling issues though :x |
| 03:47 | < celticminstrel> | Oh yes. I have major coupling issues. <_< |
| 03:48 | < celticminstrel> | I have periodically attempted to reduce them though. |
| 03:49 | | * ToxicFrog fixes a bug in Enceladus that's existed since the -o option was introduced \o/ |
| 03:49 | | iospace is now known as iospacingout |
| 03:54 | | * Tarinaky blinks. |
| 03:54 | < Tarinaky> | What is wrong with this code. |
| 03:54 | < celticminstrel> | I've had that thought a lot. <_< |
| 03:54 | < Tarinaky> | Oh. |
| 03:54 | < Tarinaky> | DERP |
| 03:56 | < Tarinaky> | Yeah, that's why. |
| 03:56 | <~Vornicus> | TF: what's that bug? |
| 03:58 | | SmithKurosaki [smith@Nightstar-1748d158.home1.cgocable.net] has quit [Client closed the connection] |
| 03:59 | <@ToxicFrog> | Vornicus: -o doesn't actually work; -o foo will combine foo with the name of the input file rather than just taking it verbatim as the name of the output file. |
| 04:01 | | * Tarinaky stares at this. |
| 04:02 | < Tarinaky> | Why does int /= int give me a float. |
| 04:02 | < Tarinaky> | That's retarded. |
| 04:02 | < Tarinaky> | Not only that, why does using it to index an array not seem to coerce it into an int? |
| 04:03 | <&Derakon> | Language? |
| 04:03 | <~Vornicus> | python? |
| 04:03 | <~Vornicus> | in py3, or in py2 using from __future__ import division, use //= |
| 04:03 | <&Derakon> | Must be Python 3 then. |
| 04:04 | < Tarinaky> | Python2 |
| 04:04 | <&Derakon> | And yeah, // is division with truncation. |
| 04:04 | <&Derakon> | I just tried "foo = 3; foo /= 2; print foo" and got 1 in Python 2.7. |
| 04:04 | <~Vornicus> | Even if you're not using the future import, // works as advertised. |
| 04:04 | < Tarinaky> | Yeah, but x /= y is supposed to be a sugar for x = x / y |
| 04:05 | < Tarinaky> | If x and y are both ints in the latter case it'll return an int in py2. |
| 04:05 | <&Derakon> | Right, and I'm not able to replicate your complaint in Python 2. |
| 04:05 | <&Derakon> | So something else must be going on. |
| 04:05 | <~Vornicus> | I don't know what you're seeing, but we're not seeing that behavior. |
| 04:05 | < Tarinaky> | Really? |
| 04:05 | < Tarinaky> | Then I must have two bugs >.> |
| 04:05 | <&Derakon> | (Also, generally speaking I'm not a fan of importing anything besides braces from __future__) |
| 04:05 | < celticminstrel> | Braces? |
| 04:05 | <~Vornicus> | (I use division relatively often) |
| 04:06 | <&Derakon> | (Because it changes how the language behaves and if you don't notice the import then it can be confusing) |
| 04:06 | <&Derakon> | CM: try "from __future__ import braces" |
| 04:06 | <&Derakon> | Vorn: yeah, and I'd rather just cast to float. |
| 04:06 | < celticminstrel> | Heh. |
| 04:06 | | iospacingout is now known as iospacedout |
| 04:06 | < Tarinaky> | 04:06 <&Derakon> CM: try "from __future__ import braces" |
| 04:06 | < Tarinaky> | Err |
| 04:06 | < Tarinaky> | SyntaxError: not a chance |
| 04:06 | <&Derakon> | Quite. |
| 04:07 | < Tarinaky> | That was the output of from __future__ import braces |
| 04:07 | <&Derakon> | Yes. |
| 04:07 | < celticminstrel> | Easter egg. |
| 04:07 | <~Vornicus> | import this |
| 04:07 | <&Derakon> | I did not know about that one, Vorn. |
| 04:09 | < Tarinaky> | Things that annoy me in ipython, Ctrl+D doesn't quit immediately. |
| 04:09 | < Tarinaky> | >.> |
| 04:09 | <&Derakon> | Not until the application processes input, no. |
| 04:09 | < Tarinaky> | Do you really want to exit ([y]/n)? |
| 04:09 | < Tarinaky> | Is what I mean. |
| 04:09 | <&Derakon> | Ah. |
| 04:10 | < celticminstrel> | ipython, not python. :P |
| 04:10 | < Tarinaky> | Although pressing ctrl+D twice works. But that's liable to lead me into quitting a shell by accident. |
| 04:13 | < Tarinaky> | Also: this ui code is making me cry. |
| 04:23 | <@ToxicFrog> | Derakon: import print_function all day every day, IMO |
| 04:24 | <~Vornicus> | I forgot about that one. |
| 04:25 | <&Derakon> | TF: eh, I'll do it when Python 3 comes around with no complaint. |
| 04:25 | <&Derakon> | I just don't really like modifying the language if someone else has to use my code. |
| 04:25 | <&Derakon> | And I generally assume that someone else will have to use my code. |
| 04:25 | <@ToxicFrog> | If it's a keyword you can't map() it |
| 04:25 | <&Derakon> | It makes my life more pleasant three months down the line~ |
| 04:27 | < Tarinaky> | http://imgur.com/Hojnl << Current state of progress on my game. |
| 04:32 | < celticminstrel> | I don't think I've ever felt an urge to map() it. |
| 04:51 | | maoranma [nbarr@Nightstar-04dbf5f6.pools.spcsdns.net] has quit [[NS] Quit: Leaving] |
| 05:04 | <@ToxicFrog> | <3 premake |
| 05:05 | | * McMartin solves problem #82 on 4Clojure by defining a function with 7 internal functions, some of them recursive |
| 05:05 | <&McMartin> | This is strictly speaking a matter of formatting, but come *on* guys |
| 05:06 | | Kindamoody is now known as Kindamoody|movie |
| 05:07 | <&McMartin> | OTOH, Light Table: pretty great |
| 05:14 | | * Vornicus pokes vaguely at game maker |
| 05:17 | <&McMartin> | If you have questions, feel free to ping me |
| 05:22 | <~Vornicus> | I guess i should make some basic art first so it's not totally abstract. |
| 05:28 | <~Vornicus> | then I have a few things I need to figure out how to do. I suspect a significant amount of it is "you'll have to handle that semi-manually" though |
| 05:30 | <&McMartin> | That's true of a lot of stuff, really |
| 05:31 | <~Vornicus> | The big one that I think I'll need engine support for is "I have bridges that things need to go both under and over, depending on the thing" |
| 05:33 | <&McMartin> | Draw Priority. |
| 05:33 | <&McMartin> | There's a concept of "Depth" |
| 05:33 | <~Vornicus> | THank goodness. |
| 05:33 | <&McMartin> | And the background is multilayered itself. |
| 05:33 | <&McMartin> | I don't offhand remember which direction is "out" though |
| 05:34 | <&McMartin> | I think that's negative. |
| 05:34 | <&McMartin> | There is also a concept of backgrounds having layers. |
| 05:34 | <&McMartin> | So you can put two layers of background and have some objects above all and others between the two. |
| 05:39 | <~Vornicus> | All righty. |
| 05:41 | | * Vornicus tries to think. okay, buildings (with ducks in) are closer than the ducks, bridges are further than the ducks but closer than the gondola, docks are further than the gondola, roofs are closer than the gondola and don't get ducks on them. |
| 05:41 | <&McMartin> | Ah, going for Vorns Ahoy here? |
| 05:42 | <~Vornicus> | Yeah. |
| 05:42 | <~Vornicus> | Figured it'd be a decent start. It's got a few features I want to sort of figure out. |
| 05:42 | | * McMartin nods. |
| 05:56 | <~Vornicus> | Also it lets me happily ignore a lot of things that I'd need to do if I made anything bigger. |
| 05:57 | <&McMartin> | Heh. Always a plus, yes. |
| 05:58 | <&McMartin> | Have you run through the silly tutorial game? |
| 05:58 | <~Vornicus> | I did the "click the fruits" one and the "1942" one |
| 05:59 | <&McMartin> | OK |
| 05:59 | <&McMartin> | I thought the 1942 one did tricks with clouds or something, but maybe not |
| 06:00 | <~Vornicus> | It did islands. |
| 06:00 | <~Vornicus> | But not clouds. |
| 06:05 | <&McMartin> | Aha. |
| 06:16 | < celticminstrel> | The (minor) problem with doing 60fps is that that's not an integer number of milliseconds per frame... |
| 06:16 | | * Vornicus gives celmin his monitor, currently running at 85fps |
| 06:16 | < celticminstrel> | I kinda want to just stick with the ~66fps. |
| 06:17 | <~Vornicus> | 100 might work well too. |
| 06:17 | < celticminstrel> | Maybe...? That sounds a lot faster... |
| 06:18 | <~Vornicus> | 10 as opposed to 15 ms per frame. But you should try to make your timestep sensible in general, and I know some linuxes only have timer resolutions of 10ms |
| 06:18 | < celticminstrel> | 100 feels too fast. |
| 06:20 | <~Vornicus> | What kind of game is this anyway. |
| 06:20 | < celticminstrel> | It's a puzzle game. |
| 06:20 | <~Vornicus> | Oh. |
| 06:20 | <~Vornicus> | So, um |
| 06:21 | <~Vornicus> | of the following, in terms of behavior over time, which is it most like: Freecell, Minesweeper, Tetris. |
| 06:21 | < celticminstrel> | Um. I guess Tetris? |
| 06:21 | <~Vornicus> | So shit happens without the player? |
| 06:21 | <&McMartin> | Hrm. Apparently I am entitled to a free upgrade to Game Maker Studio. |
| 06:21 | < celticminstrel> | Yes. |
| 06:22 | <~Vornicus> | McM: I say take them up on it. |
| 06:23 | | Vash [Vash@Nightstar-e8057de2.wlfrct.sbcglobal.net] has quit [[NS] Quit: I lovecraft Vorn!] |
| 06:23 | <~Vornicus> | Okay. Is there a "physics"? Is it more like Angry Birds or Tetris? |
| 06:24 | <~Vornicus> | Do things happen in rigid moves, or is there realtime stuff happens. |
| 06:24 | < celticminstrel> | I'd say more like Angry Birds. There is a "physics" in the sense that objects interact with other objects according to a set of rules. |
| 06:25 | < celticminstrel> | There is stuff that happens without the player's input. |
| 06:25 | <~Vornicus> | I meant more |
| 06:25 | < celticminstrel> | More what? |
| 06:26 | <~Vornicus> | In Tetris, you have /occasional/ physics actions - the pieces fall in strictly-regimented rhythm, one block at a time. In Angry Birds, things happen smoothly. |
| 06:27 | < celticminstrel> | Ah. It's smooth in a graphical sense, but logically everything is on exactly one tile space. |
| 06:27 | <&McMartin> | "Upgrade Discount: $-198.00" |
| 06:27 | <&McMartin> | Works For Me |
| 06:27 | <~Vornicus> | okay, so you'll need fine-grained timesteps. |
| 06:28 | <~Vornicus> | Actually... will you? |
| 06:28 | < celticminstrel> | Hm? |
| 06:28 | <~Vornicus> | You could do this with a slow timestep and proper interpolation. |
| 06:29 | | Derakon is now known as Derakon[AFK] |
| 06:33 | | * celticminstrel is a bit confused now. |
| 06:33 | <&McMartin> | He'll still need a timestep for the *rendering* part. |
| 06:41 | < celticminstrel> | Okay? |
| 06:42 | | * McMartin installs GM:Studio |
| 06:43 | < celticminstrel> | Timestep is the 15ms, isn't it? |
| 06:43 | < celticminstrel> | I suppose I could double it and halve the number of frames between logical changes. |
| 06:45 | < celticminstrel> | It makes it feel only slightly faster. |
| 07:02 | | franny_ [fran@Nightstar-e67f9d08.com] has quit [Operation timed out] |
| 07:03 | <&McMartin> | Also, um |
| 07:03 | <&McMartin> | There is a lot of new stuff in GM Studio. |
| 07:04 | <&McMartin> | ...like Box2D support |
| 07:06 | | franny [fran@Nightstar-e67f9d08.com] has joined #code |
| 07:08 | | franny [fran@Nightstar-e67f9d08.com] has quit [Ping timeout: 121 seconds] |
| 07:09 | <&McMartin> | Oh right, now I remember, I also wanted to improve the animation sequence in Hex Inverter. |
| 07:17 | | You're now known as TheWatcher |
| 07:19 | | franny [fran@Nightstar-e67f9d08.com] has joined #code |
| 07:21 | | celticminstrel [celticminst@Nightstar-05d23b97.cable.rogers.com] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] |
| 07:25 | | iospacedout [Alexandria@Nightstar-e67f9d08.com] has quit [Connection closed] |
| 07:25 | | franny [fran@Nightstar-e67f9d08.com] has quit [Client closed the connection] |
| 07:26 | | franny [fran@Nightstar-e67f9d08.com] has joined #code |
| 07:30 | <&McMartin> | https://hkn.eecs.berkeley.edu/~mcmartin/games/HexInverter/ |
| 07:30 | <&McMartin> | I should probably put it in a Proper Web Page at some point instead of just a near-naked container, I guess. |
| 07:53 | | Kindamoody|movie is now known as Kindamoody |
| 07:58 | <&McMartin> | Oh, nice |
| 07:58 | <&McMartin> | Automatic integration with NSIS and a local SVN server for people who can't use git >_> |
| 08:02 | <&jerith> | McMartin: Stick it up on kongregate.com, get some money. :-) |
| 08:07 | <&McMartin> | Problematic given that I recruited other people to help in the expectation that this would not be commercial. |
| 08:31 | | Kindamoody is now known as Kindamoody|out |
| 08:33 | <&jerith> | It's not /very/ commercial. They money's from ads and donations. :-) |
| 08:33 | <&jerith> | Also, not an entirely serious suggestion. I believe there's nontrivial effort involved. |
| 08:35 | <&McMartin> | Also given that IIRC Derakon's time involvement here was about 20 minutes of Blender. ;) |
| 08:39 | <&jerith> | Dish out some of your untold wealth to your assistants. |
| 08:39 | <&jerith> | Or maybe just buy Derakon dinner at Tied House when you become a Free Internet Games Mogul. |
| 08:42 | | Rhamphoryncus [rhamph@Nightstar-5697f7e2.abhsia.telus.net] has quit [Client exited] |
| 08:47 | | * McMartin fiddles with the animation, gets it to look more like what he wanted. |
| 08:56 | <&McMartin> | https://hkn.eecs.berkeley.edu/~mcmartin/games/HexInverter/ |
| 09:04 | | RichyB [MyCatVerbs@Nightstar-3b2c2db2.bethere.co.uk] has joined #code |
| 09:04 | | * McMartin hands RichyB https://hkn.eecs.berkeley.edu/~mcmartin/games/HexInverter/ |
| 09:16 | < RichyB> | McMartin, you're using WebGL for rendering? Not Canvas2DContext? |
| 09:16 | < RichyB> | Neat! |
| 09:19 | <&McMartin> | Oh, is that WebGL? |
| 09:19 | <@rms> | Stupid AI is hard :/ |
| 09:19 | <&McMartin> | And no, I'm using Game Maker Studio, which has HTML5 output, which apparently includes WebGL~ |
| 09:20 | <&McMartin> | (Latest iteration of the Iji/Spelunky engine, which I learned this evening that I am entitled to a free copy of/upgrade to) |
| 09:20 | <&McMartin> | (So I got right on that~) |
| 09:21 | <&McMartin> | Brainless plays randomly, Beginner is just grabby for pieces which actually regularly loses to Random (yay Reversi tactics -_-) and Novice/Intermediate/Expert are minimax search AIs with varying depth. |
| 09:22 | <@Tamber> | That would probably explain why I was failing to see any pattern in Brainless' playing... (That's my excuse as to why it kicked my ass half the time, and I'm sticking to it.) |
| 09:23 | <@rms> | k, well Novice one just beats the shit out of me every time. |
| 09:30 | <@Tamber> | ...Nah, I'm just awful at it. :D |
| 10:48 | | Attilla [Obsolete@Nightstar-7cc45170.as43234.net] has joined #code |
| 11:12 | | Reiver [reiverta@5B433A.F67240.D8393C.A5A749] has joined #code |
| 11:12 | | Attilla [Obsolete@Nightstar-7cc45170.as43234.net] has quit [Ping timeout: 121 seconds] |
| 11:18 | | Attilla [Obsolete@Nightstar-b77d8fb5.as43234.net] has joined #code |
| 11:37 | | Attilla_ [Obsolete@Nightstar-b77d8fb5.as43234.net] has joined #code |
| 11:40 | | Attilla [Obsolete@Nightstar-b77d8fb5.as43234.net] has quit [Ping timeout: 121 seconds] |
| 11:49 | | Attilla_ [Obsolete@Nightstar-b77d8fb5.as43234.net] has quit [[NS] Quit: ] |
| 11:52 | | Attilla [Obsolete@Nightstar-b77d8fb5.as43234.net] has joined #code |
| 12:07 | | Attilla [Obsolete@Nightstar-b77d8fb5.as43234.net] has quit [Ping timeout: 121 seconds] |
| 12:10 | | iospace [Alexandria@Nightstar-e67f9d08.com] has joined #code |
| 12:14 | | Attilla [Obsolete@Nightstar-f63ed104.as43234.net] has joined #code |
| 13:02 | <@ToxicFrog> | McMartin: speaking of NSIS, have you played with InnoSetup at all? |
| 13:12 | | Attilla [Obsolete@Nightstar-f63ed104.as43234.net] has quit [Client closed the connection] |
| 13:22 | | Attilla [Obsolete@Nightstar-8afef565.as43234.net] has joined #code |
| 13:31 | | iospace is now known as io|gone |
| 14:19 | | gnolaptop [lenin@26ECB6.2F30FB.20776A.FAABC0] has joined #code |
| 14:57 | | io|gone is now known as iospace |
| 15:08 | | gnolaptop [lenin@26ECB6.2F30FB.20776A.FAABC0] has quit [[NS] Quit: Gone] |
| 15:27 | | Reiver [reiverta@5B433A.F67240.D8393C.A5A749] has quit [Connection reset by peer] |
| 15:27 | | cpux|2 [cpux@Nightstar-c5874a39.dyn.optonline.net] has joined #code |
| 15:30 | | cpux [cpux@Nightstar-c5874a39.dyn.optonline.net] has quit [Ping timeout: 121 seconds] |
| 16:31 | | celticminstrel [celticminst@Nightstar-05d23b97.cable.rogers.com] has joined #code |
| 17:33 | | himi [fow035@Nightstar-5d05bada.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 17:41 | | * iospace eyes her board |
| 17:41 | < iospace> | running at 75C |
| 17:41 | < iospace> | Dx |
| 17:41 | < iospace> | (which is within tolerance, but still hot) |
| 17:43 | | * iospace shuts it off and lets it cool for a bit |
| 17:46 | | himi [fow035@Nightstar-5d05bada.internode.on.net] has joined #code |
| 17:46 | | mode/#code [+o himi] by ChanServ |
| 17:47 | | * iospace also sets her fan to high |
| 17:47 | < celticminstrel> | What would you call a function that takes a range and a number and returns the closest number to the input number in the provided range? |
| 17:47 | < iospace> | hmm... |
| 17:47 | < iospace> | PlaceInRange? |
| 17:48 | < iospace> | or something like that |
| 17:55 | < iospace> | that work celticminstrel ? |
| 17:56 | <~Vornicus> | a "range" like what format is that? |
| 17:57 | < celticminstrel> | Min and max. |
| 17:57 | < celticminstrel> | And yes, that basic form works. |
| 17:58 | <~Vornicus> | "clamp" |
| 17:58 | < celticminstrel> | Hm. That might be even better. |
| 18:02 | <~Vornicus> | and it's min(hi,max(lo,x)) |
| 18:04 | < celticminstrel> | I actually did it with comparisons. |
| 18:04 | < celticminstrel> | Though I imagine it probably works out the same. |
| 18:05 | < celticminstrel> | Return max if x > max, min if x < min, else x. |
| 18:06 | | * rms would call it clamp too |
| 18:07 | < celticminstrel> | I decided "minmax" was a bad name for it. :P |
| 18:07 | < celticminstrel> | Especially since that name is apparently already used in... I think <algorithm>... for something slightly different. |
| 18:07 | <@rms> | Either that or: correct, sanitizeNumber, restrict |
| 18:10 | < celticminstrel> | Heh, Xcode's jump-to fails for methods on template arguments. |
| 18:10 | < celticminstrel> | Obviously I wouldn't expect it to automatically jump to the right one, since it can't know, but it shouldn't just happily jump to the wrong one either. |
| 18:11 | < celticminstrel> | ...I always get confused when I see a lack of error messages on using cerr/clog/cout in a file without <iostream> included. |
| 18:18 | | Vash [Vash@Nightstar-e8057de2.wlfrct.sbcglobal.net] has joined #code |
| 18:18 | | mode/#code [+o Vash] by ChanServ |
| 18:48 | | Rhamphoryncus [rhamph@Nightstar-5697f7e2.abhsia.telus.net] has joined #code |
| 19:08 | | Kindamoody|out is now known as Kindamoody |
| 19:16 | < Tarinaky> | http://markshroyer.com/2012/06/c-both-true-and-false/ |
| 19:20 | | * Vornicus fiddles with game maker |
| 19:24 | < celticminstrel> | Nice. |
| 19:26 | < gnolam> | Tarinaky: I wish I wasn't distracted by his choice of spacing, but... urgh. So ugly. |
| 19:32 | < Tarinaky> | Lol. |
| 19:32 | < Tarinaky> | The tldr is an unitialised bool is both true and false. |
| 19:32 | < Tarinaky> | (In some compilers) |
| 19:43 | | Vash [Vash@Nightstar-e8057de2.wlfrct.sbcglobal.net] has quit [Client closed the connection] |
| 19:43 | | Vash [Vash@Nightstar-e8057de2.wlfrct.sbcglobal.net] has joined #code |
| 19:43 | | mode/#code [+o Vash] by ChanServ |
| 19:48 | < RichyB> | celticminstrel, "clamp" is used all over e.g. OpenGL for exactly the operation that you specify. |
| 19:48 | < RichyB> | So it's a good choice. |
| 19:49 | | Kindamoody is now known as Kindamoody[zZz] |
| 19:49 | < RichyB> | celticminstrel, "min-max" is a (outline of a class of) algorithm(s) for searching a tree of possible moves in a turn-based game. |
| 19:50 | < RichyB> | Specifically, minimax. |
| 19:50 | < RichyB> | http://en.wikipedia.org/wiki/Minimax |
| 19:53 | <~Vornicus> | Okay it looks like I use "tiles" to generate backgrounds with depth. |
| 20:15 | <&McMartin> | ToxicFrog: I haven't used InnoSetup because I've been an expert at NSIS for over 10 years now and I've never liked the end results of InnoSetup enough when other people used it. |
| 20:18 | <~Vornicus> | Next up I have to figure out how the gondola moves. |
| 20:27 | <@TheWatcher> | The gondola stays where it is, the universe moves around it~ |
| 20:28 | <~Vornicus> | Heh |
| 20:32 | <~Vornicus> | More seriously, the gondola's movement is... restricted. |
| 20:36 | <~Vornicus> | if you're not pushing the dpad, the gondola will continue slowly along its path, except if it's within range of one of the piers in which case it moves toward that and then stops at the pier; pushing in one of the two directions that the canal follows will make the gondola move quickly in that direction... pushing perpendicularly will instead make it move quickly towards the nearest path in that |
| 20:36 | <~Vornicus> | direction. |
| 20:41 | | * Vornicus fires up the game to see if he can figure out the full ruleset. |
| 20:50 | < Rhamphoryncus> | ahaha, that true-and-false thing is great |
| 20:52 | <~Vornicus> | okay. reaching a corner where you cannot go straight, you try turning right, and if that doesn't work you'll turn left, and in the case of a dead end (only at the beach) you'll stop. |
| 20:58 | <~Vornicus> | now, to see if I can figure out how to actually do this. |
| 20:59 | <&jerith> | Carefully. |
| 20:59 | <&jerith> | With magic. |
| 20:59 | <&jerith> | And SCIENCE! |
| 21:00 | <~Vornicus> | Clearly |
| 21:02 | < Rhamphoryncus> | eeergh. The true-and-false thing is funny. This is excruciatingly painful. http://blog.regehr.org/archives/593 and what it says about CERT's IntegerLib |
| 21:03 | < Rhamphoryncus> | "Let's make a lib so you can avoid undefined integer behaviour.. what do you mean -INT_MIN is undefined?! |
| 21:21 | | * Vornicus examines this, determines he needs to actually put in some data |
| 21:21 | | * Vornicus is not sure what precisely the data should look like though |
| 21:46 | <~Vornicus> | I want to say paths, but I'm not sure. |
| 21:50 | <~Vornicus> | Yeah, paths feels like the right kind of thing I want here. |
| 21:50 | <&McMartin> | If you've got a physics, timelines, otherwise paths |
| 21:50 | <&McMartin> | Also, "Check for object" is your friend |
| 21:50 | <&McMartin> | There are some cunning tricks you can do with that but mostly that's for platformers |
| 21:51 | <~Vornicus> | It's... |
| 21:51 | <~Vornicus> | gneh, I don't know how to put it. |
| 21:51 | <&McMartin> | ("Am I mid-jump and about to collide with a climbable wall", etc) |
| 21:52 | <~Vornicus> | I'm pretty sure I want paths, but the transitions are still befuddling me. |
| 21:52 | <&McMartin> | I've actually never used paths |
| 21:53 | <~Vornicus> | Basically I have a grid system that's the places the gondola can go. |
| 21:57 | <~Vornicus> | I think I want each piece of the grid to be its own path but then I have to connect the paths |
| 21:57 | <&McMartin> | Is the gondola machine-controlled? |
| 21:57 | <~Vornicus> | and I'm not sure where I can store the connection data |
| 21:57 | <~Vornicus> | The gondola is human controlled. |
| 21:57 | <~Vornicus> | But it sticks to the canals. |
| 21:57 | <&McMartin> | Ah, so the motion is forward/back? |
| 21:57 | <&McMartin> | Isn't there a path_speed variable or some such? |
| 21:57 | <~Vornicus> | I think there is, yes |
| 21:58 | <&McMartin> | Isn't there also a "Path Completed" event? |
| 22:00 | <~Vornicus> | Other - End of Path, yes |
| 22:00 | <&McMartin> | Can you use that to link the paths together? |
| 22:00 | <~Vornicus> | Like set the gondola to be on a different path? Sure, but then all my path connections are hard coded. I'd far prefer some data. |
| 22:02 | <~Vornicus> | and right now I have no idea where I can put data like that. |
| 22:02 | <&McMartin> | Mmm |
| 22:02 | <&McMartin> | That's one of the things GM is bad at. |
| 22:03 | <&McMartin> | Tabular data generally, really. |
| 22:03 | <&McMartin> | I tended to use autogenerated GML to load it up into scripts |
| 22:05 | <~Vornicus> | Right now I can see that I want "a path goes between two nodes, and the nodes can have data on them like "automatically stop here |
| 22:05 | < Rhamphoryncus> | Hrm. Is terrain really self-similar at different levels? Yes, you can make decent terrain that way, but it seems to me that it's just a subset of what real terrain does |
| 22:06 | <&McMartin> | I'd go with a script that fires on path end and that does stuff based on which path ended and which direction you were going. |
| 22:07 | <~Vornicus> | That was approximately the plan for the code, yeah |
| 22:08 | <&McMartin> | That's probably going to involve some Science though |
| 22:08 | <&McMartin> | Also, GM:Studio changed a whole bunch of stuff |
| 22:09 | <&McMartin> | There's a new class of Draw event that's viewport independent \o/ |
| 22:09 | <&McMartin> | That's only been needed since Day 1. |
| 22:10 | <~Vornicus> | Yeah, I saw that in the feed when I opened GM the other day and was like "that... wasn't there before?" |
| 22:10 | <~Vornicus> | followed by "for shame!" |
| 22:10 | <&McMartin> | Well, the way you handle that is honestly fairly trivial |
| 22:11 | <&McMartin> | You generally need an invisible object to keep track of global game state anyway |
| 22:11 | <&McMartin> | So you have it follow the viewport and give it a draw event and you're golden. |
| 22:11 | <&McMartin> | Also you can have viewports be a subset of the screen as of some version or other so you can do that too, IIRC. |
| 22:20 | | iospace is now known as io|gone |
| 22:21 | < Rhamphoryncus> | Aha, I think I've got it. A coastline *is* self-similar, but it's a result of natural processes (tiny water flows combining into every larger water flows), and that doesn't necessarily match the mandelbrot set or any simple mathematical form |
| 22:22 | < Rhamphoryncus> | (indeed, to be realistic I could do generating of terrain heights at subtle levels, then derive rivers from that) |
| 22:22 | <~Vornicus> | Landscapes can be self-similar but there's a lot of limits to scales of certain objects |
| 22:22 | <~Vornicus> | I mean you won't find streams below a certain size, nor will you find caverns above a certain size. |
| 22:23 | < Rhamphoryncus> | "Most coastlines are self-similar, that is they show he same kind of detail at different scales." <-- I'd say they have similar kinds of detail, but not the same |
| 22:24 | < Rhamphoryncus> | http://fractalfoundation.org/OFC/OFC-9-4.html shows 5 zoom levels. The z-variation is non-fractal :P |
| 22:25 | < Rhamphoryncus> | Maybe if you could trace the coastline in each (the x/y plane) you'd be able to see actual fractal behaviour |
| 22:27 | < Rhamphoryncus> | http://fractalfoundation.org/images/photo/3250592201/mediterranean-italy-alps.ht ml is the mountain fractal due to altitude or water flow? |
| 22:27 | <~Vornicus> | That's water flow |
| 22:28 | < Rhamphoryncus> | *nod* |
| 22:28 | < Rhamphoryncus> | Which is all consequence so useless to high quality terrain generation |
| 22:29 | <~Vornicus> | Well, the snow cover is water flow; the mountains themselves have a fractal pattern but that's not what you see in white there |
| 22:30 | < Rhamphoryncus> | yeah |
| 22:36 | < Rhamphoryncus> | This is a mountain with similar things at different levels, but with a hefty amount of striation: http://classes.yale.edu/fractals/panorama/nature/MountainsReal/Mountains1.gif |
| 23:19 | | You're now known as TheWatcher[T-2] |
| 23:21 | | * Vornicus finishes up his 19 paths, realizes he screwed up and needs another 12. |
| 23:23 | | You're now known as TheWatcher[zZzZ] |
| 23:52 | | KiMo [Kindamoody@Nightstar-05577424.tbcn.telia.com] has joined #code |
| 23:52 | | mode/#code [+o KiMo] by ChanServ |
| 23:53 | | Kindamoody[zZz] [Kindamoody@Nightstar-05577424.tbcn.telia.com] has quit [Ping timeout: 121 seconds] |
| --- Log closed Thu Jun 28 00:00:48 2012 |