[PC] Moorhuhn Adventure 2 ._img format

[MaxBOOST]

Tried everything I could. Even tiledggd, and all i could get was the color palette being big endian, 8x2 tile size, 4 bytes per color, RGB Order, and it starts at offset 0x50. Any Help ?

objFlugzeug.7z

Edited March 14 by MaxBOOST

[BloodRaynare]

Can't download your sample file.
It trips my Windows Defender for some reason.

[MaxBOOST]

1 minute ago, BloodRaynare said:

Can't download your sample file.
It trips my Windows Defender for some reason.

i just zipped it as a 7 zip. Let me try it as a regular zip

objFlugzeug.zip

[piken]

> color palette being big endian ... 4 bytes per color, RGB Order, and it starts at offset 0x50.

That sounds reasonable, given there are exactly 256 entries starting from 0x50. The left image is {R,G,B,X} order, and the right is {B,G,R,X} order. Do you know what the expected target image looks like?

Then just after the palette comes some directory of 17-byte records with increasing uint32le offsets (008Ch, 0118h, 011A, 0230h...), presumably to the start of each frame (too small to be a byte offset to the frames given the frames appear ~6'000 bytes apart). I've no idea what the A0, 8C, and 01 mean, but they don't change:

Next comes an array of at least 70 uint32le offsets, which match pretty nicely to the distances you see between frames (e.g. 8611 - 2574 = 6037):

Then finally comes variable width frames of 8-bpp pixel data, with interesting divisions between each one that might be a header for that frame:

TiledGGD is not going to help with compressed graphics, as it displays linear bitmaps and tiles. This might be a simple run length encoding, or it might trim the edges (some games trim the translucent left and right side of each row, storing a count instead - example), or it might be more advanced. If you can find the matching graphics in their decompressed state (in RAM/VRAM), you could compare them to these and glean some insights. 🤔 (deferring to knowledgeable others for analysis)

Edited March 14 by piken
Fix undesirable auto-inserted smiley

[MaxBOOST]

6 hours ago, piken said:

> color palette being big endian ... 4 bytes per color, RGB Order, and it starts at offset 0x50.

That sounds reasonable, given there are exactly 256 entries starting from 0x50. The left image is {R,G,B,X} order, and the right is {B,G,R,X} order. Do you know what the expected target image looks like?

Then just after the palette comes some directory of 17-byte records with increasing uint32le offsets (008Ch, 0118h, 011A, 0230h...), presumably to the start of each frame (too small to be a byte offset to the frames given the frames appear ~6'000 bytes apart). I've no idea what the A0, 8C, and 01 mean, but they don't change:

Next comes an array of at least 70 uint32le offsets, which match pretty nicely to the distances you see between frames (e.g. 8611 - 2574 = 6037):

Then finally comes variable width frames of 8-bpp pixel data, with interesting divisions between each one that might be a header for that frame:

TiledGGD is not going to help with compressed graphics, as it displays linear bitmaps and tiles. This might be a simple run length encoding, or it might trim the edges (some games trim the translucent left and right side of each row, storing a count instead - example), or it might be more advanced. If you can find the matching graphics in their decompressed state (in RAM/VRAM), you could compare them to these and glean some insights. 🤔 (deferring to knowledgeable others for analysis)

You are most likely correct. The game does use RLE for most of its files. Issue is I don't know how to decode that RLE. And i do have an idea of what the image might look like.

[MaxBOOST]

Can anyone help me with this please ?

[MaxBOOST]

ok so i got some help from a friend and dug deeper, and he told me some stuff:

 

It doesn't seem like RLE per se.

The header encodes two pointers paired with counts which could be crucial. You might find these starting at offset 0x38. It's 4 uint32s. Pointer, Count, Pointer, Count.

The first pointer will point to what seems like a list of rectangles. The rectangles are 4 uint32 (left, top, width, height) and then a uint8 (looks like a bool). Amount of rectangles matches the associated count from header.

The second pointer from the header will point to the section that immediately follows the rects.

This section then again encodes yet another list of pointers. Amount of these pointers matches the associated count from header.

These pointers each point to the start of the metadata section for what I presume is an animation frame/sub texture.

These metadata sections seem to look like this:

2x uint32 describing the dimensions?

0xFF00FF00

uint32 that seems to be width x height? But it doesn't always match up

unknown uint32

6x uint32 that seem to encode some unknown ordinal values (0, 1, 2, 4)

uint32 pointer to start of some image data for this particular sub texture, usually directly adjacent

There are some weird bytes injected in the image data occasionally that I cannot quite reason about at the moment. For square textures (especially without more subframes), it always seems to be two bytes after one row width... It could be some form of RLE because their frequency changes in other files but it's quite weird.

[MaxBOOST]

ok so we analyzed the file again, and it turns out it's not rle at all, but rather it trims the edges.

but i need anything i can use to convert them, even if it's a quickbms script.
I tried doing it myself, but i couldn't. That's why i am asking here

[piken]

Aha, one of my earlier theories 😉 (https://reshax.com/topic/345-zenonia-pzx-file/#comment-1150).

 

> And i do have an idea of what the image might look like.

Sharing a sample or screenshot of the rendered image would help folks to help you.

(I am interested from the puzzle point of view, but my time is already allocated the next week 🥱)

[MaxBOOST]

15 hours ago, piken said:

Aha, one of my earlier theories 😉 (https://reshax.com/topic/345-zenonia-pzx-file/#comment-1150).

 

> And i do have an idea of what the image might look like.

Sharing a sample or screenshot of the rendered image would help folks to help you.

(I am interested from the puzzle point of view, but my time is already allocated the next week 🥱)

sure, thanks for the tip.

anyways here, it's a vertical sprite sheet with a pink background that contain the images of a plane. these are some of the sprites i managed to take screenshots of.

[MaxBOOST]

9 hours ago, MaxBOOST said:

sure, thanks for the tip.

anyways here, it's a vertical sprite sheet with a pink background that contain the images of a plane. these are some of the sprites i managed to take screenshots of.

cuz when my friend looked at it, he mentioned how he found this:

one weird byte
Image data
two weird bytes
Image data
two weird bytes
Image data
etc....

so yeah we're pretty sure it's that.
the image type used by that game is... weird... to say the least.

[MaxBOOST]

ok, so i am attempting to write a bms script myself.

endian little
idstring "/x01"
get spriteAmount long
get imageWidth long
get imageHeight long
get unknown1 long
get unknown2 long
get unknown2 long
get null long
get null long
get null long
get PalettePointer long
get PaletteAmount long
get null long
get null long
get BoundingBoxPointer long
get BoundingBoxAmount long
get PointerListPointer long
get PointerAmount long
get null long
get null long

this is what i got so far.

EDIT: decoded all the header.

ok so the pointer list pointer points to the pointers that point to each frame's metadata

Edited March 24 by MaxBOOST