#exult@irc.freenode.net logs for 11 Mar 2002 (GMT)

Archive Today Yesterday Tomorrow
Exult homepage

[00:01:16] <Kirben> hmm permission denied
[00:03:03] <Kirben> I think you might need to chmod g+w the directory
[00:03:19] <Dominus> ups
[00:03:20] <Dominus> oops
[00:03:37] <Kirben> oops make that chmod -R g+w
[00:04:21] <Dominus> done
[00:06:13] <Kirben> all uploaded and links are working
[00:06:39] <Kirben> Why the double // in new links though ?
[00:06:54] <Dominus> aehm, just noticed myself
[00:06:54] <Kirben> ie http://exult.sourceforge.net/snapshots//pentagram/Pentagram.zip
[00:07:04] <Dominus> changing in a moment
[00:09:09] <Dominus> ok, works now
[00:09:50] <Dominus> I#m deleting the ones in /snapshot now
[00:16:41] <Dominus> how many snapshots are you actually doing? I noticed you on the ScummVM as well
[00:18:27] <Kirben> 3 projects
[00:18:49] <Dominus> what do you do on the WinUA project?
[00:19:51] <Kirben> oh I just setup that sourceforge site for another developer.
[00:20:12] <matto> WinUAE ?
[00:20:32] <matto> hehe.. oh yeah, Kirben is idling in #scummvm now
[00:20:53] <Dominus> I see (I just did a check on our developers on what projects they are memebrs :-) (sneaky little bastard, he)
[00:21:22] <Dominus> is scummvm on openprojects as well?
[00:21:29] <Kirben> yes
[00:21:29] <matto> yeah
[00:21:34] <matto> and guess who is on the auto-op list?
[00:21:49] <Kirben> http://scummvm.sourceforge.net/ or http://sourceforge.net/projects/scummvm/
[00:22:26] <Dominus> Yeah, I just looked and saw that The Dig is getting more compatibel :-)
[00:22:47] <matto> as long as D.O.T.T. works.. that's all that matters :)
[00:36:42] <Dominus> time for bed
[00:36:44] <Dominus> bye
[00:36:48] <-- Dominus has left IRC ("Exult! Exult! Exult!")
[00:58:42] --> recca has joined #exult
[01:15:37] <-- kefka has left IRC (Read error: 104 (Connection reset by peer))
[02:23:55] --> kefka has joined #exult
[03:17:36] <-- matto has left IRC ("Play Dragon's Lair in linux - http://www.daphne-emu.com - Developers welcome :)")
[07:48:47] --> Kirben2 has joined #exult
[07:50:47] <-- Kirben has left IRC (Read error: 104 (Connection reset by peer))
[08:06:17] <-- kefka has left IRC (Read error: 104 (Connection reset by peer))
[08:06:23] --> kefka has joined #exult
[08:57:13] <-- Kirben2 has left IRC ("System Meltdown")
[09:05:30] --> Xavier` has joined #exult
[09:10:30] --> Kirben has joined #exult
[09:10:31] --- ChanServ gives channel operator status to Kirben
[09:17:19] <Kirben> ?seen wjp
[09:17:19] <exultbot> wjp left IRC around Sun Mar 10 22:28:59 2002 (GMT) ("[x]chat")
[09:22:19] --> wjp has joined #exult
[09:22:19] --- ChanServ gives channel operator status to wjp
[09:22:22] <wjp> you rang? :-)
[09:23:55] <wjp> Kirben: were you looking for me for anything in particular?
[09:24:35] <Kirben> Xavier` was asking about your bot...
[09:26:08] * wjp nods
[09:29:38] <wjp> I should go get some breakfast
[09:29:42] <wjp> bye
[09:31:47] <-- wjp has left IRC ("[x]chat")
[10:29:09] --> matto has joined #exult
[10:37:28] <-- matto has left IRC ("installing new drivers")
[11:06:40] <-- Kirben has left IRC (Read error: 104 (Connection reset by peer))
[11:09:15] --> Fingolfin has joined #exult
[11:12:59] --> Kirben has joined #exult
[11:12:59] --- ChanServ gives channel operator status to Kirben
[11:43:08] --> matto has joined #exult
[11:51:08] <-- Kirben has left IRC (Read error: 104 (Connection reset by peer))
[11:55:23] --> Kirben has joined #exult
[11:55:23] --- ChanServ gives channel operator status to Kirben
[11:56:27] --> Colourless has joined #Exult
[11:56:41] --- ChanServ gives channel operator status to Colourless
[11:56:42] <Colourless> hi
[11:57:19] <Kirben> Hi
[11:58:47] <Fingolfin> yo
[11:58:54] --- ChanServ gives channel operator status to Fingolfin
[12:03:19] <-- matto has left IRC ("Play Dragon's Lair in linux - http://www.daphne-emu.com - Developers welcome :)")
[12:03:46] --> matto has joined #exult
[13:34:47] <Colourless> ah hahaha :-)
[13:34:56] * Colourless waits for someone to respond
[13:36:57] <Fingolfin> hu?
[13:37:08] * Fingolfin just returned to his keyboard, in time, it seems
[13:37:27] <Colourless> nothing. just breaking the silence :-)
[13:38:46] <Fingolfin> dang =)
[13:40:52] <Colourless> plus making the signal to noise ratio that much worse, plus i'm attempting to have more said that on the 9th!
[13:41:04] <Colourless> s/that/than/
[13:41:47] <Fingolfin> tsk tsk
[13:41:56] <Fingolfin> how is that reflecting on us now, then=
[13:41:57] <Fingolfin> ?
[13:42:16] <Colourless> you know, i couldn't care less :-)
[13:42:18] <Fingolfin> we should rather discuss how a possible pentagram rendering engine/flow could work =)
[13:42:21] <Fingolfin> hehe
[13:42:59] <Colourless> we 'could' do such a thing
[13:43:50] <Colourless> i know how i 'would' like for it to be done.... almost nothing like exult :-)
[13:44:08] <Colourless> at least the program design itself would look nothing like exult :-)
[13:44:12] <Colourless> no huge monolithic classes aka Game_window :-)
[13:44:22] <Fingolfin> heheh
[13:44:42] <Fingolfin> for example, it should be from the beginning possible to add in different scalers
[13:44:54] <Colourless> yeah
[13:44:57] <Fingolfin> and yeah, everything should be put into neat, *small and managable* classes =)
[13:45:06] <Fingolfin> well, small in the sense: not doing to much, at least
[13:45:48] <Colourless> yeah, each class should have a small number of clearly defined functions
[13:46:33] <Fingolfin> there are two way to approach this: 1) from the implementation POV, or 2) from the usage POV. I.e. 1) how could it work internally, and 2) how would I want to be able to call stuff, to get Actor/Game_object etc. classes working nicely
[13:48:47] <Colourless> object managment is going to be one of that more difficult things. expecially when attempting to save the usecode state since usecode processes could be active
[13:48:57] <Fingolfin> right
[13:49:21] <Colourless> they will mostly likely be using some object references
[13:49:36] <Fingolfin> the Usecode interpreter(s) (multiple since U8 uses threaded usecode?), could need a StreamToFile method, which just saves the full state to disk
[13:50:21] <Colourless> yeah, that would need to be done
[13:50:45] <Fingolfin> but, how would an object "render itself" , i.e.: request to be update/just draw itself/notify some "display manager"/mark itself as dirty/...
[13:51:20] <Colourless> that is something i've been thinking of a lot
[13:51:25] <Colourless> there has to be a display manager
[13:52:01] <Colourless> this is used to figure out the rendering order, and used to detect where object was clicked by the mouse
[13:52:04] <Fingolfin> ok, let's call it DisplayManager. A singleton, I figure? I.e. only a single instance ever
[13:52:18] <Colourless> yeah, 1 instance
[13:52:39] <Fingolfin> ok. how would clicks be handled? Should all gameobjects have a "mouse_click" callback?
[13:52:56] <Fingolfin> which would do one thing for gumps, and another for "normal" objects, maybe.
[13:53:32] <Colourless> well, as far as I know, most clicks, other than for gumps, would get passed to the usecode interpreter
[13:53:35] <Fingolfin> and, when is the "rendering" done. Do we just periodically tell the DisplayManager to update the screen as it sees fit?
[13:54:37] <Colourless> well, ideally, due to my obsession with interpolation, rendering is done every time the program loops
[13:54:48] <Colourless> let me explain how i would do things
[13:54:55] <Fingolfin> that'd be fine for (with a FPS limiter, optional)
[13:54:59] * Fingolfin listens
[13:55:47] <Colourless> there is a fps limiter. from experimentation 20 Hz seems to be ultima 8's animation rate
[13:59:15] <Colourless> Ok firstly, there is the DisplayManager class. This would obviously interface with the ObjectManager manager somehow to get all the objects when the screen needs to be refreshed.
[14:00:52] <Colourless> each object would include some rendering informations
[14:01:42] <Colourless> this information is used for interpolating the objects smoothly
[14:02:36] <Colourless> these would include the position on screen the object was last drawn at, the last position in the world the object was at
[14:04:05] <Colourless> it would also include the position of where the object is supposed to be in the world
[14:04:18] <Colourless> the reason for this is so the world itself can run independant of the renderer
[14:04:33] <Colourless> the world would be run at a strict 20 Hz rate
[14:05:56] <Colourless> the renderer would hopefully run much faster
[14:06:25] <Colourless> anyway, after the world has been run, the display manager would update every world object to ensure that the rendering information is all correct.
[14:07:18] <Colourless> this would pretty much just be updating the objects previous positions
[14:08:02] * Colourless think it would be much easier to write an example in code
[14:08:19] <Fingolfin> ok. question: if the world runs on 20hz, what does it gain us to run the renderer faster?
[14:08:26] <Colourless> interpolation
[14:08:29] <Colourless> looks smoother
[14:08:31] <Fingolfin> Colourless: yeah, why not, just write the stuff, even if it is not doing anything =)
[14:08:35] <Colourless> isn't a jump
[14:08:39] <Fingolfin> hmmm
[14:08:43] <Colourless> isn't as jumpy
[14:09:04] <Fingolfin> but how can we interpolate if we don't know the new object positions yet?
[14:09:21] <Colourless> you introduce latency
[14:10:20] <Colourless> you bascially say that an object only gets to it's current position when we next update the world
[14:12:59] <Colourless> so we update an object at time t, and we assume that takes 1 time unit to actually get to it
[14:12:59] <Colourless> 's \new location
[14:13:02] <Fingolfin> hm, ok
[14:13:06] * Colourless hopes that made sense
[14:13:17] <Fingolfin> since we run at 20hz, that wouldn't be a big issue to the user, I guess
[14:13:33] <Fingolfin> although I once read that users get nervous on delays bigger than 200ms =)
[14:13:56] <Colourless> don't mention the latency
[14:14:20] <Colourless> as long as the mouse doesn't have latency they really wont notice
[14:14:44] <Colourless> input handling can be done instantly if required
[14:18:20] <Colourless> it's very easy to make the interoplation a switchable options, but i really doubt anyone would turn it off.
[14:18:38] <Colourless> smooth scrolling is an automatic benefit
[14:19:35] <Colourless> i'll design a small example of what i'll do. it's quite simple really
[14:20:39] <-- Kirben has left IRC (Read error: 104 (Connection reset by peer))
[14:21:11] <Fingolfin> Colourless: go ahead =)
[14:21:39] <Fingolfin> it wouldn#t hurt either to add any code to CVS, even if it is not yet working, or not even compileable, just so that we can see it, and add our own ideas
[14:21:42] <Fingolfin> we = wjp and me, I guess =)
[14:21:54] <Colourless> yeah
[14:22:33] <Colourless> will do
[14:26:28] <Fingolfin> cool!
[14:27:22] * Colourless thinks this will take a few day... putting ideas into code always seems to take longer than expected
[14:37:07] <Fingolfin> =)
[14:37:40] <Fingolfin> that is partly because sometimes when one writes down great ideas, they suddenly aren't as great anymore because some unexpected real world problem turn up =)
[14:40:56] <Colourless> :-)
[15:34:48] <-- Colourless has left IRC ("a")
[15:38:59] <-- Fingolfin has left IRC ("42")
[16:13:45] --> wjp has joined #exult
[16:13:47] --- ChanServ gives channel operator status to wjp
[16:13:58] <wjp> hi
[17:30:32] <-- kefka has left IRC (capek.openprojects.net irc.openprojects.net)
[17:30:32] <-- Xavier` has left IRC (capek.openprojects.net irc.openprojects.net)
[17:30:32] <-- matto has left IRC (capek.openprojects.net irc.openprojects.net)
[17:30:32] <-- recca has left IRC (capek.openprojects.net irc.openprojects.net)
[17:30:32] <-- wjp has left IRC (capek.openprojects.net irc.openprojects.net)
[17:36:59] --> wjp has joined #exult
[17:36:59] --> matto has joined #exult
[17:36:59] --> Xavier` has joined #exult
[17:36:59] --> kefka has joined #exult
[17:36:59] --> recca has joined #exult
[22:08:06] <-- recca has left IRC ("leaving")
[22:53:02] <-- wjp has left IRC ("Zzzz....")