#pentagram@irc.freenode.net logs for 20 Sep 2002 (GMT)

Archive Today Yesterday Tomorrow
Pentagram homepage

[14:35:42] --> wjp has joined #pentagram
[14:35:42] --- ChanServ gives channel operator status to wjp
[14:35:47] <-- wjp has left #pentagram ()
[14:38:57] --> Colourless has joined #pentagram
[14:38:57] --- ChanServ gives channel operator status to Colourless
[14:39:17] <Colourless> Take that wjp!
[14:39:38] --> wjp has joined #pentagram
[14:39:39] --- ChanServ gives channel operator status to wjp
[14:59:01] <wjp> you know... we should start committing some code for pentagram sometime soon :-)
[14:59:58] <Colourless> well what do you have to commit? :-)
[15:00:13] <wjp> nothing yet :-)
[15:00:20] <wjp> writing some code first might be a good idea too :-)
[15:00:48] <Colourless> darke and I both have 'stuff' in the works
[15:00:54] <wjp> I know :-)
[15:01:00] <wjp> that's why I used 'committing' instead of 'writing' :-)
[15:01:53] <Colourless> what i've got isn't entirely ready to be committed though. not only is it not yet finished to a state i am happy with, it also needs to be cleaned up a bit before it can be committed
[15:02:14] <wjp> you're working on the renderer, right?
[15:02:23] <wjp> what exactly is Darke doing? something usecode related, I guess? :-)
[15:04:30] <Colourless> Yeah i'm working on parts of the renderer. Actually I have no idea what exactly darke is doing. Some usecode stuff afaik, and some misc other things too.
[15:09:24] * wjp wonders if he should start writing on some of the basic 'support' systems
[15:09:36] <wjp> the 'FileSystem' class or something
[15:10:11] <Colourless> i think darke was working on that :-)
[15:10:23] <Colourless> but yes, those sorts of things need to be done
[15:10:25] <wjp> that was kind of what I was afraid of :-)
[15:12:55] <wjp> hmm... any other roughly 'independent' systems?
[15:13:33] <Colourless> config, but i was going to make a few changes to that myself
[15:13:49] <wjp> one thing I'd like for config is the ability to read multiple files
[15:14:01] <wjp> (e.g., system-wide config, user config)
[15:14:20] <Colourless> how exactly would that work?
[15:14:34] <wjp> one way that might work:
[15:15:04] <wjp> files are loaded in order, with values from newer files overriding older files. All changes are written back to the last file
[15:15:18] <Colourless> yeah
[15:15:21] <Colourless> simple enough
[15:16:24] <Colourless> i actually wanted to change config so that the writing of changes was actually delayed and did not occur when the settings were actually changed
[15:16:33] * wjp nods
[15:16:37] <wjp> sounds reasonable
[15:16:44] <wjp> although it might be annoying in the case of crashes
[15:17:10] <wjp> (not that we're going to have any of those, of course ;-) )
[15:17:26] <Colourless> but it would also prevent pentagram from making changes to the config that are going to cause pentagram to become unrunnable
[15:18:03] <wjp> you mean when a settings change causes an immediate crash?
[15:18:05] <Colourless> for instance someone changes the screen resolution to something they can't use.
[15:18:10] <wjp> yeah
[15:18:36] <wjp> we could do some semi-clever 'failure-detection' to detect when pentagram fails to start
[15:18:46] <wjp> but that might just be annoying
[15:19:41] <wjp> (I mean to revert settings back to some default in case of 'broken' settings)
[15:20:05] <Colourless> sounds reasonable
[15:21:02] <Colourless> getting it to work reliably might be interesting
[15:21:09] <wjp> yes :-)
[15:21:39] <wjp> easiest way would probably to set a flag immediately on startup, and clear it when we're really running (whenever that is)
[15:22:00] <wjp> (flag could be a config setting, file, whatever)
[15:22:55] <Colourless> i think though that ideally we'd want the reverting to be an optional thing
[15:23:06] <wjp> very true :-)
[15:23:21] <wjp> I _really_ don't want pentagram to decide to change my config file on its own :-)
[15:23:44] <Colourless> perhaps if the failure is detected we start pentagram up in a 'safe mode' and notify the user of a problem
[15:23:49] * wjp nods
[15:24:13] <wjp> PentagramOS :-)
[15:24:50] * Colourless has an evil grin
[15:25:07] <wjp> file systems, input handlers, output handlers, safe mode... uh oh :-)
[15:25:19] <wjp> oh, and 'The Registry'? ;-)
[15:25:26] <Colourless> threads, processses, kernel's
[15:25:39] <Colourless> config will act sort of like 'The Registry' :-)
[15:26:10] <Colourless> a 'windowing system' (aka gumps)
[15:27:12] <wjp> oh, btw, something else that occured to me some time ago:
[15:27:28] <wjp> we were kind of planning to make some non-usecode things processes, too, right?
[15:27:37] <Colourless> yeah some
[15:27:53] <wjp> but usecode is cooperatively multithreaded
[15:28:15] <Colourless> yeah. they are just things that are designed to be run at a certain time
[15:28:31] <Colourless> certain time being every game tick
[15:28:51] <wjp> is usecode guarenteed to 'yield' every tick?
[15:28:52] <Colourless> it's then upto each 'c++' process what exactly it would do each frame
[15:29:08] <wjp> or we might have to do some kind of hybrid scheduler
[15:29:47] <wjp> (i.e., it does pre-emptive multithreading, but keeps scheduling the same usecode, until it yields, or something like that)
[15:29:57] <wjp> of course, that might be overkill :-)
[15:30:15] <wjp> although the idea of making usecode processes pre-emptible might be nice :-)
[15:30:16] <Colourless> here is a C++ process that i've got in a program here in a test program:
[15:30:16] <Colourless> class AnimateProcess : public PentagramProcess
[15:30:16] <Colourless> {
[15:30:16] <Colourless> public:
[15:30:17] <Colourless> AnimateProcess() : PentagramProcess()
[15:30:17] <Colourless> {
[15:30:19] <Colourless> }
[15:30:21] <Colourless> virtual bool Process(uint32 ticks, uint32 framenum)
[15:30:23] <Colourless> {
[15:30:25] <Colourless> leg_frame++;
[15:30:27] <Colourless> if (leg_frame > 106) leg_frame = 91;
[15:30:29] <Colourless> if (crouch && leg_frame > 79) leg_frame = 70;
[15:30:31] <Colourless> return true;
[15:30:33] <Colourless> }
[15:30:35] <Colourless> virtual ~AnimateProcess() { }
[15:30:37] <Colourless> };
[15:30:39] <Colourless> AnimateProcess animator;
[15:31:05] <Colourless> it might also be a real pain in the ass as it would probably break things no end :-)
[15:31:15] <wjp> most likely, yes :-)
[15:31:29] <wjp> I guess we can assume usecode processes are 'well-behaved'
[15:31:36] <wjp> (in that they won't run too long)
[15:32:05] <Colourless> yes, it's a reasonably assumption
[15:32:16] <Colourless> s/bly/ble/
[16:34:15] <-- Colourless has left IRC ("cough cough")