TexturePacker Preview
Community Forums/Showcase/TexturePacker Preview
| ||
| A few weeks ago, I realized I really needed a good texture packer to combine a load of odd shaped image into a single texture so that I can get the massive speed boost you get from having everything on one texture. I couldn't find a program that quite suited my purposes. They either didn't export to 32-bit PNG or they didn't optimize the packing very well, and I was originally planning to update Jim B's ImagePacker to support 32-bit PNG, as the packing itself seemed good. Anyway, I decided it might be fun to write my own, and boy was I wrong. It was bloody horrible, but it was a great learning experience trying out various things until I got an algorithm that is really tight. I figured a good test would be to try it with some images from Filax's GUI, as they come in such a wide range of sizes and shapes that they're bound to be very hard to pack neatly into a texture. Indeed they proved very challenging, and pushed me to keep optimizing the pack algorithm over and over until I couldn't see any way I could have done it better by hand. And so, without further ado, here's a screenshot of the packed texture ( real size, but 256 color-ized so that no one nicks Filax's graphics and so that it loads fast on a webpage. )  At the moment, the application itself is a bit rough around the edges, strictly for personal use. But I'm thinking of doing it up a bit, adding support for a few more formats ( jpg, tga, perhaps BMP ) and selling it for a low price. It also exports an xml document with the packed texture which you can then use to access each image within your program. If I can find an XML module for BMax, I may even write a quick BlitzMax module to parse the XML and create a list of images and their pixel locations, and sizes on the texture. But you've got the XML document so you could use the packed textures in any language, any engine, you wanted. It supports variable sized padding already ( to avoid bleeding with texture filtering. I disable filtering for mine, but not everyone will want to. ) but if there are any must-have features you would like to see, name them and I'll see what I can do. |
| ||
| Dude brucey's got a libxml module ready to go! Ummm...dont remember the link off hand, I'll get back to you on that. But this is looking damned keen! |
| ||
| This looks sweet, must get me a copy when you release it. |
| ||
| Dont forget to respect bitmap alpha :) |
| ||
| This could be really helpful! Once it works correctly... ;) |
| ||
| Booticus: Thanks for the tip. I'll grab that and see what I can do. Tim: Thanks. Took me a while to get it as optimized as I wanted, but I think it's there now. Filax: Oh, no problem. It already respects bitmap alpha. I just exported the GIF without transparency because GIF only supports 1 channel alpha, which looks ugly on a forum. But if you export a PNG, it exports the alpha channel exactly as it is on all the base textures. Grisu: Eh? In what way is it not working correctly? I'm currently thinking that the demo version needs to be able to demonstrate how well it will work on the images you have. That way, if people try it and it makes a bad job of their images, they can contact me and I can see if I can revise the algorithm any further, and they can be confident before buying. So I'm thinking that a fully functional demo version which watermarks the output is probably best. |
| ||
| Ok, good call on Brucey's XML module, that's a very neat way to handle XML. I've rewritten my XML exporter to use his module instead. Shouldn't be hard to knock up a little BMax module suitable for whatever engine you're using when the app itself is complete. Beyond that, you'll have the XML, so you could really use it in any language, with any engine. In fact - although the application will be Win32 only, it could be used to produce textures for x-platform development. Also, thanks to Noel's devIL module, I've added export support for DDS Compressed Textures ( 5 varieties ) as well as TGA, BMP, TIFF, PSD and PSP. I think that covers all the possible export formats you could possibly want, in conjunction with the PNG and JPG exports which were already there. Now I might have a look and see about importing some or all of those formats as well as exporting them. Not sure how practical that's gonna be, but I'll give that a good try. What seems like a fair price for this, BTW? I don't wanna rip anyone off, but it's quite a lot of work coming up with a really solid packing algorithm that packs as tightly as this does, so I reckon it's saving you quite a bit of work. And again, if there are any must-have features you'd like to see, let me know before I release the beta. |
| ||
| I'd use this but I'm not too sure I'd want to spend much money on it when I can use the nVidia Texture Atlas tools for free and get the same results. |
| ||
| Hi, Looks nice. Did you try this: http://www.blitzbasic.com/codearcs/codearcs.php?code=1208 ? It should be pretty solid. |
| ||
| I currently have lots of my graphics in small seperate png's. Is it true that they take up more memory etc.? Some are down to 10x20 pixels etc. |
| ||
| @fredbord, that's sweet, thanks. |
| ||
| kronholm - if you are using blitz3d/blitzbasic or blitzplus and only using 2d commands (loadimage/drawimage) then it should not matter. It's not so much the memory that will be the problem but, in a 3d environment, the surface count with blitz3d, although I don't know anything about blitzmax so have no idea whether it would have an impact in that. |
| ||
| Fredborg: Nope, I didn't. I got to the part where it said it could waste a bit of space with different sized images and knew it wasn't what I needed. So I wrote what I needed. I currently have lots of my graphics in small seperate png's. Is it true that they take up more memory etc.? Some are down to 10x20 pixels etc. If you're using BlitzMax or any 3d accelerated 2d, you have 16x32 pixels because they're resized to power of 2. You don't use more memory by having separate images. Your graphics just take a lot longer to render than they would if they were packed onto a single texture. Combining images/textures into one single texture is one of the simplest and most effective ways to speed up any 3d or 2d-in-3d code, so that's why I wrote this for myself. Since there's not much interest in it, I probably won't bother putting any more time into polishing up the interface and writing documentation for it. Just thought I'd post here and see if there was enough interest to warrant releasing it. It'd be great if I could release it for free, but people expect a lot of support on free tools, and I'm not in a position to offer that kind of support unless it's at least bringing in a *little* money. |
| ||
| seams like a nice little program. id give people a little more chance to get interested, i dont think everyone has even seen it yet. |
| ||
| I wasn't too interested in this until I heard it helps speed up my 2D games XD Can you give us some examples on how you would use this? |
| ||
| seams like a nice little program. id give people a little more chance to get interested, i dont think everyone has even seen it yet. Fair point. I'll leave it a while and put the work in next week or whenever if there's sufficient interest. Can you give us some examples on how you would use this? Sure. Any time your game is drawing a lot of different images, there is a small delay as the videocard changes from one image to the next. You try to group your drawing commands to minimize this, but there's only so much you can do. So you take a series of images which are drawn together ( all background tiles, all character tiles ( animated? ) or all landscape textures ( 3d? ) or whatever and put them on one texture so that all drawing operations are done without the videocard ever changing the texture. Now that you've identified which images you want to draw together, you fire up texture packer and add all the images ( a folder-full at a time is probably easiest. ) Now you pick a border size ( 1 or 2 pixels should be fine ) and click on the pack button. TexturePacker creates a new texture, puts all your images on it as tightly packed as it can, and you're done. Now just export to PNG/BMP/JPG/DDS/PSD/PSP/TIFF and an XML definitions file. Now the XML file contains the original names of the images, and the x,y coordinates and width and height that they can be found on the new packed texture. So every time you want to draw an image, just draw the section from x,y to x+w-1,y+h-1 instead. I won't spend too much time eulogizing on the subject of speed improvements from single-texture or single-surface drawing ( in 2d ) and texturing ( in 3d ) because there are dozens of threads about it on here, but I've found it the single most effective speed boost you can get, on any engine, and probably even more so on Blitz3d. Hey, I wouldn't have spent three weeks figuring out pack algorithms if I didn't think it was going to make a huge difference to my GUI rendering ;) |
| ||
| I could definitely use your program. How about putting up a paypal donate link for people who want to show their support? |
| ||
| Yeah I second the Paypal thing. So you can buy a beer or something with it. I believe in supporting the community! Definitely interested in it!!! |
| ||
| Ok, I give in. I would pay up to $20 for such a tool. |
| ||
| Ditto. |
| ||
| @Gabriel ... it does look interesting however my level of expertise is some way of using something of this nature..... |
| ||
| I'd probably pay $20 for this, it would be really useful for 2D games and GUI work, especially if it spits out co-ordinates and has pre-written code to handle it. Random question: If I added or changed the graphics in the GUI and subsequently re-packed them, would I have to change my code or would the XML compensate for this? Also, would you do any examples in Blitz3D? I don't use BlitzMAX. |
| ||
| Random question: If I added or changed the graphics in the GUI and subsequently re-packed them, would I have to change my code or would the XML compensate for this? Assuming you use the XML output ( and that's the point of it ) then you won't have to change anything. Change the size, shape, etc of the graphics, repack them, get a completely different packed texture and your program doesn't care because you're using the locations and sizes from the XML file which has updated to match the new packed texture. Also, would you do any examples in Blitz3D? I don't use BlitzMAX. Examples? Sure. BlitzMax can have a proper module, because BlitzMax's inbuilt TMap is a perfect way of retrieving the data of any image from just the filename ( before it was packed ) but Blitz3d can't do this natively. But sure, I could knock up a quick example or two to show how it's used. |
| ||
| Two ways you could save even more space in your packed texture ... 1. Don't store an extra set of images if it is exactly the same as some other image but flipped. Horizontal and vertical flipping can be done in realtime. For example those arrow buttons. 2. Notice where some graphics are the same as other except for color tints - allow use of SetColor to tint the white graphic to make it blue/green, thus needing to store less gfx. |
| ||
| 1. Don't store an extra set of images if it is exactly the same as some other image but flipped. Horizontal and vertical flipping can be done in realtime. For example those arrow buttons. That would involve a per-pixel examination of every image which is packed, resulting in horribly slow packing. If you want this kind of optimization, I think it needs to be at a user level. 2. Notice where some graphics are the same as other except for color tints - allow use of SetColor to tint the white graphic to make it blue/green, thus needing to store less gfx. That would be very difficult to calculate, and would definitely involve even slower per-pixel calculations. You'd have to compare with every possible tint. So that's 16 million ( give or take ) checks per image and each one would have to compare every single pixel with every other image of the same size. That would take forever to pack. |
| ||
| This code : http://www.blitzbasic.com/Community/posts.php?topic=51647#576571 could be modified to work with the texture packer very quickly. |
   |