----------------

Note, all numbers are in hexadecimal.

Header : 114 bytes

pos size meaning
-------------------------------------------------------
0000 4 version ?
0004 4 version ?
0008 104 zeroes
010C 4 # data-block headers
0110 4 ptr to where graphic-block headers start, always 0x114 ??
0114 60*x data-block headers start, x <=> # data block headers
0114+60*x ? graphic-block's start , x <=> # data blocks

-------------------------------------
data-block's (header, 96 bytes long)
-------------------------------------
pos size contain
-------------------------------------------
00 4 Direction ?
04 4 ?
08 4 x-pos
0C 4 y-pos

48 4 grafik-block start (absolute position)
4C 4 dataLen
50 4 #graphics-blocks in data-block

--------------------------------
grafik-block headers (0x14 bytes each)
--------------------------------
pos size contain
----------------------------------------------------------
00 2 relative x-offset from data-headers x-pos
02 2 relative y-offset from data-headers y-pos
04 2 00 00
06 2 00 00 (always ??), 04 04 i duriel.dt1 -> frame kan inte ritas...
08 2 value in torture.dt1 is always 01 10 for graphic-block 0 (only one checked)
0A 2 size of graphix block
0C
10 4 startpos of graphic pixels relativ to start of byte 0 in graphic-block 0
14 14 next graphic-block
14*x ?? pixeldata for the graphic-blocks

So, the file layout is basically like this:

|Header|data-block 1|data-block 2|..|data-block n|
|graphic header 1 for data-block 1|graphic header 2 for data-block 1|..|graphic header n for data-block 1|pixeldata for graphic-block1|pixel-data for graphic-block 2|..|pixel-data for graphic-block n|
|graphic header 1 for data-block 2|graphic header 2 for data-block 2|..|graphic header n for data-block 2|pixeldata for graphic-block1|pixel-data for graphic-block 2|..|pixel-data for graphic-block n|
|..|
|graphic header 1 for data-block n|graphic header 2 for data-block n|..|graphic header n for data-block n|pixeldata for graphic-block1|pixel-data for graphic-block 2|..|pixel-data for graphic-block n|

Some rules:
------------
* An "item" is divided into graphic-blocks and an "item" can also span over multiple data-blocks.
* Theres only one "item" in one data-block

* heres some code to plot a single block of pixeldata from a graphic-block, works almost every time...
First some variables...

data -> an array of bytes that contains the actual pixels
ptr -> a pointer that points to a specific byte in the array
x0,y0 -> where upper left corner of graphic-block is
x,y -> where to put next pixel on screen
t1,t2 -> data to decode
pal -> byte array containing the palette to use with plotting image, 768 bytes long (3 bytes / pixel)

x=0
y=0
x0 = data(0) + 256*data(1)
y0 = data(2) + 256*data(3)
Do While ptr < UBound(data) ' <= loop until we get to the end of the data, should probably check against sizeof graphic block (header offset 0a) but this seems to work to
t1 = data(ptr)
t2 = data(ptr + 1)
ptr = ptr + 2
If (t1 = 0) And (t2 = 0) Then ' New line
y = y + 1
x = 0
End If
If (t2 <> 0) Then
x = x + t1 ' t1 holds value to add to x-position
For k = 0 To t2 - 1 ' put pixels on screen
' Picture.Pset(x-pos , y-pos, color)
Picture1.PSet (x0 + x + k, y0 + y), RGB(pal(3 * data(ptr + k)), pal(3 * data(ptr + k) + 1), pal(3 * data(ptr + k) + 2))
Next
ptr = ptr + t2
x = x + t2
End If
Loop

Now, take gfx-block 0 :

code:

---

   0000 rel x-pos   : 0040 ( = 64)
   0002 rel y-pos   : 0040 ( = 64)
   0004 unknown1    : 0000 ( = 0)
   0006 unknown2    : 0404 ( = 1028)
   0008 unknown3    : 0001 ( = 1)
   000A blk length  : 00000100 ( = 256)
   000C unknown4    : 0000 ( = 0)
   000E startpos    : 000001F4 ( = 500)

---

I'm sure now, that the unknown2 is not a number in 2 bytes, but instead are 2 numbers : the position of the gfx-block in the grid. First byte is the x position, 2nd is the y position. The 25 gfx-block of this block have these 2 numbers ranging from 0 to 4, both. So it is ok with the idea of grid positions.

