Hi,

I'm the author of the software Hachoir. This program aims to split files into chunks like MultiEx does with game files. You may try it, it's a free ("libre") software under GPL licence and written in Python language.

I'm writing to you because I'm trying to read Worms2 game files (.dir files), and I don't understand Sprite pixels encoding. Hachoir is able to read most important informations from Images and Font, but can not read Sprite data. For Sprite (animations), it can read color palette, number of frame, and frame informations : (x,y) and (width, frame).

Ask me if you need help to run the Hachoir, and if you just want file format. And can also send you DIR example file.

Haypo

Hi!

Nice program you have there! It's a layout especially suited for programmers! We should talk, because it may be, from the look of the screenshots, that there might be a MultiEx script<->Hachoir conversion routine possible.

Ok, here are the command to test the Hachoir with a Worms2 dir file :

Double clic on field "resoures". You will see :
* Sprite from res[0] .. res[589]
* Image from res[590] .. res[712]
* Font from res[713] .. res[739]

Haypo

Here my addresses:
http://www.haypocalc.com/wiki/Victor_St ... _contacter


Yep, sure, it's always possible.

Haypo

Hi mate,

Sure, we would be happy to help . I took a look at your program - I like it a lot - it is definately something that is benificial and I wish you the best with it.

I don't know how much assistance I will be able to provide, considering the file you request is image/animation based, but I will definately help out as much as possible. I know Mr Mouse would be similar in this.

If you could provide us with the specifications you have so far, it would definately be a help, and any files you could provide would be excellent - maybe just zip up a few things and send it over - we will do our best to help you out wherever possible.

Thanks, keep up the excellent work with your program!

WATTO
watto@watto.org
http://www.watto.org

Try to read source code of Worms2 plugin:
http://svn.berlios.de/viewcvs/happyboom ... iew=markup

Palette is a color palette with RGB colors:
http://svn.berlios.de/viewcvs/happyboom ... iew=markup

For Worms2, they are a few classes:
- Worms2_Dir_File: Just call Resource (1st level)
- Resource: One resource (size + data) (2nd level)
- Sprite, Font, Image: differents resource type (3rd level)
- ImageData, MysteriousHeader, SpriteFrame: informations (4th level)

Just read __init__ methods, and especially "read()" functions which have prototype:


Haypo

I'll be in touch.

I think i understand some of this - it was a bit confusing at first because the source on the webpage you gave above is not the same as the source of your program, and in fact the website one looks like it is missing a few lines.

Anyway, at the moment I see it as something like this...



It is a bit of a mix of things, so let me hopefully explain some of it here. And I know its alittle rough and whatever - I havn't really been strict in documenting it correctly at this point in time.

I see several possibilities. ..

1. There are several frames, and the lower part of the file it like a script that tells the pixels that are to be changed with each frame. Each "script" block is terminated with a null byte, so if there are 36 nulls (as in the file I was looking at - arrowdnb.spr), there are 36 frames.
2. The sprite is just a single image, because the lower part of the file has the same number of bytes as (width-X * height-Y) - but this could be just coincidental
3 - If you add up the values in the loop labled "Size Of Control Characters" and "Size Of Changed Data" for each of the "frames", you get the size of the data following the "frames" directory, so maybe these 2 fields both somehow reflect things that I used for the description names
4. The other 2-byte field in the "frames" directory are probably just as before - X,Y,W,H

I see the whole thing being a little like a GIF animation image - you would start off with 1 single frame, and then for each frame following you only store the changed pixels rather than each frame in its completeness.

Hopefully some of this helps - you might be able to make some suggestions or something based on whatever you know about the format or the game.

Like I said - hope it helps!

WATTO
watto@watto.org
http://www.watto.org

You speak about Hachoir's source code? There are a lot of versions. Last stable release is 2005-12-28. But most interesting version is the last one : you have to use SubVersion (works like CVS, do you know it?).

I worked a lot with lodesi (a friend) on Worms2 file format. Here is my informations about the format.


Here is the data of a picture: 640x480 pixels, 80 color, only one frame. Can you help me to understand which compression method was used?

Ideas about "changed pixels" is interresting. I will check it after understanding basic picture encoding

Haypo

Yeah, I was referring to the source for that program. I kinda know what CVS etc is and how it works, but i've never really used it. Never mind, thanks for completing the specs for me

I will take a look at the sample image you draw above - see if I can pick something out of it. It would have to be very good compression if thats a full 640x480 image!

Some common image compressions are based on RLE encoding - basically just replacing duplicates with a control character that says "repeat X times". For example, instead of actually storing the hex FF FF FF... FF 640 times (if the first line was all the same color), it would just write something equivalent to 640 FF - thus using 2 bytes instead of 640 bytes. Chances are the compression would be like this, but I am still amazed at the size of the compressed data. If it only stores the "changed data" like I initially thought, then compression could be quite good because there would be many lines that are just empty with the same value (like all FF's or something), indicating that this data was the same as the previous frame - that would compress heaps, as in my above example. I know they did this kind of thing in The Sims image sprites (SPR_SPR2).

If you want to read up about RLE encoding - the best place to start would be googling about the RLE compression in BMP images - BMP images are really easy to learn, and there are heaps of resources on the net about them. It would probably be a bit advanced to look at the specs for the The Sims sprites, but it you want to you can take a look - the website can be found on SourceForge - its called something like The Sims Technical Resource.

Good luck. I will see whether I can determine anything from the hex you posted.

WATTO
watto@watto.org
http://www.watto.org

HEY! The picture is 640x28 pixels, not 640x480 ... sorry. I think that it's possible to store 640x28 in 259 bytes

Haypo

Im sorry to interupt this. but i dont think it is possible
to store a 640x28 picture in just 259 bytes. if its not totally black
or just 1 color. not even with a very good compression.

It wouldnt just work, too much information have to be discarded.

anyone agree with me , or am I the party-destroyer here to today? =(

To explain what i mean, i made a very simple 1 bitplane picture in
640x28 and using GIF (LZW compression , which is far better than RLE encoding), and i dont even think that "changed data" compression
will achive such incredibly low bitrates.

=o

Something interesting, though. when restructuring the data of the above "640x28" picture it looks like this.

138001
C50080
01BD81
A8C782
6AFF82
96FF84
274D84
D8FF85
28FF86
A64D87
49FF87
B7FF86
BB4D87
52FF87
AEFF86
CC4D87
57FF87
A9FF86
DA4D87
5CFF87
A4FF86
E64D87
5FFF87
A1FF86
-------
etc etc
last block
318000


notice how the numbers are made in 3 byte blocks.
the middlebyte are almost always FF or 4D
and the last byte is 80 or over up to 87.

first block 138001
last block 318000

also some strange similarity.

I dont know what this meens, but i thought it could help you
in some odd way =o

640x28 - that sounds much nicer

In regards to storing this amount of data in the small number of bytes - it could still be possible if the image is mostly a single color, or a transparency (as I suspect is probably the case).

In regards to the arrangement in 3-byte groups - that could obviously map directly to a pixel encoding like RGB or a bit-mapped variation to include an alpha. However, it is probably not the case (i also think you said that there is a palette, which means this would almost definately be wrong). My guess at the moment is that these "middle" values would be the control characters for an RLE-like compression, and the bytes either side could be some grouping of pixel values.

Thanks for putting forward some ideas - i would be interested to see whether the "middle" byte you found actually means something!

WATTO
watto@watto.org
http://www.watto.org