#pentagram@irc.freenode.net logs for 2 Jul 2003 (GMT)

Archive Today Yesterday Tomorrow
Pentagram homepage

[01:56:03] --> DraX has joined #pentagram
[02:08:51] <-- DraX has left IRC ("bye? ..(sph)")
[02:12:37] --> Kirben has joined #pentagram
[02:12:37] --- ChanServ gives channel operator status to Kirben
[04:56:19] <-- Kirben has left IRC (Read error: 110 (Connection timed out))
[06:29:52] <-- DarkeZzz has left IRC (sterling.freenode.net irc.freenode.net)
[06:33:51] --> DarkeZzz has joined #pentagram
[07:37:43] --> Kirben has joined #pentagram
[11:29:25] --> Kirben2 has joined #pentagram
[11:29:26] <-- Kirben has left IRC (Read error: 104 (Connection reset by peer))
[11:32:24] --- Kirben2 is now known as Kirben
[13:21:46] --> Colourless has joined #Pentagram
[13:21:46] --- ChanServ gives channel operator status to Colourless
[13:22:12] <Colourless> hi
[13:22:26] <Colourless> wjp: i've found out how exactly the fading worked in u8... and it's most interesting
[13:22:31] <Colourless> it also explains the trans.xmi file :-)
[13:25:30] <Colourless> quite simply, trans.xmi actually does exist. It's a multitraked xmi file. It's index 258 in music.flx
[13:25:41] <Colourless> (or index 260 if using a fm synth)
[13:26:15] <Colourless> the numbers in the transition info relate specifiy which track of trans.xmi to play
[13:26:49] <Colourless> if there is an ! before the transition number, the track from trans.xmi is meant to be played at the same time as the old song.
[13:27:55] <Colourless> due to the way AIL XMI worked, and the way trans.xmi is constructed (the fade tracks purely contain expression controllers), trans.xmi would cause the old music to fade out
[13:28:09] <Colourless> this, is actually pretty easy to replicate, and i'm busy doing it here
[13:29:27] <Colourless> if there is no ! before the number then instantly change from old to new. Or if the number is non zero, subtract 1 from the number, and then stop the old music and play the track from trans.xmi
[13:29:35] <Colourless> overall, pretty simple stuff
[13:30:44] <Colourless> above that should have been 'if there is no ! before the number and the number is zero'
[13:35:07] <Colourless> also index 0 of music.flx is called 'generic.nim'
[13:40:30] <Colourless> something interesting: the combat -> normal music transition is actually the little bit of music that plays when you leave combat
[14:31:33] --> wjp has joined #pentagram
[14:31:33] --- ChanServ gives channel operator status to wjp
[14:31:38] <wjp> Colourless: very interesting
[14:31:46] <Colourless> hi
[14:31:50] <wjp> hi :-)
[14:32:15] <wjp> how are you progressing with the audio system?
[14:32:52] <Colourless> i'll pretty much have midi 'done' in a few hours
[14:33:21] <Colourless> that is 'done' as in all the framework in place, ready for people to make/steal drivers
[14:33:51] <wjp> any work on SFX?
[14:34:04] <Colourless> nope
[14:34:22] <wjp> what needs to be saved for the music, btw?
[14:34:38] <Colourless> that... is an interesting question :-)
[14:34:41] <wjp> just current track?
[14:34:47] <wjp> or something more complicated? :-)
[14:34:57] <Colourless> ok, it depends on 2 things
[14:35:06] <Colourless> or more specfically 1 thing
[14:35:18] <Colourless> whether cacheIn() is called after loading save games
[14:35:30] <wjp> I would say no
[14:35:37] <Colourless> now, as far as I can tell, the answer to that is, no, it should only be called on map change
[14:36:01] <wjp> I'm trying to make saving/loading cause no side-effects whatsoever
[14:36:16] <Colourless> so, what needs saving then... well, I'm going to be creating a MusicProcess
[14:36:53] <Colourless> and that will probably handle the saving of the the current track
[14:37:31] <Colourless> upon recreation of the MusicProcess it will restart the song
[14:39:20] <wjp> quick english language question: is the use of "can't" (as opposed to "cannot") acceptable in semi-formal written english?
[14:39:58] <Colourless> i don't really know
[14:42:57] <Colourless> using cannot would probably be better
[14:52:35] <wjp> hm, did U8 have any lockable containers you could carry with you?
[14:52:52] <Colourless> don't think so
[14:53:02] <Colourless> only chests were lockable IIRC
[14:53:18] <wjp> and should a recursive search recurse into locked chests?
[14:54:29] <Colourless> I have no idea. I would think not, but that would require that the engine knew what a locked chest was
[14:55:14] <wjp> bbl
[15:14:35] <wjp> b
[15:14:41] <Colourless> wb :-)
[15:14:45] <wjp> and gone again :-)
[15:14:53] <-- wjp has left IRC ("going home")
[15:24:58] <-- Kirben has left IRC (Read error: 54 (Connection reset by peer))
[15:49:58] --> wjp has joined #pentagram
[15:49:58] --- ChanServ gives channel operator status to wjp
[15:50:18] <wjp> b
[15:50:38] <Colourless> wb
[15:50:43] <wjp> thanks
[16:17:23] <wjp> weird effect... if you switch maps after loading, it "merges" the current map and the new map :-)
[16:17:55] <Colourless> hmm
[16:18:07] <wjp> (I don't save nonfixed items from other maps yet)
[16:18:38] <wjp> so the teleportToEgg should probably be failing
[16:18:45] <wjp> (there's no target egg)
[16:19:55] <wjp> weird
[16:20:52] <wjp> it shouldn't ever have fixed items from two maps in memory at once
[16:21:08] <Colourless> probably isn't deleteing from one
[16:21:39] <wjp> but CurrentMap is wiped clean on switchMap
[16:22:47] <wjp> ah well, I'll just continue implementing things :-)
[16:23:27] <wjp> maybe a mapnum isn't being saved/loaded properly somewhere
[16:24:08] <wjp> yes... I don't restore CurrentMap yet, so it doesn't have a pointer to its Map
[16:24:35] <wjp> and writeback conveniently starts with "if (!current_map) return;" :-)
[16:24:46] <Colourless> :-)
[16:25:52] <wjp> so... just need to save/load Map items and everything should be working except that processes get killed
[16:26:01] <wjp> (killed = not saved :-) )
[16:39:13] <wjp> some silly object stats: 60 Actors, 9 Containers, 15 Eggs, 875 GlobEggs, 20013 Items, 1 MainActor, 13 MonsterEggs, 3 TeleportEggs
[16:39:21] <wjp> (map 3)
[16:39:23] <Colourless> :-)
[16:39:39] <wjp> (I added a #define to have 't' output this)
[16:39:53] <wjp> those runtime classtypes are really nice :-)
[16:40:15] <Colourless> they have their uses :-)
[16:40:52] <wjp> did the same for processes, but that isn't as interesting :-)
[16:41:13] <wjp> there's *drumroll*: 1 CameraProcess, 1 EggHatcherProcess! :-)
[16:41:27] <Colourless> you should include gumps too :-)
[16:41:37] <wjp> gumps are included too
[16:41:46] <wjp> (automatically since they're objects)
[16:42:13] <wjp> e.g., I get 13 ButtonWidgets when I 'look' at the Avatar
[16:42:52] <Colourless> ah neat
[16:43:03] <wjp> what the...
[16:43:11] <wjp> I get a 'degrees' symbol when I type two slashes
[16:43:18] <Colourless> where?
[16:43:34] <wjp> in emacs
[16:43:45] <Colourless> hmm...
[16:44:02] * Colourless thinks you turned on some option unwittingly
[16:44:04] <wjp> some kind of i18n thingie, probably
[16:44:07] <wjp> yes, probably :-)
[16:44:22] <wjp> gone after a restart
[16:44:52] <Colourless> it sucks when a restart doesn't fix a 'problem' cause it's saved with the programs settings :-)
[16:45:41] <wjp> emacs doesn't really save any settings unless you do that explicitly
[17:01:50] <wjp> bbl, dinner
[17:01:54] <Colourless> k
[17:21:44] <wjp> back
[17:21:48] <Colourless> wb
[17:22:05] <wjp> th
[17:22:06] <wjp> x
[17:42:24] <wjp> ok, things look a lot better after saving/loading the current map number :-)
[17:42:42] <wjp> now when you switch maps you switch to the right (but very empty) map
[18:08:07] <wjp> ok, other maps are stored now too
[18:08:12] <wjp> savegame size increased to 1.5Mb
[18:08:33] <wjp> zipped 262Kb
[18:24:48] <wjp> if I don't save in-glob items, it becomes 780Kb, and 115Kb zipped
[18:25:10] <wjp> (apparently in-glob items don't compress as good as other items? :-) )
[18:25:30] <wjp> do you think it's worth it to "creatively" save glob items?
[18:25:50] <Colourless> can they be deleted?
[18:25:51] <wjp> (save only the objids of the items, or something like that)
[18:26:02] <Colourless> they can't can they
[18:26:10] <wjp> no
[18:26:27] <Colourless> well, this is a 'hacky' way to save them then.
[18:26:40] <Colourless> the objid's will be sequential when being created
[18:27:01] <Colourless> so all you need to do is store the first one (which in theory would actually be the objid of the globegg +1)
[18:27:02] <wjp> not necessarily
[18:27:09] <wjp> there's objid 666...
[18:27:23] <Colourless> hmm, true
[18:27:25] <wjp> and if loaded in a second map you can't be sure what'll happen
[18:27:46] <Colourless> you could just store all the obj ids if you wanted
[18:28:18] <Colourless> that should substantially reduce the size of the savegames
[18:29:32] <wjp> any changes to glob items would be cancelled, though
[18:29:48] <Colourless> that shouldn't really happen anyway though
[18:29:49] <wjp> we could 'really' save any glob items in the fastarea
[18:29:57] <wjp> and reconstruct the ones outside
[18:30:16] <Colourless> yes possible
[18:30:37] <wjp> that way you at least won't get any visible changes :-)
[18:31:12] <wjp> I get about 860Kb, 130Kb zipped that way
[18:31:23] <wjp> quite acceptable, IMHO
[18:31:23] <Colourless> much better
[18:31:39] <wjp> anyway, something for later :-)
[18:31:57] <wjp> first want to get the rest of saving working before I start getting "creative" :-)
[19:19:34] <wjp> you mentioned something about an objecttype/processtype "registry", where objects/processes would store load functions
[19:20:01] <Colourless> yes just the other dat infact
[19:20:12] <Colourless> s/dat/day/
[19:20:35] <wjp> which day is the other day? :-)
[19:20:42] <Colourless> something as simple as a std::map would be the most obvious way to do it
[19:21:04] <wjp> any idea on how to populate it?
[19:21:12] <Colourless> ye... no idea
[19:21:14] <Colourless> :-)
[19:21:23] <Colourless> seriously i don't really know
[19:22:04] <wjp> I can think of some pretty ugly hacks involving static member objects with constructors, but that might depend on construction order
[19:22:17] <Colourless> yeah, not nice to do those sorts of things
[19:23:08] <wjp> then we'd probably need "something" to be aware of all process/object classes
[19:24:45] <Colourless> hmm. i can think of a not 'too' nasty hack using constructors
[19:25:19] <Colourless> use a linked list. and each constructor add it's object to the bottom of the list
[19:25:49] <Colourless> so you'd do something like next = list; list = this;
[19:26:13] <wjp> yeah, that occured to me too
[19:26:24] <wjp> you'd just need to make sure it was 0 at the start
[19:26:29] <Colourless> and that is not hard
[19:26:51] <wjp> it isn't?
[19:27:09] <Colourless> SomeType *some_global = 0;
[19:27:32] <Colourless> or if using a class
[19:27:36] <wjp> hm, POD is guaranteed to be initialized before static constructors?
[19:28:17] <Colourless> initialized variables are stored in the initialized data segement
[19:28:44] <wjp> is that guaranteed or just the case on any platforms we know? :-)
[19:29:46] <Colourless> my assumption, yes it would be like that on all platforms.
[19:29:54] <Colourless> of course i don't know for sure
[19:30:09] <Colourless> i'm sure the C++ specs might say something
[19:30:49] <wjp> I'm reading the relevant chapter of Stroustrup atm
[19:33:03] <Colourless> The following initializations take place prior to entry to main:
[19:33:04] <Colourless> Default initialization of static data to zero. All static data without explicit initializers are set to zero prior to executing any other code, including run-time initialization. Static data members must still be explicitly defined.
[19:33:04] <Colourless> Initialization of global static objects in a translation unit. This may occur either before entry to main or before the first use of any function or object in the object's translation unit.
[19:34:04] <wjp> yes... that "translation unit" part is rather annoying
[19:34:39] <wjp> if I understand it correctly, it basically says that you can't be sure any static member of a class is initialized until the class is actually used
[19:34:47] <Colourless> yeah
[19:34:56] <Colourless> something like that is my understanding
[19:34:59] <wjp> making sure something is zero the first time can be done with a static in a function, btw
[19:35:54] <wjp> T* setRoot(T* x) { static T* y = 0; y = x; return y; }
[19:35:55] <wjp> or something
[19:36:21] <Colourless> hmm, so it could
[19:37:26] <Colourless> of course, even if all that is done, i wouldn't say i'd be too impressed that we were using such hacks
[19:37:46] <wjp> me neither :-)
[19:37:59] <wjp> impressed with getting everything to work, maybe, but not impressed to be actually using it :-)
[19:39:13] <Colourless> my opinion, just have a function that has lots of 'loaderRegistry'->addLoadFunction("SomeClassName", SomeClassName->load); or whatever
[19:40:48] <wjp> I don't particularly want to add a 'load' function to every class, btw
[19:41:00] <wjp> could probably be templated:
[19:41:07] <wjp> T* newobject = new T();
[19:41:10] <wjp> newobject->loaddata(ids);
[19:41:38] <wjp> (loaddata() just loads the data into the already existing object, and calls the superclass' loaddata() function)
[19:47:25] <-- DarkeZzz has left IRC (sterling.freenode.net irc.freenode.net)
[19:47:35] --> DarkeZzz has joined #pentagram
[19:48:11] <-- DarkeZzz has left IRC (sterling.freenode.net irc.freenode.net)
[19:48:34] --> DarkeZzz has joined #pentagram
[19:49:27] <-- exultbot has left IRC (signing off...)
[19:51:33] --> exultbot has joined #pentagram
[19:51:33] --- Topic for #pentagram is: http://pentagram.sf.net/
[19:51:33] --- Topic for #pentagram set by wjp at Fri Jun 27 16:03:52 2003
[19:53:28] --> DarkeZzz has joined #pentagram
[19:54:40] <wjp> _some_ structure would be nice ;-)
[19:54:43] <wjp> but other than that, no
[19:55:15] <wjp> feel free to make subdirs as you see fit
[19:57:38] <Colourless> i'm thinking probably just a midi_drivers directory, for now
[19:57:51] * wjp nods
[19:58:32] <wjp> I'm not overly enthusiastic about the name "midi_drivers" for a directory; it's a bit longish
[19:58:49] <wjp> no real objections, though :-)
[20:00:28] <Colourless> i would partially agree. it is a bit long
[20:02:06] <Colourless> but then what to use instead. drivers perhaps? drivers/midi ? :-) of course IMO, the digital sound should also be somewhat abstracted with different drivers possible (even though there may only be 1 driver)
[20:03:07] * wjp hmms
[20:04:13] <Colourless> of course we could always just shove it all into audio
[20:04:39] <wjp> how about just midi?
[20:04:49] <Colourless> audio/midi?
[20:04:57] <wjp> might be somewhat confusing since there will probably be midi files in audio itself :-)
[20:04:59] * wjp nods
[20:05:03] <Colourless> i can do that
[20:05:55] <wjp> how many midi-related but non-driver cpp files do you have?
[20:07:15] <Colourless> i have 18 files. 5 of them are directly driver related. 4 of them are MusicFlex.cpp/h and MusicProcess.cpp/h
[20:07:41] <Colourless> the rest of them are all XMidi*.cpp/h. What was once all shoved into 2 files, i split up into multiple files
[20:07:53] <Colourless> 1 file, 1 class
[20:08:33] <wjp> how about MusicFlex/Process into audio/, XMidi.*, drivers into audio/midi?
[20:08:52] <Colourless> yes, i was thinking that. it seems... best
[20:40:04] <Colourless> ok committed it all
[20:40:34] * wjp wonders if he dares to update :-)
[20:40:54] <Colourless> reality is, i haven't changed much in pentagram :-)
[20:41:04] <wjp> oh, FLG_DISPOSABLE is implemented now, btw :-)
[20:41:12] <wjp> (in my copy, that is)
[20:41:25] <Colourless> well that's not cvs is it :-)
[20:44:50] <wjp> hm, time for some stealthy excursions into scummvm's CVS, I guess :-)
[20:45:29] <Colourless> *cough* http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/scummvm/scummvm/backends/midi/ *cough*
[20:46:39] <wjp> "Pentagram-cvs post from colourles@users.sourceforge.net requires approval" :-)
[20:46:52] <Colourless> :-)
[20:47:06] <Colourless> i'm guessing that's the audio/midi commit
[20:47:08] <Colourless> mail
[20:47:14] <wjp> indeed :-)
[20:48:23] <wjp> just one conflict
[20:48:50] <wjp> heh... I added a 'class ObjectManager;' to GUIApp.h. You added a 'class MidiDriver;' :-)
[20:49:00] <Colourless> :-)
[20:52:38] <Colourless> oh no, not blank line at the end of MusicProcess.h
[20:52:49] <wjp> *gasps* NO!
[20:54:49] * wjp tinkers with some makefiles
[20:57:14] <wjp> audio/midi/XMidiSequence.cpp:130: warning: suggest parentheses around
[20:57:14] <wjp> assignment used as truth value
[20:57:18] <wjp> (and again on 151)
[20:57:53] <wjp> and GUIApp is complaining about "invalid use of undefined type `struct MidiDriver'"
[20:58:12] <wjp> include MidiDriver.h I guess
[20:58:15] <Colourless> yeah
[20:58:33] <wjp> ah, you don't get that because of the WindowsMidiDriver.h
[20:59:12] <Colourless> the 2 XMidiSequence warnings, do as it says, put parentheses around them and maybe at != 0 or something too
[21:01:20] <wjp> ok, things compile
[21:01:42] <wjp> just one minor issue... I can't commit the changes because I have too many local changes :-)
[21:02:07] <wjp> I guess that means I'll have to finish saving quickly :-)
[21:02:21] <Colourless> ah well i've better be going
[21:02:24] <Colourless> cya
[21:02:25] <wjp> night
[21:02:27] <-- Colourless has left IRC ("casts invisibility")
[23:09:41] --> Fingolfin has joined #pentagram
[23:09:41] --- ChanServ gives channel operator status to Fingolfin
[23:09:50] <wjp> or we can talk in here :-)
[23:09:54] <Fingolfin> BTW it is a pity one cannot due "make graphics" anymore
[23:10:18] <wjp> well, you can, but there are no executables there
[23:10:20] <Fingolfin> I see no good fix for it, except for assuming that "make graphics" is meant to compile all .cpp files in graphics/
[23:10:39] <wjp> but that wouldn't do much good
[23:10:42] <Fingolfin> I can type "make graphics", and it will do nothing at all (which is correct, of course, but not the expected thing, IMHO)
[23:10:53] <Fingolfin> well it's not that I mind much...
[23:11:14] <Fingolfin> but I wonder what is the point in keeping the code which allows one to do "make graphics", or why keep the Makefil in graphcs/ at all..
[23:11:58] <wjp> good question
[23:12:20] <wjp> it does make sense for directories containing executables
[23:13:15] <Fingolfin> does it? wouldn't it make more sense to allow only "make EXECUTABLE" ? don't get me wrong, i use directory specific building a lot, but the form it is done in pentagram right now seems pretty pointless..
[23:14:02] <Fingolfin> in ScummVM I often do "make scumm/libscumm.a" and am considering adding shortcuts (i.e. "make scumm" in this case), because e.g. I might have made some change to a global header, and I only want to compile stuff in scumm/, not the whole other shebang, to see if my modification worked, etc.
[23:14:22] <Fingolfin> kernel/GUIApp.cpp: In member function `void GUIApp::startup()':
[23:14:22] <Fingolfin> kernel/GUIApp.cpp:118: error: `initMidiDriver' undeclared (first use this
[23:14:22] <Fingolfin> function)
[23:14:39] <wjp> you need to #include "MidiDriver.h"
[23:15:29] <Fingolfin> indeed I just saw
[23:16:11] <wjp> ok, just committed updated objects.mk/module.mk
[23:16:25] <Fingolfin> hm, CoreAudioMidiDriver
[23:26:17] <Fingolfin> uh, namespace problem
[23:26:34] <Fingolfin> of `struct Rect'
[23:26:34] <Fingolfin> misc/Rect.h:22: error: previous definition of `struct Rect'
[23:26:45] <Fingolfin> err
[23:26:46] <Fingolfin> /System/Library/Frameworks/CoreServices.framework/Headers/../Frameworks/CarbonCore.framework/Headers/MacTypes.h:443: error: redefinition
[23:26:46] <Fingolfin> of `struct Rect'
[23:26:46] <Fingolfin> misc/Rect.h:22: error: previous definition of `struct Rect'
[23:27:06] * wjp hmms
[23:27:25] <Fingolfin> in ScummVm we put Rect and Point into ScummVM namespace, because actually lots of OSes define those
[23:27:36] <wjp> yeah... not a bad idea :-)
[23:31:41] <Fingolfin> but what namespace would we use? Pentagram?
[23:31:46] * wjp nods
[23:31:48] <wjp> I guess
[23:32:47] <Fingolfin> well changing it later would be rather trivial I guess
[23:32:52] <Fingolfin> so I'll go for that now
[23:33:39] <Fingolfin> BTW...
[23:33:39] <Fingolfin> struct Rect {
[23:33:39] <Fingolfin> // DO NOT Manually Set these!
[23:33:48] <wjp> don't know why :-)
[23:33:54] <Fingolfin> -> err, so, why not just use a class and make those vars protected/private? :-)
[23:43:58] <wjp> rather annoying my soundcard doesn't have a hardware midi synthesizer
[23:50:46] <wjp> ugh.. nearly 2am already...
[23:50:51] * wjp should really be going
[23:50:55] <wjp> night
[23:51:12] <-- wjp has left IRC ("Zzzz...")