[SanyaWaffles]

This software is beta and in-progress coding-wise.

What is this?

I am developing a toolset for my graphics and sound conversion. I am trying to go vanilla as possible (don't ask why, it's nothing against eDuke32). Since I'm editing a ton of the graphics to start, hopefully to make a TC, I decided it'd be worth a time investment for me to code a C tool using FreeImage to convert PNGs to ART files and vice versa. I needed an excuse to learn C anyhow, as mainly I fare in VM bytecode languages like C# and Java and I want to learn more system languages like C and C++. I know tilefromtexture in the DEF files exists in eDuke32, but if I'm converting many of the ART tiles anyhow I might as well go vanilla. I tested this in eDuke32 but since it's vanilla-format ART files, I see no reason for it not to work in Duke3D for DOS.

I looked at existing code, specifically art2tga and tga2art and used some of it's Endian functions and structs and animdata parser - but not much beyond that. The concept was good - a tool that could convert ART tiles to tangible INI files and TGAs. But I found importing targas back in was shoddy at best. Still, that and bastART was the best tools I had to work with to see how ART files worked - as well as Ken Silverman's ARTFORM.TXT which allowed me to decipher the format itself.

The result? A simple command line tool that uses the FreeImage library, PNGs and is much more sturdy. Here's kind of a summary of what it does differently:

For one, it does all ART tiles in batch at the moment. I plan on implementing a single-file mode, but right now it batch converts all PNGs or all ART files at once from a folder to a folder. The reason for this is convenience on my part, but I plan on fleshing this out if there's interest.

