Now, infos that all users of islweo's ds1 editor will apreciate : In tristram, here are the meaning of the 7 layers ("map") :
* layer 0 : Walls 1
* layer 1 : Orientation of Walls 1
* layer 2 : Walls 2
* layer 3 : Orientation of Walls 2
* layer 4 : Floor 1
* layer 5 : Floor 2
* layer 6 : empty

The game draw the layers in that order : Floor 1, Floor 2, Walls 1, Walls 2. Look at that screenshot :

See the shadow on the wall ? there is a tile with 2 wall's layer to do this : 1st the wall itself, then the tree. hence the 2 layers of floors. If there was only 1 floor, we couldn't have the tree AND the floor at that particular tile (I mean "cell" in ds1's editor). Check the ds1's editor, layer 2 and 3 : this is infos for trees, while layer 0 and 1 are for the stone walls.

Now, remember the functions "nb layers = x2 + (x3 * 2) + x4" I talk about in the topic "more infos on ds1" ? In tri_town4.ds1 x2 = 0, x3 = 2 and x4 = 2. We have 2 layers of floors and 2 layers of walls. I'm sure that the x3 is the number of wall's layers (hence the *2 : 1 layer for orientation and another one for index of graphism itself), and x4 = number of floor's layers. Now, there are only x1 and x2 to be discovered.

Ok, need some rest, today was a good day.

This time I have draw as usual the tile with orientation 3, but right after, at the same place I draw the tile with orientation 4. If you check the ds1 editor, in the corner's layer, you won't see some cell with the prop1 equal to 4, despite in the dt1 there ARE some walls with orientation 4. So, when you see such a corner (prop1 = 3) in the ds1 editor, that means the game will draw 2 tiles :
* orientation = 3, main_index = layer0.prop3 / 16, layer0.sub-index = layer0.prop2
* orientation = 4, main_index = layer0.prop3 / 16, layer0.sub-index = layer0.prop2

1) In the "lvltypes.txt", we see that "act2-tomb" have all this dt1 :

* Act2/Tomb/Tomb.dt1
* Act2/Tomb/Columns.dt1
* Act2/Tomb/Things.dt1
* Act2/Tomb/Statuerm.dt1
* Act2/Tomb/Treasure.dt1
* Act2/Tomb/Stairs.dt1
* Act2/Tomb/Duriel.dt1
* Act2/Tomb/Tombsteps.dt1
* Act2/Tomb/Secret.dt1
* Act2/Tomb/Talrasha.dt1
* Act2/Tomb/Serpent.dt1

Now, open the "lvlprest.txt". "Act 2 - Duriel's Lair" have 639 in "dt1mask". In binary this number is 1001111111 (higher bits on left, lower bits on right). That's indicating which dt1 are to be take for this ds1 : there are zero at position 8 and 9 (counting from right), so we won't take the dt1 8 and 9, hence we won't take the "Act2/Tomb/Tombsteps.dt1" nor "Act2/Tomb/Secret.dt1" files. If we do take them, we'll have tiles's conflict, so follow this rule for the good choice of dt1.

2) Now, let's draw the duriel's lair as I said before (images have a zoom of 50 %) :

You see there are some problems. I found why, correct my prog, and get :

In fact, the main-index in the ds1 layer is split into prop3 and prop4. Prop3 is the low nibble of the main-index, and the prop4 is the high nibble (a nibble is 4 bits, or half of a byte if you prefer). This encoding reminds me of the one used in the d2s (savegame) files for items.

So, now, I'm almost sure the main-index is computed like that :

main-index = (prop3 / 16) + (prop4 * 16)

and the drawing is a lot more correct.

EDIT >>> I have just updated the tristram's jpeg. You don't have to look at it, because it is not perfect. There are some corners problems, the fence is really too much regular (I have to put some random variations into it), and there is still 1 blue square in the river. Still, it's improving. Now, an importnat precision. The formula is not exactly "main-index = (prop3 / 16) + (prop4 * 16)" : the prop4 can have value higher than 127, and it cause problems. So the correct formula is :

