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

Archive Today Yesterday Tomorrow
Pentagram homepage


[02:09:26] --> Kirben has joined #pentagram
[02:09:26] --- ChanServ gives channel operator status to Kirben
[07:43:43] --> DraX has joined #Pentagram
[07:44:32] <-- DraX has left IRC (Client Quit)
[11:19:12] --> Cashman has joined #pentagram
[11:24:09] --> Fingolfin has joined #pentagram
[11:24:09] --- ChanServ gives channel operator status to Fingolfin
[11:24:21] <Cashman> hi
[11:24:40] <Fingolfin> yo
[11:25:44] <Cashman> nice to see things comming along
[11:25:50] <Cashman> how you going?
[11:32:40] --> wjp has joined #pentagram
[11:32:40] --- ChanServ gives channel operator status to wjp
[11:32:41] <wjp> hi
[11:33:04] <Cashman> hey!
[11:36:15] <Cashman> are you going to have a head ache of a time committing the save stuff?
[11:36:20] <Cashman> wrjp
[11:36:24] <Cashman> oops wjp
[11:37:24] <Fingolfin> hi willem
[11:37:38] <Fingolfin> Cashman: thanks am fine (sorry for the delay =)
[11:39:55] * Cashman shouldn't have looked up his own details from there! hehe
[11:47:18] <wjp> committing it won't really be a problem
[11:59:12] <Fingolfin> the problem would be more what other people (me, ryan) then would do, depening on whether the code works/compiles or not =)
[11:59:41] <Fingolfin> I mean, I am allowed to break CVS, it's normal for me etc., so everybody is used to it. But willem? hm
[12:00:17] <wjp> I think I'll delay committing a full week for testing ;-)
[12:02:48] <Cashman> ok
[12:04:50] --- Cashman is now known as CashZzz
[12:04:54] <-- CashZzz has left IRC ()
[13:00:59] --> Colourless has joined #Pentagram
[13:00:59] --- ChanServ gives channel operator status to Colourless
[13:01:21] <wjp> hi
[13:01:22] <Colourless> hi
[13:05:23] <Fingolfin> yo ryan
[13:24:19] <Colourless> since when has OBufferDataSource used a std::deque
[13:30:40] <Colourless> using a deque isn't exactly functionally equiv to simply writing strait to a buffer of bytes, especially since you can not do seeking (currently, if ever) and you can not easily get a pointer to the buffer of data. The later pretty much why you'd want OBufferDataSource in the first place
[13:30:52] <Colourless> s/strait/straight/
[13:36:39] <Colourless> hmm, seems that we never had a real OBufferDataSource.. and the one we added was made by Darke... bad Darke! It shouldn't be called OBufferDataSource if it doesn't use a buffer. ODequeDataSource yes, OBufferDataSource... NO!
[13:37:00] <Colourless> time to hack up fold
[13:38:37] <DarkeZzz> Hmm... I was going to say "That sounds a little insane... it's probably my fault."
[13:38:59] <Colourless> :-)
[13:45:35] * DarkeZzz will make vague threatening noises at Those Who Defile fold(tm), whenever he's awake enough to care next. Given he *finally* got the stupid selection criteria in today, he might get a chance to actually touch pentagram again tommorrow or something. *grin*
[13:48:24] <wjp> Colourless: I was wondering the same thing...
[13:48:44] <wjp> I have a nice hack in my SavegameWriter to dump a std::deque to file :-)
[13:52:05] <Colourless> having a 'real' OResizableDataSource would be useful
[13:52:26] * Colourless thinks he'll right one
[13:52:41] <wjp> you might want to write one too, while you're at it ;-P
[13:52:55] <Colourless> uh
[13:54:10] * DarkeZzz would certainly prefer it to a wrong one. *nodnod*
[13:55:38] <-- wjp has left IRC (Remote closed the connection)
[13:56:18] * DarkeZzz eeps! He caused wjp to flee with that horrible pun!
[13:56:29] <Colourless> :-)
[13:56:30] --> wjp has joined #pentagram
[13:56:30] --- ChanServ gives channel operator status to wjp
[13:56:37] * wjp pretends he didn't just kill xchat
[13:57:33] <wjp> anyway, bbl :-)
[13:57:34] <-- wjp has left IRC (Client Quit)
[14:05:01] <-- Fingolfin has left IRC ("42")
[14:17:01] --> wjp has joined #pentagram
[14:17:01] --- ChanServ gives channel operator status to wjp
[14:17:23] <wjp> back
[14:18:04] <Colourless> wb
[14:46:11] * DarkeZzz casts xkill on wjp's irc client, just for fun. *grin*
[14:55:27] --> Dark-Star has joined #pentagram
[14:59:46] <wjp> DarkeZzz: no thanks, I'm perfectly capable of killing my own irc client :-)
[15:07:10] <wjp> hey, I just managed to get that \\=degree thingie in emacs again
[15:07:39] <DarkeZzz> Impressive. *grin*
[15:12:09] <-- Kirben has left IRC (Read error: 104 (Connection reset by peer))
[15:22:22] <-- Dark-Star has left IRC ("bbl")
[15:52:15] --> Dark-Star has joined #pentagram
[15:56:52] <wjp> Colourless: how do I save floats? :-)
[15:56:59] <wjp> (PaletteFaderProcess)
[15:57:26] <Colourless> you... can't :-)
[15:57:42] <Colourless> ok, it's easy enough
[15:57:55] <Colourless> just cast a pointer to a float to a pointer to a uint32
[15:58:43] <Colourless> i.e. to ds->write4(*(uint32*)&some_float);
[15:58:55] <wjp> how portable is that?
[15:59:28] <Colourless> if the system doesn't use IEEE Single Precision floats.... then it's not worth supporting ;-)
[15:59:48] <wjp> what about endian issues?
[16:00:30] <Colourless> obviously floats can be little or big endian, and it should match the host platforms integer endian
[16:01:30] <Colourless> you should probably write a writef(float) method in ODataSource
[16:01:59] <Colourless> i've 'started' writing a more more portable readf() in IDataSource, but it doesn't quite work yet
[16:02:04] <Colourless> (you can look at it yourself)
[16:04:18] <wjp> in the meantime everything except PaletteFaderProcess, TargetProcess, TeleportToEggProcess is getting saved
[16:04:39] <wjp> and TargetProcess is not going to get saved
[16:04:46] <wjp> (not in its current state, anyway :-) )
[16:04:50] <Colourless> :-)
[16:05:06] <wjp> TeleportToEggProcess shouldn't be necessary, but I'll just save it anyway
[16:08:13] <wjp> oh, and there's AvatarMoverProcess too
[16:16:16] <wjp> bbl, dinner
[16:23:21] <Dark-Star> Why not save floats in a decimal representation? although it's not very 'nice', it should be quite portable this way...
[16:24:05] <Colourless> it doesn't take much thought to think of the problems with that
[16:24:50] <Colourless> the exponent of floats is +127 to - 128
[16:25:48] <Colourless> which would mean that if you were saving as a decimal representation you would require from 1 to about 130 bytes
[16:27:25] <Dark-Star> Colourless: how about the scientific notation, like 2.4298329489234e123? OK, it's not very acurate but maybe it's acurate enough for pentagram's needs?
[16:28:31] <Colourless> problem still is variable length, and it requries a large number of bytes
[16:29:26] <Colourless> the 'proper' way is to use frexp() to get the mantissa and exponent when saving and using ldexp() to recreate the float when loading
[16:29:59] <Dark-Star> sounds easy enough :)
[16:44:59] <Dark-Star> MSVC making trouble again...
[16:45:15] <Dark-Star> What does it mean when MSVC tells me "Error C3861: mciGetErrorString: identifier not found, even with argument-dependant lookup"?
[16:46:04] <Colourless> it means it can't find the mciGetErrorString function
[16:46:28] <Colourless> is that during compiling or linking?
[16:46:39] <Dark-Star> Colourless: Yeah, thought so much :) that's during compilation...
[16:46:54] <Colourless> compiling what?
[16:47:06] <Dark-Star> WindowsMidiDriver.cpp, line 94
[16:47:38] <Colourless> line 42 of WindowsMidiDriver.h, try removing #define MMNOMCI
[16:48:25] <Dark-Star> ok, works
[16:48:55] <Colourless> i should probably remove that line
[16:49:34] <Dark-Star> I already thought my MSVC installation was somehow screwed since I got the same error today with scummvm too...
[16:59:02] <wjp> back
[16:59:08] <Colourless> wb
[17:01:20] <wjp> hm, I think I'll use the readf() hack for writef() too
[17:07:29] <wjp> right, PaletteFaderProcess done too
[17:08:12] * wjp notices he missed another one :-(
[17:08:15] <wjp> ActorAnimProcess...
[17:17:20] <wjp> ok... time for some "stress-testing"... saving during the execution scene :-)
[17:17:44] <Colourless> :-)
[17:18:01] <wjp> ok, it works when I save while Rhyan is walking towards Darion :-)
[17:18:25] <wjp> saving during lightning works too
[17:18:30] <wjp> things are looking good :-)
[17:19:47] <wjp> hmm... memory usage goes up about 500Kb every time I load
[17:26:41] <wjp> Mismatched free() / delete / delete [] by 0x809EBBA: MusicFlex::loadSongInfo() (audio/MusicFlex.cpp:272)
[17:26:43] <wjp> tsk tsk :-)
[17:28:09] <wjp> also you shouldn't use SDL_Init to initialize things after the "main" SDL_Init is already called
[17:28:14] <wjp> use SDL_InitSubSystem for that
[17:29:14] <Colourless> ah ok
[17:29:54] <Colourless> uh. such an obvious one too :-)
[17:30:01] <wjp> hm.. valgrind is choking on SDL_OpenAudio
[17:30:23] <wjp> s/SDL/Mix/
[17:30:48] <wjp> valgrind: the `impossible' happened: Unhandled REPE case
[17:30:52] <wjp> Basic block ctr is approximately 107600000
[17:32:58] <wjp> hm, lots of invalid reads in CameraProcess::GetLerped after loading
[17:33:15] * wjp wonders what he's not saving
[17:34:58] <wjp> ah, last_framenum
[17:35:02] <wjp> I should probably zero that?
[17:35:20] <Colourless> where?
[17:35:30] <wjp> when loading CameraProcess
[17:35:52] <Colourless> yeah probably
[17:36:27] <Colourless> the thing is. really the framenum in GUIApp should be saved too, and then restored
[17:36:36] <wjp> yes
[17:37:01] <Colourless> so last_framenum would then be saved and restored too
[17:38:33] <wjp> does the same go for Item::last_setup?
[17:39:10] <Colourless> it could be set to 0
[17:39:16] <wjp> ok
[17:39:22] <wjp> that was what I was doing
[17:52:19] <wjp> hm, weird
[17:52:31] <wjp> apparently the item lists in CurrentMap are leaked
[17:54:00] <wjp> although valgrind does say they're "possibly" leaked
[17:55:18] <Colourless> they shouldn't be
[18:04:06] <wjp> ah, GameMapGump doesn't delete display_list
[18:13:57] <-- Colourless has left IRC ("bbl")
[18:15:08] <wjp> 200K of memory leaks left... *sigh*
[19:01:35] <wjp> ok, less than 4K of leaks left now
[19:02:56] <wjp> some of it is leaking ifstreams from ReadFile
[19:11:23] <wjp> right, all gone
[19:42:55] --> Colourless has joined #Pentagram
[19:42:57] --- ChanServ gives channel operator status to Colourless
[19:43:09] <wjp> wb
[19:47:36] <Colourless> thx
[19:50:13] <wjp> TODO: Gump::shape, compression, getting rid of glob items
[19:50:37] <Colourless> todo for who? :-)
[19:50:53] <wjp> for who wants to do it :-)
[19:51:05] <wjp> I'll do the glob items
[19:51:11] <Colourless> i was going to fixup the gump shape stuff
[19:51:35] <wjp> so that leaves compression for Darke :-)
[19:51:45] <wjp> didn't he mention having some time for pentagram this weekend? :-)
[19:52:12] <Colourless> :-)
[19:55:27] <wjp> I think I'll commit all this
[19:57:10] <Colourless> uh oh :-)
[19:57:17] <wjp> indeed :-)
[19:58:00] <Colourless> i'm thinking, perhaps we *should* have started with saving framework in place :-)
[19:58:33] <wjp> maybe :-)
[19:58:35] <wjp> too late now :-)
[20:01:02] <wjp> oh, and of course I forgot to re-enable midi :-)
[20:02:33] <wjp> ok... update if you dare ;-)
[20:02:49] <Colourless> i don't :-)
[20:04:32] <Colourless> not yet anyway
[20:05:40] <wjp> awww :-)
[20:06:37] <wjp> yikes, our activity dropped to 58.4% last week
[20:07:10] <wjp> I guess that's what you get when both of us are doing 'big' things :-)
[20:07:40] <Colourless> 58!
[20:07:50] <Colourless> shocking
[20:08:46] <wjp> it was 21 earlier
[20:13:16] <wjp> more TODO: savegame interface, save & check GameInfo
[20:13:36] <wjp> store game metadata
[20:14:24] <wjp> setup a proper place to store savegames
[20:14:54] <wjp> oh, one thing we might consider is caching the savegame descriptions in a separate file
[20:15:17] <wjp> opening the save screen in exult becomes _really_ slow with 200+ saves
[20:15:21] <Colourless> the original did that
[20:15:28] <wjp> yes :-)
[20:15:43] <wjp> I want to keep them in the saves too, btw
[20:16:09] <Colourless> would need some checks in place though to make sure the names were correct though
[20:16:25] <wjp> timestamp on the files?
[20:16:52] <wjp> s/on/of/
[20:16:52] <Colourless> we could try... to bad it's going to require system specific code
[20:17:40] <Colourless> we could *gasp* actually make the filenames the name of the save game ;-)
[20:17:55] <wjp> umm.. well.. uhh..
[20:18:08] <wjp> we could, yes :-)
[20:18:53] <Colourless> you've got to remember, if we want to do some fancy sorting of the savegame list, we are going to have to read data from them anyway
[20:20:03] <wjp> unless we cache metadata too :-)
[21:04:25] <wjp> what would be required to use timidity?
[21:04:40] <Colourless> me to do stuff :-)
[21:04:55] <Colourless> i'll add it.. tomorrow
[21:05:07] <wjp> ah, cool :-)
[21:05:24] <wjp> are you using it internally or through an external binary?
[21:05:56] <wjp> (if the latter is at all possible... transitions might be tricky, I would guess)
[21:06:00] <Colourless> i was just initially going to just add support for using sdl mixer
[21:06:16] <Colourless> re transitions... i have an idea of how to do it :-)
[21:06:41] <wjp> SDL_mixer only exports a 'play midi file' interface, right?
[21:07:00] <Colourless> yeah
[21:07:23] <wjp> I'm wondering how much work it would be to either use SDL_mixer's libtimidity, or timidity++ itself
[21:07:51] <Colourless> ideally, being able to do it using some other method would be nive
[21:07:55] <wjp> from my pretty-clueless-about-midi point of view, timidity's internals look quite similar to a MidiDriver
[21:09:26] <wjp> but that might be just because both use MIDI terminology :-)
[21:09:48] <Colourless> where can i get info about timidity++
[21:10:09] <wjp> good question
[21:10:21] <wjp> gentoo gives http://www.goice.co.jp/member/mo/timidity/ as the url
[21:10:42] <wjp> SDL_mixer's internal libtimidity is a lot more compact, AFAICT
[21:12:00] <wjp> there's a newer version than 2.11.3, btw
[21:12:14] <wjp> ah, but that's a beta
[21:13:42] <wjp> playmidi.h seems to contain most relevant structs/functions... (AFAICT...)
[21:14:19] <Colourless> SDL_Mixer uses very few functions
[21:14:32] <Colourless> (timidity.h)
[21:14:47] <wjp> yes
[21:14:53] <Colourless> what i want to know is how every fits together internally
[21:15:39] <wjp> the basic structure I've been able to find is: something from readmidi.c reads a midi file and produces a list of MidiEvents
[21:16:00] <wjp> PlaySome (in playmidi.c) plays enough of these to fill the buffer passed to it
[21:16:27] <Colourless> hmm, that is most useful to know
[21:17:07] <wjp> there are some huge sysex parsing functions in there
[21:17:19] <Colourless> sysex, we can ignore :-)
[21:17:41] <Colourless> pentagram's midis dont contain any sysex data :-)
[21:17:42] <wjp> great :-)
[21:17:47] <Colourless> s/pentagram/ultima8/
[21:18:32] <Colourless> if you follow code 'well' enough
[21:18:47] <wjp> (sysex stuff was in timidity++, btw, not sdl_mixer)
[21:18:53] <Colourless> you can look at LowLevelMidiDriver::produceSamples() and you'll notice that it works in a somewhat similar fashion to Timidity_PlaySome
[21:19:27] <wjp> initalizied?
[21:19:35] <wjp> :-)
[21:19:46] <Colourless> eh, typos :-)
[21:19:53] <wjp> auto-complete? :-)
[21:20:05] <Colourless> no :-)
[21:20:12] <Colourless> find & replace :-)
[21:20:40] <Colourless> the var used to be is_available, but i didn't think that was quite correct
[21:20:48] <Colourless> so i just did a replace all
[21:21:03] <wjp> :-)
[21:21:37] <Colourless> i don't think it would be 'that' hard to adapt timidity to fit my LowLevelMidiDriver code
[21:22:47] <Colourless> most of Timidity_PlaySome would be shoved into TimidityMidiDriver::send()
[21:23:48] <Colourless> TimidityMidiDriver::lowLevelProduceSamples() would call compute_data
[21:24:37] <Colourless> it will need a few modifications though to the way things work
[21:25:04] <Colourless> cause timidity wants to know what instruments are needed before time
[21:29:01] <Colourless> how many mb does the timidty patches take up?
[21:29:14] <wjp> the ones with gentoo are about 25Mb
[21:29:47] <wjp> RH ships patches of about 10Mb
[21:29:54] <wjp> s/RH/RedHat/
[21:30:19] <Colourless> i *know* what RH is... i'm not an entirely clueless windows user
[21:30:36] <wjp> sorry :-)
[21:31:12] <Colourless> i'm just thinking whether patches should be discarded. I don't think that its wise to discard them, as it would mean that the you'd need to reload them for every file
[21:31:30] <Colourless> and with the way things would work, it might just cause a lot of pain in the process of having to reload them
[21:32:02] <Colourless> i'm thinking that it would be possible to just get timidity to load all the patches on init
[21:32:15] <wjp> or maybe just all patches that U8's tracks use?
[21:32:16] <Colourless> or, get it to load all the patches we might want
[21:32:29] <Colourless> yes :-)
[21:32:55] <Colourless> i'd do that first. Then later if i decide to be fancy, i could attempt to do something different
[21:37:40] * wjp nods
[21:37:46] <wjp> we have plenty of memory left, anyway
[21:38:04] <wjp> only using about 17Mb currently
[21:38:26] <Colourless> :-)
[21:38:49] <Colourless> using 20mb here
[21:41:00] <wjp> U8 required only 4, btw :-)
[21:41:07] <Colourless> :-)
[21:41:23] <Colourless> yeah well, the did things differently to us
[21:59:29] <Colourless> i had better be going... it's not 'really' late :-)
[21:59:33] <Colourless> cya
[21:59:41] <wjp> night
[21:59:41] <-- Colourless has left IRC ("casts invisibility")
[22:47:29] <-- wjp has left IRC ("Zzzz...")