CAC - Tool for making celled images for T2D

#1 Thank you!

#2 David, try to link with allegro statically. If you use UPX the final exe will be around 120k if you just use core and loadpng functions (and use zlib / load png dlls). If you also link statically to zlib and libpng, it should be still smaller than including the allegro.dll.

#3 Just a thought: why don't you make the sprite assembler a console application so we can use the Torque GUI to call it on the command line. This would also have the added benefit of allowing simple batch jobs from the dos console.

#4 Whoops, my bad, put the debug DLL instead of the release version. I've updated the zip file now.

#5 I just wrote a command line tool that does something similar. You can either pass it a prefix (if your files are named image0000 to image00099 just pass image as first parameter) or a list of files (in the order wanted) and the tool will merge them to a single strip.

The outputfile will either be the prefix with an added _strip.png or if multiple files are given on the command line, it'll try to find a prefix based on the given filenames.

Source is included.
Do you think that a crop option would be useful as well (remove as much transparent space as possible for each image)?

www.steinke.net/strip.zip

#6 Thanks for that David

#7 @Lennart
Nice but really bad form :p

#8 Pardon?

#9 Something like this would make a nice addition to Chris Newman's Image DataBlock Tool.

#10 Good job Lennart and David, now we have options:)

This is exactly what I was thinking, combining a command line tool with the image datablock tool so we can make an "all in one" package. Torque (at least from what I've seen) isn't very good with bitmap manipulation, but forunately libraries like Allegro are. Lennart was kind enough to make his batch converter open source, so we can go on to make the Datablock source part of the output and do everything from the command line if we wanted to. We can also do this with the Torque GUI, whatever we prefer:)

#11 Well, if you want I can add a an option to output datablock definitions. I can also add an option to shrink the sprites to the smalles possible size.

But then the number of parameters to the cmd line tool would grow, a call would then look like this (for the prefix version):

split -o sprites.cs -n runningMan runner

The tool would then scan for runner images, sort them alphabetically, create a strip, search inside sprites.cs for a runningMan datablock and update that one.

If you'd use:

split -o sprites.cs -n runningMan -crop runner

The sprites would also be cropped to the smallest possible size before the strip is created.

I was also thinking of adding two more options
-a Sort images alphanumerically (default) sorts correctly if frame numbers start with 0
-n Sort images numerically sorts also if the frames are named frame_0 .. frame_99

On the other hand, that might be overkill, since one can simply define that frames should have leading zeros to ensure that they are sorted correctly.

#12 Both of these are good "art" tools.

I checked out Torques C++ code and don't see any way of doing this in the engine, unless you modify the code.

I thought about what both of the Matt's said and i don't have any plans to integrate Lennarts tool with mine (call it from mine).

Its my opinion that different types of tools should stay apart.
I see the T2D art flow going something like this:

1. create your sprites in what ever tool you like. Maya, 3D Studio Max, Paint shop Pro, Photoshop , Gimp, etc....

2. If you need animation frames, do it manually in the art tools (hard) or use these 2 tools (easy), Remember you will also have many single non animated images in your game too.

3. Put all of your finished art in the image dir.

4. Type out your datablocks or use a tool such as mine to create them for you.
Don't forget you have the full, celled and keyed types to deal with. And also even if Lennarts tool creates datablocks for you, you still have to deal with the single images yourself and their datablocks.

*edit: cleared this part up
@David and Lennart
One thing that will be cool is if your tools give an option to put a one pixel border around each image so people can use it with the keyed mode type in their datablocks. They would have less properties to define in their datablocks.

#13 Hmm, the tool I wrote is purely an art tool. (Actually, it's a modified tool that I was using with another game.) I really don't think in terms of datablocks and such when I am working on art, and I have no reason to incorporate this process into T2D itself (or use a T2D based tool to generate these images).

But then again, I am approaching this from the angle that my art pipeline is seperate from my T2D programming pipeline -- and I lump the datablocks in with the programming stuff.

However, if you guys want to use Lennart's tool to write out datablocks as part of some image tool, that's fine, but I'm done with my tool. (In case you were hinting I should add that to CAC. :) It does what I need it to do and don't plan on adding any more functionality to it. Someone else is going to have to do the "all-in-one" image combiner/datablock maker tool. ;)

#14 @David
So thats a no on the one pixel borders?

#15 Actually, I do add a one pixel transparent border already (just to make sure that no filtering problems occur). So, all I'd need to do would be to add a single command to clear the image to the border color.
If there's a generally agreed color value for that, I could easily add it. If not, I'd need to add a option parser (not a big deal, but I kinda cheated a bit when it comes to reading the cmd line args, so I'd had to change the filename code slightly as well).

I'm just not sure why that's needed? I mean, if you know the number of frames you've just used to create the final image and using the cell mode is all you need. Or am I missing something here? If so (and it's likely that that is the case, heh) what am I missing?

-Lenny

#16 The key mode reads in the first upper left pixel for the border color and reads to the right and down looking for your images. When you create your datablock for the key mode
it looks something like...

datablock fxImageMapDatablock2D(torqueRadioImageMap)
{
mode = key;
textureName = "common/ui/torqueRadio";
};

instead of ...

datablock fxImageMapDatablock2D(torquePaneImageMap)
{
mode = cell;
textureName = "common/ui/torquePane";
cellWidth = 20;
cellHeight = 20;
};

It just less things you have to remember when defining your datablocks.
The engine supports it, so why not have an option for it.

#17 @david
I ran into a problem with your tool.
All my images are in png format and it does not show them when i try to use the tool.

#18 I am having the same problem no .PNG files show and I get a load error on .TGA files. Is there requirements for the .TGA files? The example ones work.

#19 Ok I figured out the problem. It isnt the .TGA files its the program it seems that if the files are in any folder address that contains digits anywhere in it it wont load the files (e.g.C:\crusade_animation_compiler\sprite2) sprite(2) I erased the 2 and it loaded up the files perfectly. and by the way this thing rocks its just what I needed

#20 A couple things. I am not getting this video mode screen the readme talks about and just goes right to the image select screen. I dont get any other selection like feather and add trans Bkgrnd. It goes from image select to the image save and then thats it. It saves the file, but there is huge empty spaces on the right side of the outputed sheet. Any ideas?