dc6 file format help

[smurf_wow]

hi, im working on a little gui converter for dc6 images (to more common image formats).

at the moment im just looking at single frame inventory graphics. some of them turn out ok, but others not so well.

im using similar code to paul's dc6edit.

The problem seems to be (in decompress_dc6_frame()) that the x value is getting too big. for images that are ment to be say 30 or so pixels wide, the x value sometimes gets up to a few hundred.

would anyone be able to explain the dc6 pixel format(the headers fine, its just the actual pixel data) in detail?

thanks.

[SVR]

[quote=smurf_wow";p="142909"]
would anyone be able to explain the dc6 pixel format(the headers fine, its just the actual pixel data) in detail?[/quote]

Basically ...

Code: Select all

c = nextbyte

if c  > 80h then skip  (c-80h)

if c == 80h then new line, each scanline ends with 80h.

if c < 80h then copy c pixels.

Sounds like your missing the end of line tag (80h).

[smurf_wow]

Sounds like your missing the end of line tag (80h).

well this is the code im using.

Code: Select all

// bytes is an array of bytes that holds the entire file
int index = 56; // first byte after the headers
byte curByte = 0, tempByte = 0;
int x = 0, y = 0;

for(int i = index; i < frameHeader.length; )
{
  curByte = bytes[i++];
	
  if(curByte == 0x80)
  {
    x = 0;
    y++;
  }
  else if (curByte > 0x80)
  {
    x += (curByte - 0x80);
  }
  else
  {
    for(int j = 0; j < curByte; j++)
    {
      tempByte = bytes[i++];
      pic.SetPixel(x, pic.Height-y, palette[tempByte]); // flip y so picture isnt upside down
      x++;
    }
  }
}

are "scanlines" just the lines of the image?

Im definatly missing something here...
if bytes > 128 are ment to skip (byte-128) along the x-axis, then for an image 30 pixels wide, shouldnt that mean the bytes should never have a value more than 158 (0x9E) ? (they do though, thats why im missing something )

when you "skip", do you skip over multiple lines? (ie change the y value)

i think im getting myself more confused that i need to be

[SVR]

First off, don't use length !
The length may go beyond the last pixel and BOOM ;-)

use ...

Code: Select all

 // watch out for struct size ! must force byte alignment

typedef struct {
   ...
   DWORD offset[]; // put zero size dummy array for frames
}fileHeader;

typedef struct {
   ...
   byte data[]; // put zero size dummy array for pixels
}frameHeader;

fileHeader *file = bytes;
frameHeader *frame = (frameHeader *) (bytes+file->offset[n]);

~...

byte *p=frame->data;

int y=frame.height-1;
int x=0;

while(y>=0)
{
    curByte=*p++;

    if(curByte==0x80) {
        x=0;
        y--;
    }else if(curByte>0x80)
        x+=(curByte-0x80);
    else
        while(curByte--)
              SetPixel(x++,y,color[*p++]);
}

Now you don't need to flip the Y in windows unless you use flipped DIB's.

The width may be any width. (although by default each block is max 256).
If you have solid pixels across 256 width you have...

0x7F xx xx xx xx ... 0x7F xx xx xx xx ... 0x02 xx xx 0x80

0x7F = 127 pixels to copy

You may have multiple skips in a line (transparent pixels).
You may have only 0x80 in a line. (blank line)

yes,Scanlines are just the lines of the dc6. (But you may have padding in other formats;-)

No you don't skip passed end of line.

If you're getting skips > width you are off count, bytes that big are
surely pixel data.

// bytes is an array of bytes that holds the entire file
int index = 56; // first byte after the headers

Problem! it may not be 56 bytes. The File header has variable frame pointers. To get the actual frame (block) data you need to add the frame offset to the start of the buffer.

Code: Select all

fileHeader *file = bytes;

frameHeader *frame = (frameHeader *) (bytes+file->offset[n]);

[smurf_wow]

i finally got it, thanks for your help.

it turns out my frame header was 4 bytes short, and that caused it to skip past the first several lines of image.

