dmi format?

ID:133191
 
Feb 4 2009, 9:26 am
I'm analysing the metadata for .dmi png files right now in order to write a parser in Python. .dmi's are png's with their metadata describing how the png is split and what each slice is supposed to do.

# BEGIN DMI
version = 4.0
state = ""
    dirs = 4
    frames = 4
    delay = 1,1,1,1
    loop = 5
    rewind = 1
# END DMI


It seems to look like this. The topmost node contains information about the version. Then there is a node for each icon state. These nodes describe the number of directions(1,4,8), the number of frames, the delay for each frame column, how often the animation should be looped and whether the animation should be rewinded.

Did I miss anything there? Also, I can't seem to find the size of the slices(32x32 by default). Does anyone know how that is stored?
Feb 4 2009, 9:42 am
CIB wrote:
Did I miss anything there? Also, I can't seem to find the size of the slices(32x32 by default). Does anyone know how that is stored?

There should be 'width' and 'height' parameters in the file, at least when the size is anything other than 32x32.
Feb 4 2009, 9:55 am
In response to Tom
Where exactly in the file? I can't seem to find it in the metadata. This is what I get for my .dmi with 96x96 size setting:

Description: # BEGIN DMI
version = 4.0
state = ""
    dirs = 1
    frames = 1
# END DMI
Feb 4 2009, 10:29 am
In response to CIB
CIB wrote:
Where exactly in the file? I can't seem to find it in the metadata.

I'm sorry, I stand corrected. At one point we explicitly encoded the width & height but I realized it wasn't necessary. Those values are inferred from the size of the image. Specifically,

width = image width / total #frames
height = image height (DMIs save with their frames in a single row)

You can still enforce the width & height in your own custom PNGs by using the "width" and "height" keywords at the top of the meta data (underneath BEGIN_DMI, but before the states-- all states must have the same width & height). The only real value of this is if you want to import an image that has the icons displayed on more than a single row. In this case, setting a height of, say, 32 for a 32x64 image will cause the interpreter to find two frames, one in each row. But resaving this in the editor will put the two frames together in the top row (64x32).
Feb 4 2009, 5:41 pm
In response to Tom
Tom wrote:
CIB wrote:
Where exactly in the file? I can't seem to find it in the metadata.

I'm sorry, I stand corrected. At one point we explicitly encoded the width & height but I realized it wasn't necessary. Those values are inferred from the size of the image. Specifically,

width = image width / total #frames
height = image height (DMIs save with their frames in a single row)

You can still enforce the width & height in your own custom PNGs by using the "width" and "height" keywords at the top of the meta data (underneath BEGIN_DMI, but before the states-- all states must have the same width & height). The only real value of this is if you want to import an image that has the icons displayed on more than a single row. In this case, setting a height of, say, 32 for a 32x64 image will cause the interpreter to find two frames, one in each row. But resaving this in the editor will put the two frames together in the top row (64x32).

On this subject, I recently created a PNG image with characters arranged horizontally by ASCII value with a few extras(I.E. small HUD icons), and I recently attempted to stuff the DMI specification in the file comments to set the hotspot for the small HUD icons at the end of the file to use them as mouse_drag_pointers. I couldn't get it to work using this description tag:

# BEGIN DMI
width = 32
height = 32
version = 4.0
state = "95,0"
    dirs = 1
    frames = 1
    hotspot = 6,19,1
state = "96,0"
    dirs = 1
    frames = 1
    hotspot = 6,19,1
state = "97,0"
    dirs = 1
    frames = 1
    hotspot = 6,19,1
state = "98,0"
    dirs = 1
    frames = 1
    hotspot = 6,19,1
state = "99,0"
    dirs = 1
    frames = 1
    hotspot = 6,19,1
# END DMI


So this leads me to believe either PNG states aren't named as such internally, I'm missing an important part of the DMI specification, or I must define a "state" for each frame of the icon, and I'm leaning towards the latter item (which would kinda suck since there's a hundred 32x32 icon frames).