To Tom

ID:189170
 
Sep 25 2003, 9:00 pm (Edited on Sep 25 2003, 10:38 pm)

(From TomB)
Lummox JR wrote:

  I think next I might try to figure out exactly how .dmi files are formatted, then try to make a utility to convert .bmp files directly .dmi.

Ooh, don't dig around in the .dmi binary file; that's just asking for headache! I can provide the format if you want, but it might be easier to just provide a utility since the dmi uses some "weird" compression that isn't that easy to follow. Come to think of it, I may even have this utility in the archives somewhere, as another user requested such a thing in the past. I can look into that once get this next release behind us this week.

FYI, the format will be changing to support larger sizes and 24-bit color, but that's at least a few months down the line. Ideally I wish we could just use a standard format for everything, but because of the need for directions we needed something customized. We'll at least support PNG fairly soon so that movies can be imported with ease.

And remember, in the map editor at least you shouldn't have to go through dmis at all if you just want to input large bitmaps. Just assign the bmp to the large object of choice (generally a turf or an area) and click your way to big pictures!

The utility sounds great. Welcome aboard!



Meh, I have had my nose in that format for quite some time, and have figured out about half of it.. and now you say you'd provide it? -_-... I myself am trying to create a utility for LINUX users to create and modify DMI files.. since you guys were so kind to release a linux compiler, the task didn't seem so huge.. Of course map editing would take forever since it reads from compiled data (or source scripts)... And also, it seems that you are going to release a new .dmi format, which basically will make my monthes of work useless -_-... Is there any way that I can get the new formats from you so I can provide acceptable linux alternatives, and/or is there a way I can prove that I can do what I claim?

I have been in and out of the byond scene since april 2001, and eagerly await the new byond.. But I guess my unnecesary comments about byond in the past gave me a bad impression -_-.. sorry if it did.. Well if you cannot give out the format, that is fine, I will once again decode the new format with my trusty khexedit and gcc tools.. But hey, theres no harm in hoping :)

Sep 26 2003, 2:30 pm (Edited on Jul 3 2004, 5:53 pm)
I've already figured out the essentials of the "4" format (the "3" format is old and obviously out of date).
All 2-byte or 4-byte values are in LSB, MSB order.

File header:

4 bytes:  04 "DMI"
          The "3" format is 03 "DMI"
1 byte:   # of directions in file (1, 4, 8)
2 bytes:  Palette size; color 0 is transparent
x bytes:  Palette entries (3 bytes each) in RBG order, not RGB
2 bytes:  # of states in file
x bytes:  Icon states
x bytes:  Mouse hotspots

State header:

2 bytes:  # of directions
2 bytes:  # of frames
2 bytes:  time delay (ticks)
1 byte:
  Bit 0:  Rewind
  Bit 1:  Movement state
2 bytes:   Length of name (including null)
x bytes:  Name (including trailing null)
x bytes:  Icons
          - First, by frame
          - Then, by direction (south, north, east, west, se, sw, ne, nw)
          - e.g., All dirs of frame 1 first, then all of frame 2...

Icon:

4 bytes:  icon ID
          Starts at 2 and goes up
          0 for transparent icons
2 bytes:  # of runs for run-length encoding
          This is 0 if not compressed

  RLE compressed:
    Starting at upper left, going to lower right, by row
    measure each "run" of solid color, up to 255

    n bytes:  Length of run (1 byte each)
    y bytes:  Color encoding
        x = bits per color (1 for 2-color, 2 for 3-4, 3 for 5-8...)
        y = (n+k)*x/8, where 0<=k<8
        (y must be an integral number of bytes holding an integral number of x-bit values)
        e.g.:
            x=8, n=51: y=51
            x=4, n=51: y=52*4/8=26
            x=3, n=51: y=56*3/8=21
            x=2, n=51: y=52*2/8=13
            x=1, n=51: y=56*1/8=7

  Non-compressed:
    Starting in the upper left and moving on by row,
    encode each color, x bits each

Mouse hotspots: (after all states)

1 byte: 02
3 bytes per icon:
   byte 2   byte 1   byte 0
  00000000 00000yyy yyyxxxxx

  x: Distance from left starting at 0; 0 by default
  y: Distance from top starting at 0; 32 by default

  Default 3-byte value is (0,32): 00 04 00

