A possiable new tool for ReBUILD people...

[Corvin]

In addition he had to offer this:

Well than there should be 2 tools.

1 to scan all the ART files, SURFACE.DAT and VOXEL.DAT file(s) to generate a definition script.
The other one would only read the script and then adds the tiles and properties.

So basically there will be a project folder with the separate tiles (GIF) and a script file.

[Corvin]

I now realize there maybe more work in programing needed tool(s), you still can say you don't want to do it.

I was unaware at the time that more parameters where going to be needed.

[Elric]

Heheh Indeed, it's more work that a simple ART diff program. A few randomly ordered thoughts off the top of my head regarding your requests:

• I won't support the GIF format as it would require more work than supporting the TGA, PCX, and BMP formats combined, with no real benefits. I can probably add PNG support using an external library if you really need a compressed format.
• I don't know the format of the SURFACE.DAT and VOXEL.DAT files, so until I find some documentation and/or sample source code about them, I can't promise anything.
• Taking images to build an ART files is what the Tga2Art tool does. I admit that it could definitely use some upgrades and improvements though

Maybe I could start with a simple artdiff clone and we can gradually improve from that.

[Corvin]

Do what you think is easiest of course.

My friend had this to add:

Well, It doesn't have to be GIF of course, the formats that he mentioned like TGA and PCX would be fine too.

Furthermore, the SURFACE.DAT file is really easy; there's 1 byte for each surface type so a total of 6144 bytes.
There are 14 types in total:

0 = None
1 = Stone
2 = Metal
3 = Wood
4 = Flesh
5 = Water
6 = Dirt
7 = Clay
8 = Snow
9 = Ice

10 = Leaves
11 = Cloth
12 = Plant
13 = Goo
14 = Lava

VOXEL.DAT works as follows; 2 bytes represent 1 VOXEL ID, and the address divided by 2 is the TILENUM

The byte pair of the address is in the lobyte/hibyte order.
So for example (in decimals): address 1036 has a value of 38
1036 divided by 2 = 518 ---> this is the TILENUM and 38 is the VOXEL ID

[Corvin]

Is there any progress on this tool(s)?


Also my friend wanted to stress this point:

I hope those extra parameters (voxel id and surface type) will be added later on because that is something typically needed for Blood, TileNum+VoxID+SurfaceType should be defined at the same time since they all go together and it provides a really great overview (which is lacking at present time, both ID and Surface have to be set with ARTEDIT which is completely separate from adding tiles to an ART file)

[Elric]

No, I haven't started working on it. I'm in the middle of a very busy period at my work, so I doubt I'll be able to spend some time on this for several weeks.

[Corvin]

Okay.

Here's some text about a similar tool to Duke's ARTDIFF(1999), it actually predates ARTDIFF by a few years(1996). Unfortunately I wasn't able to get the download.
The file name is: DDF100.ZIP I'm hoping this text will help you out....



What is a DDF file?

DDF stands for Duke Distribution File. It's a proposed new way to distribute duke maps. Because of how DUKE is designed (the .ART files in particular) it's preaty damn tedious to include graphics with your maps. DFF solves all of this.

The biggest problem is, that you would have to include a custom TILESxxx.ART with your map... the user would then have to copy that in to their DUKE3D directory. Of course... if there were any other custom ART files they would either be copied over or rendered useless.

DDF overcomes all of these issues. First off DDF is a librarian that manages your .ART files automatically. When you process your map, DDF scan it and maps out what artwork is need. It then extracts that artwork and stores it in the .DDF file with you map. When a user runs UNDDF, the utility takes that information and inserts the new artwork in to your .ART files. DDF uses a CRC system to make sure it only inserts new artwork which allows you to install many, many maps all with their own artwork, and never have to worry about switching .ART files again.

[Corvin]

@Elric any news or progress on the tool?

[Corvin]

Hey Elric. Do you think you'll ever get to making this tool?

It's alright if you changed your mind, I'm just wondering.
It's believed to be the last tool needed to shrink the size of a add-on, also shrink the size of current mods.
Plus it's would be very helpful with smaller projects too.

Please let us know where you stand, thanks so much for ReBUILD!

[Elric]

The short answer is no. First, I don't find the time to work on many things I would like to work on these days. And second, the tool you described to me is non-trivial to develop (meaning more that a couple of hours of work), for something that doesn't seem important to me (saving some MB of data, given the current hard-drive sizes and internet download speeds nowadays...).

So unless I really have several hours of time to waste ahead, which frankly won't happen, I highly doubt I will ever start working on this tool.

[Corvin]

Okay, thanks for at least considering it and thanks for the recent reply.

[Corvin]

Well this isn't going to free up any of your time but,

How about improving the tga2art program so that we can have parameters:

TOOL [tilenum] [filename] [surfacenum] [viewtype] [VOXELid] [ANIMtype] [ANIMlength] [ANIMspeed] [Xoffset] [Yoffset]

Also to load these values from a definition script file. So basically there will be a project folder with the separate tiles (TGA or PCX) and a script file.


What you think Elric?

[Corvin]

I have this other idea about adding art and voxels with a few parameters. It's very simple:
In the WORKFOLDER there's a KVX and PCX file and a SCRIPT file that looks like this:



"MYVOXEL.KVX", 100, 1
"MYVOXEL.PCX", 4608 ,3



100 = voxel ID
1 = spinvoxel flag; 0 is normal, 1 is spin
4608 = tilenum
3 = surface type


The tool should read all the SCRIPT files to compile the voxel definitions into a RFS file and adding the PCX and the VIEWTYPE to the correct ART file and the SURFACE TYPE to the SURFACE.DAT file

Now a modder can easily add or delete individual items.







here's some additional text to make it more clear:
=============================================

After compiling, the RFS file script looks something like this:



RESOURCE "myvoxel.kvx" AS 100;
RESOURCE "another.kvx" AS 101;
RESOURCE "thethird.kvx" AS 102;
;

the last ; is important, the text in red are the parameters from the previous script for a single voxel model and screenshot

the SURFACE data is just 1 byte for each type and its position in the SURFACE.DAT file equals that of the TILENUM
the VIEWTYPE must be written in the ART file, it's the high nybble of the 4th byte in the properties table.