Second, since it uses FreeImage as an image library, it doesn't require you to use just the PNGs it spits out - I've been able to swap out indexed PNGs. Any valid duke 3d paletted PNGs will work, even if they are not the same size as the original tile you replaced. It can also insert tiles not originally in the ART file. Just create an indexed PNG at the 0-based index and png2art again. I know though ART files have a cap limit on size (I think it's 512x512), that's not currently implemented because it wasn't in the original documents I had to work with. I plan on fixing that though if people show interest. I also plan on checking the palette of the PNG before converting. I might also find a way to parse 24-bit/32-bit PNGs that are close enough color-wise to the proper index.

And finally, this tool actually works. I tested it many times and it does what needs to be done. This release includes a couple Photoshop palettes compatible with making indexed PNGs (and can also serve as swatches for Photoshop, Flash), as well as a vanilla PALETTE.DAT. Careful though, it will overwrite both ways without warning, so use with caution until I can implement existing file detection.

It follows the same syntax as art2tga and tga2art for Animdata, which is stored as adata###.ini now.

Here's a link:

Download of initial version.

I initially wasn't gonna post it here, as it is a beta product. Constructively compliment, criticize, help me out - for I feel this tool could be useful for those who wish to use ART tiles and not tilefromtexture.

Documentation is included, read the README before using. Keep in mind it is very beta.

I'd post screenshots but there is not much to see at the moment, it being a command line tool. Source code is included. Requires FreeImage to compile, compiled using VS2010.

[Jimmy]

That's really cool, I'd definitely like to see some development on this.

[SanyaWaffles]

Captain Awesome, on 15 December 2011 - 12:42 PM, said:

That's really cool, I'd definitely like to see some development on this.

I have news! I am restructuring the functions and such so it's cleaner, commenting as I go along. I am also aiming to combine the two executable files into one, by using command line switches. I hope to have something to show in a week or so, still recovering from some surgery I had a week ago.

But still, glad you show interest

[Hendricks266]

Good work. I've been intending to do something like this for some time, but it looks like you beat me to the punch just a few days before I was to start looking into working on it. No worries though!

Perhaps we could collaborate as I was envisioning a complete replacement for EDITART, bastArt, and DukeResART as none of them do everything I want, they all have their own quirks and bugs. Command-line tools are an essential building block, but for the best work a GUI would be great. I was also planning to allow seamless conversion between tilefromtexture definitions to art files and back.

[SanyaWaffles]

Hendricks266, on 15 December 2011 - 10:18 PM, said:

Good work. I've been intending to do something like this for some time, but it looks like you beat me to the punch just a few days before I was to start looking into working on it. No worries though!

Perhaps we could collaborate as I was envisioning a complete replacement for EDITART, bastArt, and DukeResART as none of them do everything I want, they all have their own quirks and bugs. Command-line tools are an essential building block, but for the best work a GUI would be great. I was also planning to allow seamless conversion between tilefromtexture definitions to art files and back.

Thanks for the kind reply!

My motivation was EDITART didn't work on Windows 64-bit, which I use due to the nature of my workstation... bastART was aging significantly and used BMPs, which made transparency previewing guesswork due to two duplicate color entries, and DukeResART wasn't my cup of tea.

That sounds cool, the collaborating idea. I'd be willing to help this cause. While tilefromtexture is good for small replacements, for grand-scale TCs it's probably not that intuitive. Plus it allow some compatibility as ART tiles are guaranteed to work in all Duke ports.

Sadly, I don't know much about GUI programming for Windows or Linux outside of Java and C#, but I'm willing to help with the backend code.

Let me try working on my Command Line tools some more so we have some codebase to work with.

[Jimmy]

I wouldn't worry too much about compatibility across Duke ports. There really is no reason to use the other ports, except for playing multiplayer. It's not like Doom ports, where ya got many very nice ports that do some things here and there others don't. EDuke32 is all you'll get.

[SanyaWaffles]

Captain Awesome, on 18 December 2011 - 01:32 PM, said:

I wouldn't worry too much about compatibility across Duke ports. There really is no reason to use the other ports, except for playing multiplayer. It's not like Doom ports, where ya got many very nice ports that do some things here and there others don't. EDuke32 is all you'll get.

Gotcha, I now realize eDuke32 is about it for Duke, which makes it okay. I did come from ZDoom originally, which is practically a port people hail by but does many things Doom simply doesn't, making cross-compatibility basically a loss. Even ZDoom derived ports may not work entirely with one another.

Though, using ART files is still a good idea if you're just gonna replace nearly all tiles aside the sector effectors/touch plates/etc anyways. Which I plan on doing.

----------

I did write a similar tool in C# a while back, which parsed all .png filenames in a directory and popped out a .def file to be imported for 8-bit art, though it didn't do anything for animation/offsets. That's what inspired me to go ahead and try doing a C tool for actually creating art files. That and some people wanted such a tool.

Also, I found a possible "bug" in my code but it's not fatal in one sense, but one in another. The filenumber argument in the tools basically starts at zero. So instead of 20 for TILES000-019 you should simply type 19, but if you want to edit TILES000 only, type 0 only.

However, the fatal bug I fixed - bounds checking for the maximum number of tiles to be parsed.

There's also some prototype conflicts for my methods (and I'm missing some FreeImage_DeInitialise() calls, which aren't harmful with a Dynamic library according to FreeImage's documentation, but still I added those where needed), I have fixed those for the next release.

Also, I have a question: I acquired a Mac recently and tried porting the tools (command line only) using XCode and Command-line. It didn't work out too well due to my lack of knowledge of the Mac platform. Does anyone know how to make a proper makefile (I'm admittedly not that good at *nix programming) and how to import the header and library included at /opt/local/include and /opt/local/lib respectively?

[Hendricks266]

Kraigose, on 16 December 2011 - 04:28 PM, said:

While tilefromtexture is good for small replacements, for grand-scale TCs it's probably not that intuitive. Plus it allow some compatibility as ART tiles are guaranteed to work in all Duke ports.

Captain Awesome, on 18 December 2011 - 01:32 PM, said:

There really is no reason to use the other ports, except for playing multiplayer.

It doesn't matter if tilefromtexture is intuitive or not. (I think it is in all cases, it just currently is unmanageable on a large scale because of a lack of a good program to organize and preview the contents.) As Captain said, compatibility with other ports is not a concern whatsoever. In fact, EDuke32's multiplayer will get finished someday.

Kraigose, on 16 December 2011 - 04:28 PM, said:

Sadly, I don't know much about GUI programming for Windows or Linux outside of Java and C#, but I'm willing to help with the backend code.

I don't know a single thing about GUI programming, but I feel the need to learn. I talked about this with Plagman a while ago, and he said it might be best for me to link my nonexistent tool to the engine itself if I wanted to preview 3D models and textures like I was planning. (That's rather far down the line, but support for every def parameter would be great.) EDuke32 contains special JPEG/PNG/etc loading code written by Ken Silverman himself so your library might be some degree of a redundancy, yet we should definitely keep it because I doubt Ken's code can do all the manipulations FreeImage can, let alone save images. However, we should explore options.

I do anticipate this being quite a challenge, but I have encountered such things in the past. Right about a year ago at this time, I started and completed a program to organize my music with a lot of considerations about naming, moving, special file formats, and categorization, etc. (it's a lot to explain). I had only had about 4 months since beginning my first C++ class, and I knew nothing about object-oriented programming, yet I dove into TinyXML++ and after quite a challenge it worked. Now, looking back on it, it seems rather simple and easy to work with. Similarly, this summer I added a feature called modules to EDuke32 and I thought it was the most difficult thing I've done yet, but shortly afterwards it did not seem so difficult after all. My point is that if we persevere through coding a GUI even though we don't know how, when we're done it will be much easier for us moving forward. The same holds for anything in programming.

Kraigose, on 16 December 2011 - 04:28 PM, said:

Let me try working on my Command Line tools some more so we have some codebase to work with.

Keep in mind, my free time surplus expires in about two weeks. (Not saying I won't be able to work on it later, but this is the most fruitful time for a while.) Perhaps you should read up on a content version management system like Subversion (SVN). Duke4.net can host a repository for the project if you/we feel that's the best. They really are helpful for multi-user projects. (/glares at Deadly Kiss team)

Kraigose, on 18 December 2011 - 06:46 PM, said:

Though, using ART files is still a good idea if you're just gonna replace nearly all tiles aside the sector effectors/touch plates/etc anyways. Which I plan on doing.

I'm not sure what's special about the special sprites' art.

Kraigose, on 18 December 2011 - 06:46 PM, said:

I did write a similar tool in C# a while back, which parsed all .png filenames in a directory and popped out a .def file to be imported for 8-bit art, though it didn't do anything for animation/offsets.

Whenever I needed to do something like this in the past, I just type this in a command prompt window:

dir /b *.png >tiles.csv

From there I did some tricks with columns and find/replace to shape a working def file.

Quote

Also, I have a question: I acquired a Mac recently and tried porting the tools (command line only) using XCode and Command-line. It didn't work out too well due to my lack of knowledge of the Mac platform. Does anyone know how to make a proper makefile (I'm admittedly not that good at *nix programming) and how to import the header and library included at /opt/local/include and /opt/local/lib respectively?

I have occasional access to Macs but I don't have any experience with XCode. I can write a Makefile. I probably will need to because I build with MinGW/GCC.

[Jimmy]

Kraigose, on 18 December 2011 - 06:46 PM, said:

Gotcha, I now realize eDuke32 is about it for Duke, which makes it okay. I did come from ZDoom originally, which is practically a port people hail by but does many things Doom simply doesn't, making cross-compatibility basically a loss. Even ZDoom derived ports may not work entirely with one another.

Though, using ART files is still a good idea if you're just gonna replace nearly all tiles aside the sector effectors/touch plates/etc anyways. Which I plan on doing.

Yeah, I'm a big ZDoom fan myself. I post on the forums over there under the same cocky moniker. I'm a proponent of ART files because I'm really old school and I can't ever see myself leaving dear sweet EDITART.

[Hendricks266]

Captain Awesome, on 19 December 2011 - 07:21 AM, said:

I'm a proponent of ART files because I'm really old school and I can't ever see myself leaving dear sweet EDITART.

We'll work to change that. Keyboard shortcuts ftw?

[Jimmy]

Well, EDITART doesn't really have an interface if you think about it, it's practically all keyboard shortcuts.