main-index = (prop3 / 16) + ((prop4 & 0x0F)* 16)

If you prefer a less "C language" notation :

high-nibble of main-index = low-nibble of prop4
low-nibble of main-index = high-nibble of prop3

I wonder what the high-nibble of prop 4 is... maybe a sort of a sub-sub-index ? maybe the "frame" in the dt1 ? Or just a flag... Have to check it.

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

Keep us informed, it is alway a pleasure to check out your progress

The random variations of floors / walls is not implemented, and there is still some problems with some ds1. read the Readme.txt and provide me with the results of your tests

EDIT >>> just a small precision : it's not really a scene maker but a viewer : you won't made any ds1 from this prog, you can only see a big preview of the ds1.

If a wall's tile have an orientation of 15, then the bitmap must be draw 160 pixels higher. When I mean higher, since the 0 of the bitmap is in the upper part, in fact the y of the drawing must be minus by 160, of course. With that, the buildings in harogath are correct too, as for larzuk (but there are still some problem in there). It does make sense to draw this bitmap higher for me, since they are objects above the floor. This is important for player / wall drawing priority.

I added 3 more .bat files : baal lair, worldstone, 1 variation of nilhatak temple (the biggest of all ds1).

Draw your wall as always (flat method), then each 2 pixels in X, move them all by 1 pixel in Y. You better have to draw your wall in true color format, then move the pixels, and only after convert the bitmap to 256 colors.

EDIT >>> This method is not the best for creating bitmaps of good quality, but at least it's easy to make.

Ok, so to put all the drawing infos in one place :

the tiles with an orientation of 0 or 15 must be draw 80 pixels lower than the other ones. That means that the floor and the gfx that are above them (roofs), must be draw lower.

Now, after this first offset, there is another. The data that I used to call "flags" in the dt1 is in fact at least 2 datas. The first 2 bytes are an Y offset for the drawing, and the 2 others are still flags. After the first 80 pixels lower offset checking, you must minus the resulting Y position of the drawing by the value of what I call now "Y delta" (berk), the first 2 bytes of the old "flags" data.

Now, you can have a pretty much more correct drawing of the roofs. But there are still problems in harogath.

Btw, I change a thing, but it won't be very interesting for you I think : now, instead of output the infos on the screen, it output them in the file stdout.txt. And I have reformated the cell infos, so it's easier for me for debuging, when I have to compare my prog's datas with the islveo's ones.

I think this not the only ones info the "flags" data contain, but at least there is :
* the environment sound of the tile
* a bit is set when the floor is animated.

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

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

quote:

---

Originally posted by Olorin:
Zehr kewl. ANd don't worry, folder directories with spaces in their names DO work. Now, need to view more pcx...

---

Just a tought I have : If you want to save some time in the creation of the .bat, you can put more than 1 command line in the bat. So, let's say you make a .bat for all the town, or for a zone of an act... The bat will make a pcx, then the 2nd, and so on ... that can save your time, by not copy / edit ALL the .bat, as I said in the readme.txt.

What sort of output do you want ? For easier readibilty, I think there will only be the interesting data when in excel mode (not the current output).

Let's say 1 line per block, a fix amount of column for the infos of the block, then a variable ammount of columns : a group of columns for each sub-blocks.

Problem : there are dt1 with more than 60 sub-block (like the worldstone), and then with 9 columns per sub-blocks, that will create near 600 columns, too much for excel.

How do you want to manage this ? Just tell me, I'll do it.

EDIT >>> I can even make a first line with the header's infos, then I skip a line, and then each another line is for each sub-blocks ? I can also provide some "title's line", I mean a line with the description of the column, 1before the header's info, then another one, before the sub-blocks. But will it fit your needs ?