Now, here's a shema who represents in which "square" are the 25 gfx-blocks (from 0 to 24) :

code:

---

   |  0  1  2  3 4    (x)
---+-------------------
0  | 24 23 22 21 20
1  | 19 18 17 16 15
2  | 14 13 12 11 10
3  | 09 08 07 06 05
4  | 04 03 02 01 00
(y)

---

See ? they go from right to left, then from down to up, the exactly opposite way of common reading (but it's not surprising, Blizzard put big efforts in crypting the format of all their files. In the dc6, we draw from left to right, but from down to up, hence the y-offest which is not based on the upper-left corner of the image, but the bottom-left).

Now, here is another shema, with the summary of the "rel x-pos" and "rel y-pos" of each gfx-blocks (format is (x,y) in the shema) :

code:

---

   |    0       1       2       3        4    (x)
---+---------------------------------------------
0  | (64,0)  (80,8)  (96,16) (112,24) (128,32)
1  | (48,8)  (64,16) (80,24) (96,32)  (112,40)
2  | (32,16) (48,24) (64,32) (80,40)  (96,48)
3  | (16,24) (32,32) (48,40) (64,48)  (80,56)
4  | (0,32)  (16,40) (32,48) (48,56)  (64,64)
(y)

---

Seems strange at the first glance. But if we make a "virtual screen" and put this position on it, we obtain :

See ? the gfx-blocks are rotated by 45° right. Or better say "The final gfx is a bitmap in isometric-3d, which is divided in a 5 * 5 gfx-blocks". I didn't check, but I think the floor's tiles themselves are rotated too : note that these tiles are 256 bytes each, no more, no less, so no compression format in there. That should explain why I saw drawing bugs in some dt1, with cv5.2.

Another guess, which have nothing to do with the precedent explanation : in the "data-block's (header, 96 bytes long)", I think that the 2nd "0004 4 version ?" is not a value of 4 bytes, but instead are 4 flags. If it is set to 1, then we'll have to check the values of some byte. I saw a dt1 (the floor's lava in act4 if i'm correct), which have got all these 4 bytes to 0, except somes blocks ; when it is not 0, it is "00 00 00 01", and in these case, the byte at position 20 (hexa) in this header have a value, and not a 0. In fact, I'm thinking there are 3 numbers, which have some conections with animated floors : Heach of these number are 4 bytes. They are at position 18, 1C, and 20 (all hexa) in the header. Maybe a sort of number of frames, the code of the frame, and the time to wait ? Don't know.

Just 1 last thing : since I didn't test the level editor, I'm hopping I'm not telling things which are well-known. I only have all these ideas with a personnal dumping program, some papers and a pen, I never have a look of images. So this is only theoric for now, but I'll test it.

That's all folks.

Good Work Paul!

------------------
The frost. Sometimes it makes the blade stick.

Darkness Weaves

Some more info. I had some problems with the lava tiles. But I found it. In fact, there are (at least) 2 sorts of tiles : full-raw tile (as the above : 256 bytes each) and the other, coded as Clannad told it (variable size). Now I think I "master" the floor tiles :

It was long for me to code a program to obtain this, but here they are, these lava tiles. Each one of these "big" tile is in fact a combination of the 5*5 "smaller" tiles, as I explained 2 post above.

Now, more info I discovered : in the gfx-header, right before the lenght of the data, are 2 bytes. There are set to (hexa) 0001 if it is a raw tile (256 bytes, no zero in it, rotate by 45% right) or set to 2005, in this case it is a "common" tile : it has to be decode as Clannad said it (00 00 = new line, else 1st byte is a "jump" value ann the second the number of pixels to read, follow by the pixels).

Another piece of info : in the block-header are 4 bytes set to "00 FF 00 FF". Right after these ones, there are (at least) 25 boolean flags (folowed by 8 zero, maybe for other booleans of another type of gfx-block ?). I think they indicate if one can walk in the sub-tile (one of the 5*5 little tiles) or not. 00 means player can walk, 01 means he can't. I didn't check for all, but it seems it's that. it has nothing to do with the decoding methode of the tile (I was messed a long time with it, damn).

I wish to see some of the dt1 files and figure out their relation to the ds1 files.
maybe I can figure something out with looking at the dt1 files in a viewible form

------------------
Come stay a night at my Dragon's Inn

(link outdated)

near 450 kB, But in the future I'll drop it down. No time to do that right now.

You should use cv5.2, with the cvdt1.dll : you'll be able to see all the dt1 walls, but not the floors. My program is at the exact oposit : only the floors, not the walls. Launch "maggot.bat" : it will extract the floors in files like "block-001.pcx". If you want to use it for your own, look the .bat, you'll get the syntaxe. Just open dt1 files with floors. if not, you'll se a great pcx of ... grey (empty). It's in the very early development.

Forget that. Here's a exe I made, and which may help you (not for the gfx, but for some byte replacment, like the "no_walk" infos maybe) (link outdated) is just 30 kB.

You have to go in msdos tough. I don't make program for win, just msdos (shame on me). Quick exemple :

dt1info "my dt1 to test\this_one.dt1"

will produce the file "dt1info.txt" which is a dump of the dt1, with offsets in file, as long as what it understand. I think this one will come in handy. The gfx-header are almost well known now, so I suggest you concentret your time in the block headers. An exemple :

code:

---

00000174 block header 1
   0000 direction ? : 00000003 ( = 3)
   0004 ?           : 00000000 ( = 0)
   0008 x-pos       : FFFFFF80 ( = -128)
   000C y-pos       : 000000A0 ( = 160)
   0010 unknown     : 00
   0011 -           :                    00  00 00
   0014 num[0]      : 00 ( = 0)
   0015 -           :                    00  00 00
   0018 num[1]      : 05 ( = 5)
   0019 -           :                    00  00 00
   001C num[2]      : 02 ( = 2)
   001D -           :                    00  00 00
   0020 num[3]      : 00 ( = 0)
   0021 unknown     : 00 00 00 1E 28 28 00
   0028 no_walk     : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
   0041 unknown     : 00 00 00 00 00 00 00
   0048 data ptr    : 00002508 ( = 9480)
   004C length      : 00001AF4 ( = 6900)
   0050 # sub-block : 00000019 ( = 25)
   0054 unknown     : 00 00 00 00 00 00 00 00 00 00 00 00

---

And there's also this "unknown : 00 00 00 1E 28 28 00" which have some others bytes to figure out...

Now it's up to you.

edit >>> Yeah, I'm not a cerf anymore, now i'm a squire

code:

---

00000114 block header 0
   0000 direction ? : 00000003 ( = 3)
   0004 ?           : 00000000 ( = 0)
   0008 size Y      : FFFFFF80 ( = -128) ( /32 = -4)
   000C size X      : 000000A0 ( = 160) ( /32 = 5)
   0010 zeros ?     : 00000000 ( = 0)
      0014 num[0]      : 00000000 ( = 0)
      0018 num[1]      : 00000005 ( = 5)
      001C num[2]      : 00000003 ( = 3)
      0020 num[3]      : 00000000 ( = 0)
   0024 unknown     : 1E 28 28 00
   0028 no_walk     : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
   0041 unknown     : 00 00 00 00 00 00 00
   0048 data ptr    : 00000A14 ( = 2580)
   004C length      : 00001AF4 ( = 6900)
   0050 # sub-block : 00000019 ( = 25)
   0054 zeros ?     : 00 00 00 00 00 00 00 00 00 00 00 00

---

The num[0] to num[3] are more readeable (I don't knwow why I splited the 4 bytes just before them in 1, then 3 bytes : there are only dword data (4 bytes) in fact).
Also, when I checked the wall's dt1, I saw that usualy, but not always, the num[0] is equal to the direction. As for the no_walk data I put... I'm not sure how it works, because there are other value than 00 and 01, I saw 07 also... but I'm still thinking each byte is a flag for each sub-tiles.

I'll make it clearer later. I'll make a viewver this time. Since I can view floors and almost sure I can view walls as well. Maybe the viever will output one big pcx, with all the infos he can put into (like my dc6color.exe : text in the bitmap). It won't be ready for some hours. Maybe juste tomorow ? (apoc : a viever is not an editor, so you'll have to wait some more time to see that )

Oh, and I just checked your words on gfx colors in the resources section of the keep, very well written indeed. What can I say, my new items look great because of the info you posted in the forums... thx again man

Sorry just have to ask

------------------
Come stay a night at my Dragon's Inn

I was on my way to programmed this big extractor I talked of, then it was time so test some functions. I started with showing each block on the screen, and a a key get to next block... and little time after here it is : you can view the block and use the keyboard to choose the one you want, and even take a snapshot. It is limited, not an editor, not a convertor, but at least it can show you all the walls and floors there are in dt1. Read the readme.txt in the zip.

Just one question: how should I interpret the subtile flags (those sets of 8 bytes) that show in the tile info?

But as I wrote some post above, I'm sure they are relative to the sub-tiles. I'm almost sure each byte is a flag for each sub-tile. In a floor, there are 25 sub-tiles (5*5) so just look at the first 25 subtile flags. Strangely, even with the walls, it seems there is only 25 flags to check ???? In floors, you can see some 00 or 01 in there. 00 when you can walk on it, 01 when you can't. But for the walls, there are other values, like 07. So maybe you can "walk behind, so use transparency" ? Don't know.

Here is a (too big) image, which I made with the help of this viewer. I take all the screenshots and worked with them in psp, and here it is :

I just focused on this num[x] number, and now we have a little more infos, yet not complete.

------------------
"Get me a balrog attack-1 hand-to-hand animation, and I want it yesterday, the paladin is almost here!" ---> DMA1HTH @ offset 0006A480h. - Myhrginoc

I made a minor update of this prog. If you don't feel to go on the download of 450 KB again, you don't have to. I just change some text on the right, reformat the output of the "subT flag", bring down a little the horizontal axis, and write into memmory before I draw it to the screen (so even with my p166mmx it don't flicker), and put the right act5.dat palette (It was previously act4 rename act5, still wonder how I did this). Still, the sub-tiles flags are more readable now.

I saw some dt1 in expansion... This is not as easy as "floors" vs "walls" there are cliff which have big walls and some floor. There are very huge block, like the cliff, or the worldstone : they don't fit in the screen, so you can't have a complete view of it, I'll try to fix that later (maybe I'll implement an "E" shortkey, like "Extract" which will save a pcx with all the bitmap ?)

The worldstone is composed of 64 sub-tiles. Wow, and I was think no block could be more than 32 sub. Damn. Also, about this "sub-tiles flag", I saw 00 01 05 07... But NEVER more than 25 flags, even with cliff, or worldstone. That may indicate there are no distinctino between floors and walls : there may be always floors AND walls, and some of this 2 components are absent, while the flags are always refering to the floor ? I saw block with floor and walls to the up, or to the bottom (which again don't fit in the screen, sorry).

Just the exe and readme.txt (180 kB) : (link outdated)

All the package : (450 kB) : (link outdated)

Now, you can toggle a grid, and it's VERY usefull. Hit the G key to switch betwwen 3 grid mode. In addition, you can choose the layer mode : grid below or grid on top (L key).

I found myself only using a detailled grid under the drawing of tiles, or a non-detailled grid on top of the drawing.

I found some things. If the direction is 03 and the orientation is 00 then it is a floor tile with no walls at all (and the drawing is automaticaly reposition 80 pixels to the up). It will be centered in the screen.

If the direction is greater than 0F (so >= 10 in hexa) then the walls are drawing bellow. Other case = walls to draw to the up. The drawing will always be positioned appropriatly.

Enjoy and ... good "night".

EDIT>>> damn, just when I was thinking I found something... the town in act5 don't obey to the rule "if >= 10(hexa) then walls are upper" in this case they are some (not all) below. Darn it ! nevermind, it seems it works most of the time. I just re-upload the prog to don't draw too low the tiles when there are walls up.

EDIT 2 : the town floor problem is fix. when direction is 05 and orientation is 15 (hexa) this is now considered too as a floor, instead of having walls above. zips updated.

When the tile is animated : just after the first data of the block (direction) is an unknown1 data. The 4th byte of it is set to 01. Then, the num[3] (the 4th) is use to tell which frame it is.

In the exemple above, the first tile have
direction = 01000000 (hexa)
num[0] (orientation ?) = 0
num[1] (main index ?) = 20
num[2] (sub index ?) = 4
num[3] (frame ?) = 9

then we can find 9 other frames direction the same, and with num[0] thru num[2] exactly the same too, but with num[3] = 8 thru 0, hence the evidence of the frame number. i don't know if there is a speed info...

Check the BIG image above : they are more than 2 tiles with
   2
  22
   2
   1
and if you llok carefully you'l lsee some differences (use a zoom )