Image Packer

ImagePacker is a tool for packing individual images into 1 larger image suitable for single-surface 3D sprite systems.
It can also be used to extract standard 2D images into your program.
The tool saves the images along with a definitions file which details each image name, it's position in the pack, it's width/height dimensions, and animation settings.



Features:

* Auto-pack - Just load your images and ImagePacker re-arranges them for you into the smallest size available.
Uses standard sizes such as 32/64/128/256/512/1024
* Clipboard copy/paste for quickly updating/editing the images.
* Basic image functions like flip/rotate/change color/resize
* Set animation parameters
* Code generation via templates
* Border settings (for 3D sprites)
* Save packs as *.bmp, *.png, *.tga, or *.jpg

Includes templates for generating source code suitable for 3D single-surface sprites and standard 2D images.
The 3D generated code uses SpriteMaster. This a single-surface sprite system loosely based on Sprite Control.
The 2D generated code uses ImageMaster. This lets you load one large image then extract each packed image as required.

You can download SpriteMaster along with examples and a sprite pack.

DOWNLOAD Image Packer


CREDITS:
Paul Snart - FreeImage Library

Surely this work of art isn't free? Everyone who ever wanted to do something like what Anthony Flack is doing should check this out as soon as humanly possible!

Thanks Rob. I was heavily inspired by an article Anthony posted on Blitzcoder explaining his methods used in Cletus.

TBH I have not considered charging for the app.
Just in case it bombs out on somebody who has paid for it.

If however anyone wishes to make a donation through PayPal then please send via this email address:

jb2000@...

Thankyou in advance:-)

Cool. It also handles icons thanks to Snartys FreeImage lib.

Fabulous!

Brilliant work!

Superb program Syntax! One small problem - when loading in png images, the alpha channel seems to be lost. Is there any chance of retaining alpha info at all?

Thats the next thing I need to work on.
I understand Pauls FreeImage lib retains alpha info so I'll look into it.

BTW: Just updated with keyboard shortcuts and a couple of new code templates.

This is sweet, this is a great way to be able to handle the old school bitmap fonts, they have on various websites!

Thanks alot!! Syntax you are the man, and to release it free, this is great, and the kind of support and community help I was hoping when I purchased blitz3d... You can be sure any and all tools, that I develop will be released free as well. Tools are to help each other, Games are okay to sell, but tools are meant to help out other fellow programmers.

Thanks again,

Ken

Excellent and lovely.

I've just finished playing with the latest FreeImage release and I have sussed how to both load/save alpha channeled images correctly. I have managed to retain the alpha channel as an 8bit depth bank for later manipulation.

Over the next week or so I will release a new FreeImage userlib with a few new commands.

Great news Paul. I'm hoping to get alpha integrated into ImagePacker with your next library update.

BTW: Have you made all of your variables local to prevent clashes?
You may remember an email I sent you ..
Here's some modifications I had to do with the last lib:

Restore Extentions
For FI_n=0 To 22 ; WAS 'n='
 Read FileEXT(FI_n)
Next
 
Function WriteCRC(Fl,Buf$)
 Local n
 Local C=CreateBank(4)
 Local B=CreateBank(4)
 etc ...
 
Function ComputeCRC()
 Local n,k,c
 c=CreateBank(4)
 etc ...

For other blitz users who want *.png / *.tga / *.jpg import/export I highly recommend Pauls library.
BlitzPlus users .. it's worth pointing out that there is no *.tga support as standard.

Oh, and thankyou all for your kind comments ;-)

Yeah, I'm going to tidy things up a great deal. To be honest it's still not generic enough. I think for the next release I will rework it from the ground up. And maybe change the decls to relect there dll conterparts better.

This rework should not mean much, if any changes, away from the include itself (other than replacing the .decls).

The main type will not change, but I'm hoping to rotate around this type more to save confusion and handle error trapping easier.

I will also ensure all var's are declared (Const, Global, Local) so any clashes can be identified easily. Plus, I'll name them all FI_

I'm working on it as we speak :)

Great work - just what I needed :)

But...

there is something that needs adding that could help alot! All it needs is an option to put pixel borders around some of the textures...

This would be a great tool to use for tiled based worlds that use 3D polys to display the tiles - but, the problem is when you put all your tiles into one texture the mip-mapping tends to bleed the sub-textures together. So, you have to add borders around the sub-textures so they dont bleed and push in the UV coordinates of the tiles.

So, an option that allows you to add a border on a sub-texture that repeats the edges would really help for the next version - I'd pay for it too ;)

