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

Archive Today Yesterday Tomorrow
Exult homepage


[00:14:43] <-- Dark-Star has left IRC (Read error: 110 (Connection timed out))
[00:38:26] <-- bj0ern has left IRC ("Some people hate violence. They're all dead ...")
[00:38:27] <wjp> hmm... this is not good... unpacker fails at a frame which seems to have been modified by the patch
[00:48:17] <wjp> bah, this line seems to be broken or something
[00:48:37] <wjp> each line specifies exactly the right number of pixels, but this one specifies one less
[01:11:57] --> sb-x has joined #exult
[01:12:02] <wjp> hi
[01:12:05] <sb-x> hi
[01:12:19] <sb-x> your making me a u8 decompressor for pentagram now? :)
[01:12:36] <wjp> kind of :-)
[01:13:15] <wjp> there's just one or two glitches causing some problems
[01:13:30] <sb-x> it seems like you've been working on it for over an hour (over 2 hours?)
[01:13:46] * wjp looks at time
[01:13:51] <wjp> hm, yes, about 2 hours now
[01:14:31] <wjp> the main thing was done after an hour or so, but it seems we don't know a couple of details about the shape format
[01:18:37] <-- matto has left IRC ("Play Dragon's Lair in linux - http://www.daphne-emu.com - Developers welcome :)")
[01:18:47] --> matto has joined #exult
[01:19:15] <sb-x> but you know enough to draw them?
[01:19:21] <wjp> yeah
[01:19:34] <wjp> or so it seems, anyway
[01:21:46] <-- Fingolfin has left IRC ("night")
[01:25:41] --> Darke has joined #exult
[01:25:41] --- ChanServ gives channel operator status to Darke
[01:25:48] <wjp> morning
[01:26:08] * Darke bows. "Evening, or at least I guess it's evening over there. <grin>"
[01:26:15] <sb-x> evening
[01:26:17] <wjp> 2:30am
[01:26:23] * wjp yawns...
[01:26:33] <sb-x> 19:25
[01:26:38] <Dominus> hi as well
[01:26:53] * Dominus is playing Geneforge
[01:26:58] <Darke> wjp: As to the 'exact number of pixels' are they all an even number of pixels?
[01:27:18] <wjp> hm, interesting thought
[01:27:21] <Darke> With the one specifying less, being an odd number of pixels?
[01:27:34] <wjp> but unfortunately it's the wrong way
[01:27:38] <Darke> Becuase a lot of the graphics formats round up to an even number, to speed up blitting.
[01:27:46] <wjp> the width is 62 pixels, but the line _should_ end after 61 pixels
[01:28:02] <wjp> however, because it's not done yet (according to our decoding), it continues reading on the next line
[01:28:10] * Darke hmms.
[01:28:39] <Darke> Is the 'width' flag 1 byte in side?
[01:28:48] <Darke> s/side/size/
[01:28:53] <wjp> no, 2
[01:29:04] * Darke thinks that it appears he hasn't woken up completely yet.
[01:30:37] <Darke> There's no obvious terminating byte or bytes that are always at the end of the line?
[01:30:45] <wjp> no
[01:31:10] <wjp> the way I currently solve it:
[01:31:34] <wjp> the first byte of every 'run' is the length. If the length of a run exceeds the line width, I stop the line, and back up one byte
[01:33:27] <Darke> So one 'run' is equal to one line?
[01:33:35] <wjp> no, a line consists of several runs
[01:33:53] <wjp> oh, wait, I was wrong
[01:34:10] <wjp> line = ( x shift + run ) +
[01:34:21] <wjp> (x shift = how far to move the 'cursor' to the right
[01:34:33] <wjp> , run = some pixel data to draw)
[01:34:50] * Darke nods. This format is sounding rather familiar.
[01:34:55] <wjp> :-)
[01:36:02] <Darke> How often does this oddity happen? One an image, once or twice in an entire file of images?
[01:36:16] <wjp> first occurence was in shape 4
[01:36:41] <wjp> then I 'fixed' it, and so I don't know how many times it happened after that
[01:37:28] <wjp> all these glitches seem to be fixed by the patch, though
[01:37:31] * Darke remembers something similar happening in the decoding of XCOM's images. It turned out there was a bug in their encoder, that was 'transparent' to their renderer.
[01:37:54] <wjp> heh :-)
[01:38:07] <wjp> ...or maybe they were fixed by the decompressor
[01:38:25] <wjp> (problem is, I have a pre-patch u8shapes.cmp, obviously, and a post-patch u8shapes.flx)
[01:38:51] <Darke> Which sounds like probably how they handled it in game, or yes, in the decompressor.
[01:39:15] <wjp> ugh... this line looks broken too
[01:39:32] <Darke> Hmm... I only have the post-patched copy and, IIRC, decompressed too, since it's from the Ultima Collection.
[01:41:11] <wjp> ok, here's a line:
[01:41:35] <wjp> 00 0E 1B 1A 1A 1A 1A 1A 1B 82 04 19 1B 03 0A 1A
[01:41:48] <wjp> 19 01 18 1B 01 01
[01:42:35] <wjp> no, minus that last 01
[01:42:45] <wjp> interpretation:
[01:42:52] <wjp> 00 = start at pos 0
[01:43:07] <wjp> 0E = (14 / 2) = 7 data bytes following
[01:43:23] <wjp> 82 = move 0x82 to the right
[01:43:31] <wjp> 04 = (4 / 2) = 2 data bytes following
[01:43:38] <wjp> 03 = move 0x03 to the right
[01:43:46] <wjp> 0A = 5 data bytes following
[01:43:55] <wjp> 01 = move one to the right
[01:44:35] <wjp> now, if I'm not mistaken, we should be at position 0 + 7 + 0x82 + 2 + 3 + 5 + 1 = 0x94
[01:45:21] <wjp> however, the frame width = 0x96
[01:46:30] <wjp> now the next byte is a 01, and that is completely meaningless as the start of a run
[01:46:43] <wjp> ugh... so I have to sanity-check the data while I read it? bah
[01:47:43] <wjp> ok, it's reached shape 300...
[01:47:48] <wjp> shape 400
[01:47:50] <Darke> Hmm... the 'run' file formats I've found, have used 01 and 00 as 'special' values. Such as terminating the shape and line prematurely.
[01:48:05] <wjp> segfault in shape 851...
[01:48:19] <Darke> So you don't have to store runs for each line of a large image that are all transparent and such.
[01:48:57] <wjp> in this case, the 01 apparently means: stop this line, but read me again for the next one
[01:49:17] <Darke> Of course it could also just be a bug.
[01:49:35] <wjp> or a smart way to save a few more bytes :-)
[01:50:02] <Darke> <nod> That also works. <grin>
[01:51:14] <wjp> shape 851, frame 0, line 45...
[01:55:44] <wjp> oh, wow, it didn't crash in the decoder this time
[01:55:57] * Darke earperks. Impressive!
[01:56:15] <wjp> ah, that was the last shape :-)
[01:56:50] * wjp should check for empty shapes
[01:57:54] <wjp> now, let's see if the .flx works...
[01:59:26] <Darke> <grin> Luck!
[01:59:54] <wjp> wow, it does
[02:01:26] <sb-x> !
[02:04:22] * Darke boggles in amazement.
[02:06:45] <wjp> ok, committed
[02:07:05] <wjp> now I should _really_ go to bed...
[02:07:10] <wjp> bye
[02:07:31] <-- wjp has left IRC ("[x]chat")
[02:17:08] <sb-x> !
[02:19:15] * Darke brushes the spare exclamation marks into the punctuation bowl.
[02:19:51] * sb-x runs ./bootstrap
[02:20:14] * sb-x runs ./configure
[02:20:40] <sb-x> I learned autoconf yesterday btw
[02:21:58] <sb-x> I havn't needed it for anything before, and I don't actually need it for portability yet. I need it because automake says it needs it, and I'm using automake so I don't need to make my own complex Makefiles in my deep project.
[02:22:15] * sb-x runs make
[02:22:59] * Darke nods. He let kdevelop do all the fuss of making the autoconf/automake files for him, but he had to hack at them a lot.
[02:28:01] <sb-x> KDev is too slow for me. :-) Did you use it for ucxt? There isn't a .kdevprj file there.
[02:28:54] <Darke> I have a exult.kdevprj file which I don't commit into cvs. <grin> I use that.
[02:29:42] <Darke> It's easy to recreate anyway. KDev will create one from the autoconf/automake files you've already got.
[02:29:55] <sb-x> Does it understand your hacks?
[02:30:03] <sb-x> or anything you've done manually to them
[02:30:43] * sb-x completes building Pentagram.
[02:32:46] <Darke> If the files don't have a special 'KDEV' commented out section in them, it won't actually touch them, so if you add a file to your project, you still need to edit them if you create the project from the files,
[02:35:08] <sb-x> oh i see
[02:35:43] <sb-x> i just use cooledit but i would like to modify it a little
[02:35:53] <sb-x> to add a function list
[02:36:08] <sb-x> and change the widget style if i get the time
[02:36:16] * sb-x tries to figure out Pentagram.
[02:39:03] <sb-x> display is not a good name for the map viewer
[02:39:22] <sb-x> that is also the name of an Image Magick program
[02:39:34] * Darke nods. He had the same problem. <grin>
[02:44:15] <sb-x> thunderstorm, ive gotta go
[02:44:18] <-- sb-x has left IRC ("X-Chat [1.6.4]")
[02:47:48] <-- Dominus has left IRC ("Exult! Exult! Exult!")
[02:48:51] --- Darke is now known as Darke|afk
[03:15:44] --- Darke|afk is now known as Darke
[04:55:15] --> MisterP has joined #exult
[05:18:43] <-- MisterP has left IRC ()
[05:52:51] --> ShadwChsr has joined #Exult
[06:43:19] <-- ShadwChsr has left IRC ()
[08:01:24] --> Kirben has joined #exult
[08:01:24] --- ChanServ gives channel operator status to Kirben
[08:44:30] <Darke> Hi Kirben.
[09:20:31] --> wjp has joined #exult
[09:20:31] --- ChanServ gives channel operator status to wjp
[09:20:33] <wjp> hi
[09:22:46] <Darke> Hi.
[09:29:39] <matto> hi
[09:30:01] * matto has changed the topic to : Exult v0.98 RC1 Now Available! Download it NOW! http://exult.sf.net *FLUFF*
[09:34:27] * wjp fixes a couple of minor issues with unpackshp...
[09:35:23] * wjp should get an u8shapes.flx from the original for comparison
[09:35:46] <wjp> breakfast first, though
[09:39:22] * Darke nods a comparison with the original shapes.flx would be good. And I'm curious how different yours is from it. <grin>
[09:49:30] * wjp is going to install U8 on his parents' win98 machine
[09:49:32] <wjp> brb
[10:03:56] <wjp> hm, looks like I have more work to do...
[10:04:14] <wjp> the u8shapes.flx I generate is _way_ too small
[10:10:17] <wjp> hm, and on top of that I seem to write some junk at the end of each file
[10:24:16] <Darke> <blink> Weird. Perhaps when they decompress the shapes, they also 'expand' any duplicates?
[10:25:06] <wjp> actually, from what I can tell they remove duplicates
[10:27:34] * Darke wonders what all the other 'stuff' in the flex is, and where it comes from.
[10:27:55] <wjp> yeah, me too
[10:31:29] <wjp> this is kind of weird... in the uncompressed .flx, there's a field "size" for every frame
[10:32:02] <wjp> the corresponding field in the .cmp, occasionally seems to mean size too
[10:32:25] <wjp> but not always... *sigh*
[10:43:34] * wjp decides to ignore that field and just calculate size from the difference with the next offset
[10:50:10] * Darke nods and gets the feeling that field may actually never mean size, it's just a 'coincidence' that it matches most times.
[10:52:03] * wjp gets the very unpleasant feeling that they may have done something else to compress the shapes
[10:53:05] <wjp> I think it does mean size, but my assumption that the actual data wasn't compressed further (it is already RLE, after all) is just wrong
[10:55:11] <wjp> I wonder if that will explain the problems from last night
[11:03:50] * Darke ponders and nods. Yes, it's certainly possible that the data is further compressed. The question is, of course, how. <grin>
[11:03:56] <wjp> yes...
[11:04:08] <wjp> and it would seem it's not just line-based
[11:05:01] <wjp> 12 32 4B 00 4B 4C 4D 4F ... (19 more data bytes), uncompresses too:
[11:05:20] <wjp> 12 34 4B 4C 4C 4B 4C 4D 4F ... (those same 19 data bytes)
[11:07:02] <wjp> s/too/to/
[11:07:43] <wjp> that 00 clearly does something special, but I don't quite see yet how it would transform into 2 4C's
[11:15:21] <wjp> huh? and here the uncompressed version _does_ RLE 6 adjacent equal bytes, but the compressed version doesn't
[11:16:10] * Darke blinks. And thinks this is not a 'normal' compression.
[11:16:32] <wjp> most definitely not...
[11:22:23] <wjp> and even though it doesn't RLE that run, it's still 1 byte shorter
[11:22:47] * Darke really can't think of how that 00 transforms into those 4C's. It can't just be hardcoded that 00==4C4C, because that would just not make any sense. And one thing that most of our U8 decoding so far has done, is made 'sense'.
[11:23:06] <wjp> it might be some kind of reference to an earlier line/frame
[11:23:15] <wjp> here's another one:
[11:23:27] <wjp> 0E 40 4E DE 4A 4B 01 4C 4D 4C ... ->
[11:23:44] <wjp> 0E 1A 4E DE 4A 4B 4B 4A 4D 4C 4D 4C ...
[11:23:55] <wjp> (the 1A and 40 are different because of that run I mentioned)
[11:24:02] <-- matto has left IRC (Read error: 110 (Connection timed out))
[11:24:15] --> matto has joined #exult
[11:24:26] <wjp> (ie. it inserts a "4B 4A 4D" at the '01')
[11:25:53] <wjp> I wonder if it could mean "insert X+2 random things close to the last byte"
[11:28:21] <wjp> D9 DB DC DD DB 00 4E -> D9 DB DC DD D8 D9 D8 4E
[11:30:23] <wjp> 4C 4E 00 DB -> 4C 4E 4E 4E DB
[11:30:25] * Darke agrees it could be a reference to an earlier line. Maybe there's a sequence byte that assigns a byte to represent a string of them. Odd, but it might work.
[11:46:30] * wjp thinks he typoed in the D9 DB one
[11:48:07] <wjp> uncompressed should be: D9 DB DC DD DB D9 D8 4E
[11:48:14] <wjp> (which means the "X+2" still holds)
[11:48:23] <-- Kirben has left IRC (Read error: 104 (Connection reset by peer))
[11:50:01] <Darke> I was wondering about that, thanks.
[11:52:38] --- wjp is now known as wjp|away
[11:52:41] * wjp|away has to go
[11:52:47] <wjp|away> see you later
[11:53:25] <Darke> Bye.
[11:56:56] --> Kirben has joined #exult
[11:56:56] --- ChanServ gives channel operator status to Kirben
[12:47:30] <-- Darke has left IRC (capek.openprojects.net irc.openprojects.net)
[12:48:10] --> Darke has joined #exult
[12:55:17] <-- matto has left IRC (capek.openprojects.net irc.openprojects.net)
[12:55:32] --> matto has joined #exult
[13:02:21] --> Dark-Star has joined #exult
[13:07:01] <Dark-Star> Hi
[13:09:58] * Darke bows. Hi.
[13:19:35] <-- kefka has left IRC (Read error: 104 (Connection reset by peer))
[13:20:58] --> kefka has joined #exult
[13:46:43] --> Colourless has joined #Exult
[13:46:43] --- ChanServ gives channel operator status to Colourless
[13:50:15] <Colourless> hi
[13:51:31] <Darke> Hi.
[14:32:47] <-- Kirben has left IRC ("System Meltdown")
[14:33:58] <Dark-Star> help /leave
[14:34:07] <Dark-Star> oops ;-)
[14:48:31] --> Nadir has joined #exult
[14:48:31] --- ChanServ gives channel operator status to Nadir
[14:51:42] <Colourless> hi
[14:53:44] <Nadir> hi
[14:56:43] <Nadir> Colourless: it would be neat to implement Exult's scaling with GL
[14:57:39] <Colourless> the way exult handles rendering isn't exactly friendly for hardware acceleration via opengl
[15:00:36] <Colourless> that is why it's not something that i have really thought much about. Exult does a lot of partial screen updates which can cause some problems
[15:05:31] <-- Dark-Star has left IRC ("Leaving")
[15:06:52] <Nadir> ah, ok
[15:27:43] <-- Nadir has left IRC ("Client Exiting")
[16:35:49] --- wjp|away is now known as wjp
[16:36:12] <wjp> hi
[16:36:18] <Colourless> hi
[17:03:08] <matto> partial screen updates don't sound like they'd be a problem to me
[17:04:53] <Colourless> well, not really, but changes will require that each object on screen gets redrawn. In some circumstances (i.e. multiple modal gumps) what is supposed to be on screen isn't actually known
[17:04:56] <matto> you could use an SDL_Surface for an OpenGL texture which would allow partial screen blitting to still work
[17:05:12] <Colourless> that is an an inefficient method
[17:06:02] <Colourless> texture updates can be 'real' slow for some hardware
[17:06:09] <matto> hehe
[17:06:52] <wjp> how would you do palette cycling?
[17:07:07] <matto> you can do 8-bit textures in opengl, pretty sure
[17:07:08] <Colourless> well, that's another thing
[17:07:32] <Colourless> unless the device supports the palattized texture extension, i wouldn't bother
[17:08:30] <matto> if not, you could blit an 8-bit SDL_Surface to a 32-bit SDL_Surface ... hehe
[17:09:44] <matto> I'm guessing that with the current scalers that exult has, you must not be running directly in 8-bit color anyway ... else how would you get that smoothing effect.. hehe
[17:10:34] <Colourless> we can already blit from 8 bit to 555, 565 and 888
[17:13:23] <matto> cool
[19:00:41] --- wjp is now known as wjp|dinner
[19:07:56] --> Fingolfin has joined #exult
[19:08:17] <Colourless> hi
[19:08:27] --- ChanServ gives channel operator status to Fingolfin
[19:13:10] <Colourless> bye all
[19:13:11] <-- Colourless has left IRC ("no comment")
[19:16:08] --- wjp|dinner is now known as wjp
[19:16:09] <wjp> hi Max
[19:17:04] --> Dark-Star has joined #exult
[19:17:08] <Dark-Star> Hi
[19:20:06] <Dark-Star> ok, seems no one's here so I'll just go eat something first...
[19:20:10] <Dark-Star> brb
[19:20:16] <-- Dark-Star has left #exult ()
[19:42:12] --> Dark-Star has joined #exult
[19:42:18] <Dark-Star> Hi
[19:45:02] <Dark-Star> uuuh... anybody here?
[19:47:08] <Fingolfin> yes
[19:50:14] <Dark-Star> good, I already thought my IRC client was broken ;-)
[19:57:13] <wjp> hi
[19:58:14] <Dark-Star> hi. I've just browsed the logs... seems the decoding is harder than it looked ;-)
[19:58:38] <wjp> yeah, it turned out they added another form of compression besides just stripping the headers
[19:59:03] <wjp> so it looks like I'll be staring at hexdumps some more
[20:00:04] <Dark-Star> the u8shapes.cmp is the same for all u8 versions, right?
[20:00:10] <Dark-Star> (german/english)
[20:01:54] <wjp> dunno, probably
[20:02:11] <wjp> 52c5b79eafcd7bc95f50dd85ecbc4255 u8shapes.cmp
[20:02:40] <Dark-Star> 52c5b79eafcd7bc95f50dd85ecbc4255 /var/games/pentagram/ultima8/static/u8shapes.cmp
[20:29:23] <wjp> hm, looks like that interview Ryan sent has a few facts wrong...
[20:29:32] <wjp> "Originally for windows"? "RC2"?
[20:33:03] <Dark-Star> :)
[20:56:55] <Fingolfin> he, indeed
[20:58:01] * wjp wonders what is meant with "What changes did you have to make to get sound working [...] under Windows?"
[21:15:18] * wjp found a pattern in the compression scheme! woohoo
[21:15:29] <wjp> it looks like it "borrows" pixels from the previous frame...
[21:15:52] <wjp> (which explains why I didn't catch it the first time... I was only looking at the first frame of a couple of shapes)
[21:18:24] <wjp> *sigh*, so I need to write an RLE compression algo. too. Oh joy
[21:32:21] * wjp wonders how to handle frames that have a different size than the previous one
[21:37:20] <Dark-Star> left-align every frame? that's what I'd try first...
[21:40:12] <wjp> yeah, that would be my guess too
[21:41:17] <wjp> next thing to find out would be exactly which colours are reserved for this "borrowing"
[21:41:32] <wjp> 00 and 01 are 2 and 3 bytes, resp.
[21:41:54] <wjp> ah well, I guess I should just start experimenting
[21:42:20] <Dark-Star> so if you encounter 01 then you need to copy 3 bytes from the previous frame?
[21:42:25] <wjp> yes
[21:42:41] <Dark-Star> weird encoding scheme :)
[21:42:50] <wjp> kind of, yes
[21:43:08] <wjp> it makes sense for sequences of frames which are nearly identical, though
[21:43:43] <wjp> assuming that this is the last piece of the puzzle, it saved 10% of space
[21:44:31] --> bj0ern has joined #exult
[21:44:41] <bj0ern> hi
[21:44:44] <wjp> hi
[21:48:35] <Dark-Star> hi
[22:05:50] <Dark-Star> ok I'll be leaving ... see ya
[22:05:55] <wjp> bye
[22:06:01] <-- Dark-Star has left IRC ("using sirc version 2.211+KSIRC/1.1")
[22:09:12] <wjp> ugh... this is slowly turning into one of the worst pieces of code ever
[22:12:49] <wjp> ...and the resulting .flx file is only 1.4Mb
[22:12:50] <wjp> ugh
[22:15:33] <wjp> 2.6Mb...
[22:21:03] <wjp> 6.6Mb...
[22:21:06] <wjp> sheesh
[22:30:26] <bj0ern> omg.. its an inflatable virus
[22:30:37] <wjp> :-)
[23:11:53] <wjp> wow, I apparently wrote the new savegame screen
[23:12:03] * wjp corrects that...
[23:50:06] * wjp sighs again
[23:50:10] <wjp> this format is just plain weird
[23:50:22] * wjp should give up for tonight
[23:50:26] <wjp> night
[23:50:29] <-- wjp has left IRC ("[x]chat")