[02:30:01] --> Kirben has joined #pentagram
[02:30:01] --- ChanServ gives channel operator status to Kirben
[08:28:46] <-- Kirben has left IRC ("System Meltdown")
[08:34:11] --> Kirben has joined #pentagram
[08:34:11] --- ChanServ gives channel operator status to Kirben
[09:00:09] <-- DarkeZzz has left IRC (brunner.freenode.net irc.freenode.net)
[09:01:31] --> DarkeZzz has joined #pentagram
[09:01:31] --- ChanServ removes channel operator status from DarkeZzz
[11:47:47] --> Cashman has joined #pentagram
[12:51:09] <Cashman> how are you going Kirben?
[12:53:02] <Kirben> Going well.
[12:53:22] <Cashman> nice to hear
[14:25:13] <Cashman> eh gtg
[14:25:22] --- Cashman is now known as CashZzz
[14:25:46] <-- CashZzz has left IRC ()
[15:18:37] <-- Kirben has left IRC (Read error: 54 (Connection reset by peer))
[16:47:01] --> Colourless has joined #Pentagram
[16:47:04] --- ChanServ gives channel operator status to Colourless
[17:04:25] --> wjp has joined #pentagram
[17:04:25] --- ChanServ gives channel operator status to wjp
[17:06:03] <wjp> I wonder why I'm handling this un-expanding of globeggs so complexly
[17:06:14] <wjp> it would probably be much easier to just 'forget' to write back the EXT_INGLOB items
[17:06:41] <wjp> OTOH, I'm pretty sure I came up with that idea last night too, but apparantly I rejected it for some weird reason
[17:10:02] <Colourless> :-)
[17:10:12] <Colourless> i haven't looked much at the code yet
[17:10:29] <wjp> it's nothing special
[17:10:47] <wjp> while loading items from a Map into CurrentMap it expands globeggs
[17:11:01] <Colourless> when you are talking about write back, what do you actually mean?
[17:11:01] <wjp> and while writing them back from CurrentMap to Map it un-expands them again
[17:11:22] <wjp> write back from the object lists in CurrentMap to those in Map
[17:11:39] <wjp> (mainly the nonfixed items)
[17:24:47] <wjp> bbl, dinner
[17:24:47] <Colourless> k
[17:44:12] <wjp> b
[17:44:17] <Colourless> wb
[18:40:53] <wjp> right... so, what's next? :-)
[18:41:12] <Colourless> gumps... :-)
[18:41:16] <wjp> basic timing, gumps+event handling, rendering
[18:41:18] * wjp nods
[18:41:42] <Colourless> well, maybe not quite yet for gumps
[18:41:59] <Colourless> timing + basic event handing needs to be set up first
[18:42:20] <Colourless> we really do need to get some framework in place to actually receive events from sdl in a decent manner
[18:42:41] <wjp> yes :-)
[18:44:04] <wjp> hm, how do we combine event handling with the kernel?
[18:44:16] <wjp> do we handle events at a given time in a single tick?
[18:44:28] <Colourless> good question, i honestly don't really know
[18:44:31] <wjp> or semi-continuously handle them between processes?
[18:44:48] <Colourless> it depends on exactly how things are setup to work
[18:45:12] <Colourless> 'most' input wont matter if it's got 50 ms latency
[18:45:38] <Colourless> what we need to think about though, is single and double click detection
[18:45:50] <wjp> yes, that's a bit of an issue
[18:46:14] <wjp> we need to delay handling a click until we know it isn't a double click, I guess
[18:46:15] <Colourless> the original game my memory tells me added a rather excessive amount of latency to input handling
[18:47:26] <wjp> I can't really remember noticing it
[18:47:51] <wjp> (or maybe I just attributed it to a slow PC)
[18:48:11] <Colourless> if we do add latency for double click detection, we should have a double click speed slider in a config gump somewhere
[18:48:18] * wjp nods
[18:48:35] <wjp> or maybe even a way to change double clicks to middle mouse or something
[18:48:41] <wjp> (and remove the delay altogether)
[18:48:50] <Colourless> well we need double left and double right
[18:49:00] * wjp thinks
[18:49:02] <Colourless> double right was used in combat IIRC
[18:49:03] <wjp> what did double right do?
[18:49:09] <wjp> oh, kicking or something?
[18:49:13] <wjp> (or was it blocking?)
[18:49:25] <Colourless> kicking
[18:49:29] <Colourless> i 'think'
[18:49:43] <Colourless> for blocking i think you held left
[18:50:16] <Colourless> yes
[18:50:20] <Colourless> manual agrees
[18:50:32] <wjp> :-)
[18:50:52] <Colourless> heh, manual says double right click on avatar will activate combat mode
[18:51:29] <wjp> I don't think I ever used (or knew) that :-)
[18:52:05] <Colourless> neither did i
[18:52:07] <wjp> hm, so we'll need to detect click-and-hold too
[18:52:22] <wjp> (for other purposes than only dragging)
[18:52:25] <Colourless> dragging items will be interesting :-)
[18:52:35] <wjp> yes... :-)
[18:53:42] <wjp> can you manipulate (look, move, use) items while in combat mode?
[18:53:53] <wjp> I guess you can at least use your inventory?
[18:54:01] <Colourless> can't remember exactly what you could do
[18:55:11] <Colourless> no you can't drag items in combat mode
[18:55:56] <Colourless> when dragging items, the world i'm pretty sure was stopped.
[18:56:11] <wjp> interesting
[18:56:31] <Colourless> also when view scrolls and books
[18:56:39] <wjp> stopping the world shouldn't be too much of a problem, luckily
[18:56:52] <Colourless> no it shouldn't
[18:58:25] <Colourless> IMO, event handling should be done as soon as new events are detected. this is to help ensure the mouse cursor is updated quickly
[18:58:55] <wjp> so go into an event loop between any two processes?
[18:59:06] <Colourless> yes
[18:59:25] <wjp> means changing the kernel API a bit
[18:59:27] <Colourless> probably do it right before/after rendering
[18:59:42] <Colourless> wouldn't think the kernel would need any changing
[18:59:47] <-- DarkeZzz has left IRC (brunner.freenode.net irc.freenode.net)
[19:00:18] --> DarkeZzz has joined #pentagram
[19:00:45] <wjp> hm, rendering will have to be done multiple times per tick too?
[19:00:50] <Colourless> why do you think it would?
[19:00:57] <Colourless> yes rendering was going to be done multiple times per tick
[19:01:03] <Colourless> hence the interpolation code
[19:01:38] <wjp> any idea how many ticks/s there are/should be?
[19:01:52] <Colourless> 20 Hz seems to be the correct rate
[19:02:17] <wjp> we'd have to do some dynamic 'scheduling' of the renderer during a tick, I guess
[19:02:32] <Colourless> explain
[19:02:48] <wjp> to make sure we don't render too often
[19:03:07] <wjp> (but I haven't really thought this through properly yet, so I may not be making much sense :-) )
[19:03:13] <Colourless> rendering too often usually isn't a problem :-)
[19:03:25] <wjp> it is if it slows things down
[19:03:56] <Colourless> ah, thats why the rendering interval is dynamic
[19:04:26] <wjp> k, that's kind of what I meant with 'dynamic scheduling' :-)
[19:04:30] <Colourless> i see
[19:05:08] <Colourless> you render as many times as you can, and no more as you want to prevent slow down
[19:05:15] <wjp> anyway, why I thought the kernel API might need some modifications: I was thinking to separate the 'run process', 'handle events', and 'render' functions
[19:05:36] <Colourless> everything is always kept on track with a strict timing system
[19:06:16] <wjp> is the ~10ms resolution provided by SDL enough?
[19:06:22] <wjp> should be, right?
[19:06:34] <Colourless> welll 20 Hz is 50 Ms so it's fine
[19:07:28] <Colourless> as long as over all the timing is accurate than it's fine. it one tick is 40 ms and the next is 60 ms then it doesn't really matter
[19:08:22] <Colourless> here in windows sdl is giving me way better than 10ms resolution
[19:08:53] <Colourless> of course the windows port of sdl includeds a high resolution timer :-)
[19:11:25] <wjp> not sure about the resolution here
[19:12:15] <Colourless> lets just say this, if sdl doesn't give you a resolution sufficent for 20 Hz timing, then it would be a useless api for timing games :-)
[19:12:21] <wjp> :-)
[19:24:32] <Colourless> i should be going
[19:24:33] <Colourless> cya
[19:24:34] <-- Colourless has left IRC ("casts invisibility")
[20:17:02] --> Fingolfin has joined #pentagram
[20:17:03] --- ChanServ gives channel operator status to Fingolfin
[20:17:09] <Fingolfin> wjp: not that I am much in here either =)
[20:17:23] <wjp> yikes, Fingolfin is following me :-)
[20:17:27] * Fingolfin still waits for Apple GCC update to fix the internal compiler error <sigh>
[20:19:41] <Fingolfin> wjp: channels
[20:20:02] <wjp> Fingolfin: annoying
[20:32:05] <DarkeZzz> (doubleclick) IIRC we concluded before that any events had a latency of one tick into the next frame to handle double clicks and such. Which seems a little excessive, IMO. *grin*
[20:32:58] <wjp> 50ms isn't that much for a double click, is it?
[20:34:56] * DarkeZzz has most of his mouse slides on 'most sensitive', so probably not for most people no. *grin* Even then, two clicks within a tenth of a second is probably about as fast as he can get anyway. *grin*
[20:36:13] <DarkeZzz> Anyvay... work calls. Bye!
[20:36:17] <wjp> bye
[20:54:13] <-- wjp has left IRC ("Zzzz...")
[21:07:12] <-- Fingolfin has left #pentagram ()