Thanks for that information.
I can certainly incorporate a 'add border' feature. Or, should that be spacing to separate all of the images?
Is a 1 pixel border enough to avoid the bleeding?

I seem to remember a technical discussion regarding how mipmapping steals the edges. Any more information would be appreciated.

Maybe that explains why I get these edges appearing on rotated/resized quads:

Glad to hear you'd like to add the feature, I'll try and give you as much info as you need :)

There are two types of borders you could add,

1) For icons, just adding an empty border (either black for masked textures, or alpha=0 for alpha textures) around the edges, this is more important for alpha textures doing this will solve the problems in the images above. You probably know this already, but I'll explain anyway ;) The mip-maps are generated in blitz by taking the texture then making it 1/2 the size, this scaling involves a filter to blend the pixels, so if you have a lot of subtextures inside one big texture the edges of these textures will blend together :( So what your seeing the images above, are the edges of the other subtextures next to the one being displayed because its using a mipmap and adding a border will stop this.

2) For repeated tile based textures, the border should be a repeat of the texture edges - as if the texture was repeating for a few pixels at the edges. Its hard to explain this one, without drawing pictures :S

The amount of pixels to make border depends on the size on the texture and the number of mip maps you make - but generally you can get away with adding a 2-pixel border, it's always worked for me :)

Very generous of you to give this away for free!

Thank you :)

Please don't take this the wrong way -- sounds like a great app... but...

WE ALL should be careful not to use images that are the property of third parties (certainly not without acknowledgement) in screenshots of your product (free or otherwise)... The prominent images in your screenshot include: an AOL icon and icons from Panic software for Candybar and Transmit. AOL has a lot of lawyers on staff.

Note that this is not a problem if the screenshot gratuitously includes trademark or copyright images (e.g. the Apple logo in the top left of most Mac screenshots, or the Close Window icon in the top right of Windows Windows (which is actually licensed from NeXT and so, ironically, is also owned by Apple).

As developers of software, Intellectual Property is our livelihood and we need to both respect it and be aware of it.

Fair comment podperson.
I grabbed a load of icons during development.
Some free, others not. The copyright ones kind of slipped in! I'll clear them out asap.

Afrohorse,
Regarding the pixel border issue ...
Lets assume I have an image which has a red/blue edge as shown in the LEFT side of the diagram below.
On the right a 2-pixel border has been added:



1) Now, which part of the original image should be copied to the 2-pixel border? The red and blue lines or blue only?
2) Once saved, should I ignore the 2-pixel borders when setting the UV coordinates?

Thanks for taking the time out to do this :)



Ok, there are two types of 2-pixel borders you can do. The one for alpha textures should use the colour of the edges and expand them for a further 2-pixels, the alpha of these should be set to 0. Doing it this way will allow the texture to remain the same colour around the edges, but fade out nicely and not bleed with textures near by.

The border for repeated textures need the 2 pixel border to repeat the texture from the opposite side, so the border on the left is taken from the 2 pixels on the right of the texture, same for top -> bottom etc... The example I gave is a little messy looking but hopefully you can follow it.

The UVs should always map the same (shown by the black border), texture filtering always takes into account the surrounding pixels when it displays it on the screen. Bilinear filtering takes the surrounding pixels and blends them together, so the edges will always pull in the pixels next to them (Also, this is worst when it is using a mipmap, because the filter used to make the mipmap blends the edges too!). Trilinear filtering blends both the surrounding pixels and the mipmap levels together.

Individual textures are usually fine because the edges are automatically repeated in directX with blitz, but when packing many textures into a bigger texture the automatic repeat is no longer applied so you have to add the borders manually to emulate it - it's a pain - but its worth it! The speed gain you get by not having to swap textures or having lots seperate surfaces is huge! :)

Top diagram!
Ok, looks like I got my work cut out.
I'll be needing some option in ImagePacker like this then:

----------------------------------------
| Border   [O]None [O]Alpha [O]Repeat  |
----------------------------------------

At the moment there is no alpha support since BlitzPlus (which IP is written in) has no alpha handling.
Paul Snart (FreeImage library) is working on a set of commands for alpha handling so hopefully I can use those.

*UPDATES*

Image Packer:
* Border settings are in.
* Docs added (not quite completed though)
* A few tweaks here and there
* [?] help buttons on some of the windows

SpriteMaster/ImageMaster:
* Updated to handle border settings
* A couple of examples added

Image Packer
SpriteMaster & ImageMaster

this is excellent work Mr. Error!
Also the SpriteMaster lib does wonders.
Thanks for sharing this fine piece of work!

Yeh this rules