#pentagram@irc.freenode.net logs for 4 Jan 2004 (GMT)

Archive Today Yesterday Tomorrow
Pentagram homepage


[00:29:30] <-- wjp has left IRC (Remote closed the connection)
[00:39:44] --> Kirben has joined #pentagram
[00:39:44] --- ChanServ gives channel operator status to Kirben
[03:00:43] <-- Fingolfin has left IRC ("42")
[04:17:27] --> SB-X has joined #pentagram
[05:33:00] <-- watt has left #pentagram ()
[06:03:35] --> sbx has joined #pentagram
[06:03:36] <-- SB-X has left IRC (Read error: 54 (Connection reset by peer))
[08:19:38] --> watt has joined #pentagram
[10:13:36] --> Colourless has joined #Pentagram
[10:13:36] --- ChanServ gives channel operator status to Colourless
[10:15:06] <Colourless> hi
[10:16:32] --> Knight has joined #pentagram
[10:30:29] --> EsBee-Eks has joined #pentagram
[10:30:29] <-- sbx has left IRC (Read error: 54 (Connection reset by peer))
[10:36:29] <Colourless> wjp: Document the compessed shapes format please :-)
[10:38:25] <Colourless> ideally I would like to be able to decompress to a ConvertShape object
[10:38:36] <Colourless> but I've no idea how similar compressed shapes actually are
[10:39:36] <Colourless> that way if it can be done, we wouldn't need a separate program to do command line shape conversion. It could be integrated into ShapeConv
[10:42:26] <Colourless> also, in theory, it would mean that Pentagram could actually load the shapes directly from the compressed shapes flex file
[10:42:37] <Colourless> assuming that the format wasn't too different
[11:06:35] <-- EsBee-Eks has left IRC ("...")
[11:40:32] <-- Knight has left IRC (sterling.freenode.net irc.freenode.net)
[11:41:58] --> [1]Knight has joined #pentagram
[11:43:55] --> Knight has joined #pentagram
[11:44:33] <-- Knight has left IRC (Read error: 104 (Connection reset by peer))
[11:44:34] --- [1]Knight is now known as Knight
[11:58:56] --> wjp has joined #pentagram
[11:58:56] --- ChanServ gives channel operator status to wjp
[12:00:05] <wjp> hi
[12:01:27] <Darke> Nanoo!
[12:01:32] <wjp> *slap*
[12:01:55] * Darke yips! Hey!
[12:02:25] <Colourless> hi
[12:04:21] <Colourless> hey would it be 'cool' to add typedef'd ObjId and ProcId type to pentagram?
[12:05:01] <wjp> yes, you mentioned that before
[12:05:16] <Colourless> Yes, i have
[12:06:21] <Colourless> if there are no objections, my next commit will change some of the uint16s to ObjId and ProcId
[12:24:14] <wjp> in other news: I've actually started documenting that compressed shape format friday
[12:24:15] <-- Darke has left IRC (Read error: 54 (Connection reset by peer))
[12:24:33] <wjp> about 75% done
[12:24:45] --> Darke has joined #pentagram
[12:24:54] --- ChanServ gives channel operator status to Darke
[12:25:02] <wjp> the main 'problem' is that a frame in each shape can copy pixels from the previous frame
[12:25:21] <Colourless> ah. interesting
[12:25:21] <wjp> other than that it uses the same RLE
[12:25:37] <Colourless> i had no idea :-)
[12:25:45] <wjp> (although the array of pointers to the start of the scanlines is missing in the frame header)
[12:27:17] <wjp> I didn't really do any benchmarking, but I suspect that decoding them at runtime will be too slow
[12:27:40] <wjp> well, maybe not 'too slow'; just 'slow'
[12:28:09] <Colourless> well, the sounds sufficently different that kludging the loading routine wouldn't be possible
[12:36:22] <wjp> well
[12:37:00] <wjp> if we subclass ShapeFlex to CompressedShapeFlex, and replace the cache() function by something that decompresses and caches the result
[12:37:22] <Colourless> i would prefer not doing that :-)
[12:37:27] <Colourless> but it's possible
[12:38:10] <wjp> or make a new 'dummy' ConvertShapeFormat
[12:39:16] <Colourless> ok, saving Item::parent... do it always, or only if flags & (FLG_CONTAINED|FLG_EQUIPPED) ??
[12:40:40] <wjp> hm, how many items did we have?
[12:40:41] <Colourless> dummy would be 'okish' as well
[12:41:05] <wjp> order of 10K items?
[12:41:34] <Colourless> i'm not sure how many
[12:41:45] <wjp> I think it won't be a problem to always save it
[12:41:50] <Colourless> the value is 'garbage' for items in maps that don't have it too
[12:42:07] <Colourless> I'm thinking we should decompress to a ConvertShape object. Then we have the ability to construct a Shape object from a ConvertShape object.
[12:42:30] <Colourless> or something :-)
[12:43:24] <Colourless> i'll just make it conditional on the contaied equipped flags
[12:45:12] * Colourless hmms
[12:45:50] <Colourless> ConvertShape and Shape aren't 'that' different
[12:47:51] <Colourless> it 'might' be an idea to just slightly expand Shape to include the missing members that ConvertShape has
[12:54:49] <wjp> that would work too; just a few things
[12:59:31] <Colourless> grr. I've broken save game loading some how :-)
[13:01:40] <Colourless> ok. Saving the 'parent' value is just going to cause problems with the way things currently work
[13:02:05] <Colourless> the container should just reset the parent value upon loading
[13:04:30] <Colourless> no point changing the savegame format when it's not required
[13:06:20] <wjp> only save parent when ETHEREAL && (CONTAINED || EQUIPPED) ?
[13:06:33] <Colourless> yes
[13:06:48] <Colourless> that's how it's going to be
[13:08:16] <Colourless> is equipped ever set when contained is not?
[13:08:46] <wjp> hm, I think they're currently mutually exclusive
[13:09:15] <Colourless> contained is set by Item::moveToContainer
[13:09:51] <Colourless> and equipped is set by Actor::addItem
[13:17:23] <Colourless> ok, this seems to be functioning correctly
[13:24:25] <Colourless> committed
[13:25:52] <wjp> I had the _last_ commit of the year for two years :-)
[13:26:14] <Colourless> aye you did :-)
[13:27:04] <wjp> three years if you count commits to the pentagram module of exult
[13:28:35] <wjp> three years... that's rather long already :-)
[13:28:42] <wjp> why isn't pentagram done yet? :-)
[13:28:43] <Colourless> :-)
[13:28:54] <Colourless> I blame darke :-)
[13:29:32] <Darke> Hey!
[13:29:45] <Colourless> I get a 'consolation' first commit of the new year in 2002. Tristan may have been the one to do the commit, but he committed something written by me :-)
[13:29:52] <Colourless> 2002-01-02 Tristan Tarrant <nadir@users.sourceforge.net>
[13:29:53] <Colourless> * FAQ: added the FAQ by Ryan
[13:29:58] <wjp> hehe
[13:30:20] <Darke> We're obviously taking so long, simply because we're trying to do things documentation/infrastructure side first. *grin*
[13:31:42] <wjp> hm, is the current Container::addItem correct?
[13:32:21] <wjp> (specifically when the added item is ethereal)
[13:32:45] <Colourless> yes it will work :-)
[13:33:03] <Colourless> Container::addItem should never be called directly
[13:33:10] <Colourless> you use Item::moveToContainer
[13:33:18] <Colourless> which will clear the parent value before adding
[13:34:59] <wjp> ah, I see
[13:35:36] <wjp> makes it clearer by having most of the etherealness-mess in Item
[13:38:28] <Colourless> you wouldn't think that Item::move and Item::moveToContainer would be so complex :-)
[13:38:48] <wjp> they are rather large, yes :-)
[13:39:12] <Colourless> they are also rather similar too....
[13:40:45] <Colourless> it would be nice if they could be combined, but i really don't see how
[13:53:37] <wjp> ok, committed u8shapes.cmp format docs
[13:55:43] <Colourless> ok great.
[13:55:52] <wjp> revision 1.319 of ChangeLog already
[13:56:29] <Colourless> well, with pentagram we log everything
[13:56:34] <Colourless> even 1 line fixes :-)
[13:57:13] <wjp> hm, speaking of changelog... forgot to mention something in exult's ChangeLog yesterday
[13:57:35] <Colourless> in exult for example, jeff doesn't always commit an updated changelog for better or for worse, so we don't really have an real idea the number of changes that have been done
[14:00:35] * wjp nods
[14:07:58] <wjp> so, does this mean the 'push/pop and containers' bug is fixed?
[14:08:03] <Colourless> yes
[14:12:46] <Colourless> ok, is there ever 'see through' pixels in the rle runs?
[14:13:16] <Colourless> actually, ignore that comment
[14:13:35] <Colourless> since it doesn't actually matter
[14:34:42] <wjp> it should be possible to decompress the shapes without un-RLE-ing and re-RLE-ing them, in most cases
[14:35:09] <wjp> although they do have to be un-RLE-ed to get pixels from them for the next frame
[14:35:45] <wjp> (the only problem would be when runs get too long after copying pixels)
[14:41:49] <Colourless> yes
[14:42:13] <Colourless> how long would the runs actually get?
[14:42:28] <wjp> of course I didn't know that when writing unpackshp, so it should re-RLE-s the frames
[14:42:31] <wjp> I have no idea
[14:42:44] <wjp> some of the shapes are pretty big, though
[14:43:57] <wjp> the 'newdlen' variable I keep in unpackshp() should be the new first byte of each run, so we could see if that ever gets larger than 255
[14:44:43] <Colourless> i would have though that the shape structure would have been mostly the same
[14:44:52] <Colourless> the only 'problem' i could see would be if when copying the data from the previous frame gave you a gap in the middle of a run
[14:45:13] <wjp> yes...
[14:45:41] <Colourless> it is easy enough though to split runs
[14:47:20] <wjp> I'll add in some asserts in unpackshp to see if it's necessary
[14:49:17] <Colourless> i would imagine that all of the runs are actually of the correct size.
[14:49:44] <Colourless> i would also imagine that copying gaps wouldn't be done.
[14:49:51] <Colourless> it's not going to save you very much
[14:49:54] <wjp> very likely you're right
[14:50:26] <Colourless> same with duplicated pixels. No point copying when they are already compressed
[14:50:48] <wjp> so far no assertions have been triggered
[14:51:21] <wjp> (checking for 0 <= newdlen <= 255, and copied pixel != 0xFF)
[14:51:40] <wjp> ok, run finished
[14:52:07] <Colourless> in some cases you can only have max size of 127 for a run
[14:52:17] <wjp> newdlen is the actual byte
[14:52:28] <Colourless> ah ok
[14:52:32] <wjp> including the LS bit that indicates the type, if applicable
[14:53:07] <wjp> (good thing it's the LS bit... prevents having to check overflows :-) )
[14:54:47] <Colourless> thinking about it, the compressor probably was very simple to construct
[14:54:49] <wjp> a simple gzip compresses the shapes _far_ better, btw :-)
[14:55:08] <Colourless> yes i can imagine that it would :-)
[14:55:29] <Colourless> probably would have been faster to decompress too :-)
[14:55:52] <wjp> (u8shapes.flx is about 15Mb; u8shapes.cmp is ~12Mb; u8shapes.flx.gz is ~7.5Mb)
[14:56:16] <wjp> hm, u8shapes.cmp.gz is 6.6Mb
[14:56:38] <Colourless> game was distributed rar'd remember
[14:56:41] <wjp> yes
[14:56:51] <wjp> so it probably mattered about 1Mb
[14:57:27] <Colourless> now, if i had a u8shapes.cmp i could tell you :-)
[14:57:59] <Colourless> u8shapes.rar from u8shapes.flx is 6.4 mb
[14:59:00] <Colourless> as a zip i'm getting 7.2 which was better than your gz
[15:04:12] <wjp> it should be pretty trivial to copy sequences of pixels straight from the RLEd data
[15:04:28] <wjp> so we can probably skip all the unRLEing and reRLEing
[15:05:00] <wjp> would be particularly nice if every copied sequence falls within a single run in the previous frame
[15:05:17] <Colourless> yeah it should be fairly trivial
[15:05:35] <Colourless> even handling over multiple runs should be trivial
[15:05:50] * wjp nods
[15:06:01] <Colourless> the only problem might come if it accumulates over multiple frames
[15:06:08] <Colourless> or if it only compares to the previous
[15:06:27] <wjp> well, as long as we decompress an entire shape at once, that won't be a problem
[15:06:37] <wjp> since we'll have the uncompressed RLEd data of the previous frame then
[15:06:52] <Colourless> yes true, it's not a problem :-)
[15:07:18] * Colourless wasn't actually thinking entirely properly. Of course the previous frame is going to contain all the data from it's previous and so on
[15:09:00] <Colourless> all you need to do is get the correct line which after the lookup table is constructed, is trivial, skip over 'x' pixels then copy 'n' pixels
[15:09:18] * wjp nods
[15:46:39] <-- Kirben has left IRC ("System Meltdown")
[16:20:10] --> ragzter has joined #pentagram
[17:08:41] --> Fingolfin has joined #pentagram
[17:08:41] --- ChanServ gives channel operator status to Fingolfin
[17:10:32] <wjp> hi Fingolfin
[17:28:06] <-- Fingolfin has left IRC ("42")
[17:38:31] --> hofi has joined #pentagram
[17:38:36] <-- hofi has left #pentagram ("Client exiting")
[17:51:51] <wjp> bbl, dinner
[18:18:24] <wjp> and back
[18:18:34] <Colourless> wb
[18:52:55] <-- Colourless has left IRC ("casts invisibility")
[21:06:57] <-- ragzter has left IRC ("mörda mig inte eller så men nu bootar jag (fanimej) till Windforce.. :F tänkte göra lite ambient.. blir inte borta länge =)")
[23:19:52] --> shinji-kun has joined #pentagram
[23:25:40] <watt> wow.. You have been busy since I was last here... er awake, I should say.
[23:39:27] <wjp> hi