Topic: Tile Slicer 1.0

[Revned]

Here it is, featuring a fancy new GUI. Well, sort of fancy. It should work fine if you have JRE installed; just double-click the JAR file. Tell me if you find any problems, I only briefly tried it in Windows.

[Maxim]

A few technical questions:



1. What benefits does JAI give you (apart from a TiledImage class with handy methods)? Is it faster than the "old way" with BufferedImages? The extra 2MB is a bit heavy...



2. Does your fancy tile hash work better than a simple pixel summation? Although a few shifts and xors probably costs about 1 picosecond more runtime so it doesn't matter much anyway.



I made a load more mods to the "old" slicer, including:

- making a Tile class to make all the slicing logic a lot cleaner

- implementing a derived Tile class that can handle flipped and rotated tiles, mainly for my tile applet but also useful for reducing the total number of tiles spat out

- making a "map cleaner" mode that fills in colour-keyed (eg. #ff00ff) "holes" in your map with the best match from all the other tiles in the map (very useful for getting clean edges on "diagonal" maps and also removing sprites)

- making it name the sliced tiles according to the number of times they appear on the map (eg. if tile 10 appears 3000 times it'd be 003000_10.png) which allows you to see which tiles need attention (normally the ones with only 1 or 2 appearances)

So:



3. Do you want some of my (hugely messy) code to do with as you wish?

[Revned]

1. It was handy, and it was already installed on my computer. I had to add in the libraries because it wasn't working with Windows. If you're on Mac (and maybe Linux) you should be able to delete JAI from the lib folder.



2. Yes, it does. I tried it with some very large images and got no collisions, whereas your summation had lots. For example, if you have an image that is half black pixels and half white pixels, yours will have the same hash no matter how they are arranged. This one is based on CRC, which is a good hash. Yours fell back on the pixel-by-pixel checker if the hashes were the same, which really slowed things down. Since this is such a good hashing function, I just got rid of that since I'm confident error will be minimal.



3. Sure, why not. I was going to do both of the first two on your list, but I ended up doing other stuff instead. I'm not sure I understand what the 3rd one on your list does.... I don't think the last thing would be something I would want, but I did consider having it output a little report in a text file with some statistics.

[Maxim]

Not having a pixel-by-pixel fallback will break your code at some point. Hashes are by nature prone to collisions. If your hash is good, the pixel-by-pixel check will rarely be used anyway.



By making it shift and XOR you make the result sensitive to pixel ordering and also more likely to use the full range of bits, so on reflection it is totally better than my hash function.



The most useful line of code in any Java Swing program:



UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());



I'll send over some of the other stuff when I get a chance. My coding computer's out of commission at the moment.

[Revned]

Well, yes, I know it's not infallible. But like I said, it looks good enough to trust. But, it seemed to me as if every time you found tiles that were in fact identical, your code would run through pixel-by-pixel just to make sure it could trust the hashes.



I've never used Swing before, so I apologize if my GUI code is bad/confusing. I hacked it together pretty quickly.

[Maxim]

My point is that you shouldn't trust it, ever. A crude test suggests it roughly doubles the slicing time to do the full check, and when that's a matter of 15 seconds or so on a 4096x4096 map, it's not the end of the world.

[Revned]

You're right. I guess I thought it would be worse, but since I'm already running through all the pixels once to get the hash, going through again to check would only double the running time. I'll fix it for the next release.

[Revned]

Well, I did a bunch more work on it. I promise I'll work on Tile Splicer soon. Changes:



Lots of internal restructuring

More options in the GUI

Now has both a GUI and command-line interface

Seems to handle bigger images without running out of memory

Tile statistics (just the number of occurrences of each tile)

Got rid of JAI dependency



And the link:

http://revned.googlepages.com/TileSlicer1.1.zip

[snesmaster]

Hi, I downloaded Tile Slicer 1.1 and cut up some maps and replaced some tiles.  That worked great.  Now I want to rebuild the big image with the tiles I replaced.  After all that work I found I can't do that with this program.

Is there a new version of this that lets you rebuild the image?  Without that feature, it severely limits the usefulness of this program.

[Revned]

There was a companion program for that, but I don't know where it went. I had grand plans for this, but I haven't touched it in three years. Maybe I'll revisit it sometime in the near future.

[snesmaster]

If you find that program let me know.  I did find a temporary solution.  I just loaded up the .html file that puts all the tiles together and take screen shots of that page and use that to rebuild the map in only a few screen shots. 

Thanks for making this program.  It is useful for R.C. Pro-Am where the levels are exactly the same, except for different tree and bush sprites.