it seems this is the correct header. (im using C#)

Code: Select all

public struct DC6FrameHeader
{
  public int unknown1   ;
  public int width      ;
  public int height     ;
  public int offset_x   ;
  public int offset_y   ; 
  public int unknown2   ;
  public int unknown3   ; 
  public int next_block ; // byte offset for next frame
  public int length     ; // length of this block
}

[Adrian]

hm... mine is looking like this (Java)

Code: Select all

private class DC6Block {
	int unknown1; //flip?
	int width;
	int height;
	int xOffset;
	int yOffset; //from bottom border, not up
	int unknown2;
	int next; //pointer to next frame in file
	int length; //length of data
	byte[] data;
	byte[] termination = new byte[3]; //EE EE EE
}

so what is unknown3? do i miss something?

[Uzume]

[quote=smurf_wow";p="143075"]it seems this is the correct header. (im using C#)[/quote]

If you are developing in C#, I would be interested in exchanging code and co-developing. I am (slowly) working on a D2S editor in C# (eventually with stormless-MPQ, BIN and DC6 code).

[SVR]

Nah, there is no unknown03, the next_block field has multi-uses. The
block header is 32 bytes. The file header is 24 bytes. You are probably
missing the offset after the file header. The inv gfx have one block so
they will have one offset.

Code: Select all

typedef struct 
{
	long bFlipped;			// +00
	long width;				// +04
	long height;			 // +08
	long x;					// +0C - left
	long y;					// +10 - top
	dword unknown;			// +14 - 0 - unused ?
	union {					// +18
		short unk[2];		// 0x006f // 0x007c .. a8 ..
		long next_block;	// ignored / don't care
	};
	long length;			// +1C - ignored / don't care
	byte data[];			// +20 - pixel data follows header
} dc6blockheader;

typedef struct
{
	long version;			// +00 - 6
	dword dwFlags;			// +04 - 1 = CELFILE_SERIALIZED, 4 = CELFILE_24BIT
	dword eFormat;			// +08 - encoding format - 0 = 8 bit RLE/skip
	dword pad_bytes;		// +0C - EEEEEEEE or CDCDCDCD - not used/ don't care
	long nDirs;				// +10 - 1
	long blockcount;		// +14 -
	long offset[];			// +18 - after header are block pointers
} dc6header;

The fields I mark /don't care are ones I've changed and Diablo II doesn't complain.
Be careful using int types in your structure. They may not always be 32 bits.

[smurf_wow]

ahh ok, i didnt know about the offsets at the end of the main header.

in the language/compiler im using, int's are 32 bits, and longs are 64bits.

[Adrian]

what is

Code: Select all

dword dwFlags; // +04 - 1 = CELFILE_SERIALIZED, 4 =CELFILE_24BIT
dword eFormat; // +08 - encoding format - 0 = 8 bit RLE/skip

for?

[SVR]

[quote=smurf_wow";p="143125"]in the language/compiler im using, int's are 32 bits, and longs are 64bits.[/quote]

Cool. I was wondering when they'd get around to screwing up long's like they did int's

I haven't played with C# yet. I suppose I should get off my *u-no-wat*
and learn it ;-) Just the idea of interpreted languages bugs me.

@Adrian -
Not sure *exactly* but CELFILE_24BIT means the dc6 has RGB values instead
of indexes. Don't know if they work in D2. There are other flags but those
2 are the only references I found in code.
The encoding field allows for different methods. Probably supporting the
20/40 tags like the old CEL/CL2 format that dc6 was derived from.
(thats why they call it 'dc6' - Diablo Cel version 6 I suppose ;-) Changing
it will cause D2 to complain.

[Adrian]

well ... the best is if i ignore them and don't change them

btw
i'm pretty sure c# isn't interpreted, it should work the same way like java

[Joel]

[quote=Adrian";p="143197"]
i'm pretty sure c# isn't interpreted, it should work the same way like java[/quote]

which is interpreted too .... both languages use a Virtual Machine.

@Adrian : sorry to be long and looking liek I ignore you. I have several harsh problem right now that pevent me to give you this **** JAVA sources. I'll try to circumvent these asap. Don't slap me /o\

[Adrian]

afaik the vm compiles some parts of the bytecode dynamically (jit - just in time compiler)
maybe it's some kind of interpretation... but that doesn't matter so much in speed (like start of the vm and swing )

@joel
ok, just want to let you know i'm still interested in this files
if its just a problem of uploading the files i can provide you several ways and space for that