Lummox JR
May 29 2004, 11:56 am
In response to Lummox JR

Icon:

4 bytes: icon ID
Starts at 2 and goes up
0 for transparent icons
2 bytes: # of runs for run-length encoding
This is 0 if not compressed

RLE compressed:
Starting at upper left, going to lower right, by row
measure each "run" of solid color, up to 255

n bytes: Length of run (1 byte each)
y bytes: Color encoding
x = bits per color (1 for 2-color, 2 for 3-4, 3 for 5-8...)
y = (n+k)*x/8, where 0<=k<8
(y must be an integral number of bytes holding an integral number of x-bit values)
e.g.:
x=8, n=51: y=51
x=4, n=51: y=52*4/8=26
x=3, n=51: y=56*3/8=21
x=2, n=51: y=52*2/8=13
x=1, n=51: y=56*1/8=7

Non-compressed:
Starting in the upper left and moving on by row,
encode each color, 1 byte each

Mouse hotspots: (after all states)

1 byte: 02
3 bytes per icon:
byte 2 byte 1 byte 0
00000000 00000yyy yyyxxxxx

x: Distance from left starting at 0; 0 by default
y: Distance from top starting at 0; 32 by default

Default 3-byte value is (0,32): 00 04 00</dm>
Lummox JR


Well I was reading ur thing and decided too look at one of my own .dmi files and see if I can find each peice of the .dmi format and how it fits together and were it goes.

Every thing was going ok intell I reached the above part and got all confused. I understand the Icon ID im guessing it just counts up per icon state and such in the .dmi. The part I dont understand is bellow that. I think the .dmi file is compressed because in the # of runs for run-length encoding it has 47 as one of its bits. But from there Im just confused as I said earlyer.

Could you please explain what the other information is doing in morte detail.

Thank you for any help.
May 29 2004, 12:47 pm
In response to Green Lime
Non-compressed:
Starting in the upper left and moving on by row,
encode each color, 1 byte each


I was digging through this recently myself, and I think there is a bit of compression here. Rather than being '1 byte each', I think they still use the above compression formula to determine how much space they take up.

For example, if your icon uses 7 colors, that would give a formula of:

y = (n+k)*x/8 

n = 1024 // 1024 pixels in a 32x32 icon
x = 3    // 3 bits per color for icons with 5-8 colors
k = 0    // since the division works out nicely.

y = (1024+k)*3/8  // k will = 0
y = 3072/8
y = 384


So, rather than taking up a fully uncompressed 1024 bytes, the colors section will only take up 384 bytes. Each of the 1024 pixels will be assigned a numeric value based on it's color's position in the color listing at the beginning of the icon.

There are some cases I haven't figured out yet, and I haven't even tried to pull the colors out of that mess since I don't need them for what I'm trying to do.



May 30 2004, 3:07 am
In response to Flick
Flick wrote:
Non-compressed:
Starting in the upper left and moving on by row,
encode each color, 1 byte each


I was digging through this recently myself, and I think there is a bit of compression here. Rather than being '1 byte each', I think they still use the above compression formula to determine how much space they take up.

For example, if your icon uses 7 colors, that would give a formula of:

> y = (n+k)*x/8 
> 
> n = 1024 // 1024 pixels in a 32x32 icon
> x = 3    // 3 bits per color for icons with 5-8 colors
> k = 0    // since the division works out nicely.
> 
> y = (1024+k)*3/8  // k will = 0
> y = 3072/8
> y = 384
>

So, rather than taking up a fully uncompressed 1024 bytes, the colors section will only take up 384 bytes. Each of the 1024 pixels will be assigned a numeric value based on it's color's position in the color listing at the beginning of the icon.

There are some cases I haven't figured out yet, and I haven't even tried to pull the colors out of that mess since I don't need them for what I'm trying to do.




So with that formula your basically finding y = the number of bytes the encoding takes up. But what about the encoding its self. Is there a way too see what colors are in what pixel?

& instead of 1024 pixels you should use the run-length incoding they gave above for compressed icons. Right?

Thanks for any help.