Related links: [Dwarf Fortress] [Map Archive] [DF Wiki]
Last updated February 28, 2008, for version 3.3.2 for .NET and Mono 1.2.6+. (The Java version is obsolete - use 3.3.2 with MONO if you can't use the .NET version). 3.3.2 produces significantly smaller filesizes than previous versions (if you allow tile identification to proceed, and if it finds your init file and font).
This program was written in C# (mainly because I, having used both it and java for years, prefer it over java and think it is a better language, with better IDEs), and so it requires at least either the .NET Framework 2.0 to run, or MONO.NET as an alternative. If you are using Mono, you'll want to run it with 'mono --debug DwarfFortressMapCompressor-3.3.exe' or whatever the exe filename is (the version may be newer). The --debug is so that it'll show a stack trace if it crashes. Note: The integrated flash map viewer will NOT work in Mono because the flash control is activex-based and mono can't handle that.
The DF Map Compressor is a program I made to encode Dwarf Fortress fortress or world map images into a much smaller format than is possible with normal image formats. Here's a quick summary of how it works: It determines the size of your tiles from your DF font file (or asks you), splits the map up into tiles, identifies duplicate tiles (including very similar ones with slight color differences - the color sensitivity can be increased now if your maps have an abnormally large color variance, and as of 3.3 it will generally notice this and prompt you), writes out every unique tile image, and then writes out a list of ID#s for each tile position which points to the tile image for that tile. What it outputs is piped through a compressor (LZMA (for df-map) or zlib/deflate (for fdf-map)) to compress it further. The file which it writes out is usually less than 100 KB in size (Or was in the 2d version. The size now varies wildly depending on the size of the area you embark to and the number of layers you write out. I have a 3x3 22 layer site that's 98 KB, but my 6x6 site with all layers comes out around ~250 or more KB). (By comparison, a PNG of the same map can exceed 2 megabytes, depending on how well you compress it, whether you change the color depth, and whether you are using a graphical tileset or detailed font) Version 3.3 has decreased filesize yet again (to 63% of the best filesize that 3.2.2 could do on a 288x288x19 16x16 test map, and to 37% of the previous version's best filesize on a test map with abnormally large color variance), and there are additional (though comparatively fairly small) filesize gains on the horizon which require a change in the file format which the DF Map Archive's map viewer does not yet support (we're just waiting for it to be implemented there before releasing a version of the compressor which outputs maps with that enhancement). The current filesize enhancement that we've mentioned, of course, is here now. That said, these filesizes are still generally above the 100 KB that the old 2d maps used to be - the 288x288 site with 19 layers is 181 KB. I'd say 181 KB for 19 layers versus 100 KB for 1 layer is comparing pretty well, though.
WARNING: The DF Map Compressor will very like die from running out of memory if you attempt to compress an extremely large image. Also, changing the image to a PNG first will not help. And even if you have ridiculous amounts of RAM and do manage to compress an extremely large map, and if the map archive allows you to upload it, will anyone else be able to view it without their computer grinding to a halt because of how huge it is? Be mindful. By "extremely large image," I mean max-size fortress maps, for example. A 6x6 map is just fine for a computer with 1 GB of RAM, and you can probably go above that size, but remember that the dimensions multiply, they don't add.
This program used to be called the "DF Map Viewer," but the compressing aspect of it is the primary focus, so it was renamed quite some time ago.
Version 3.3.1 has a bugfix to prevent it from changing dark grey ,.'`% and red , ground tiles into pure black tiles. It will now only change tiles which already have a pure black tile next to them, which will only be the case for tiles which are in the unexplored blackness.
Version 3.3 of this program, if it can find your init file and font stuff, and if you don't order it not to identify tiles, can identify all the randomly generated tiles in the black space in your map, and will change them all into black space. This allows it to dramatically reduce the filesize of the fdf-map or df-map file that it writes out. Version 3.3 can also better detect maps with abnormally large color variance and prompt the user to see if they want to raise the color match threshold for just that map, but also allows the user to manually change the color match threshold value themselves to whatever they want.
Version 3.2 of this program can identify each tile's font character and background and foreground colors, auto-correct tile images which have black bars covering part of them, and write the font character and color information into the fdf-map (which makes it about 1 KB bigger, but allows various new features on the DF Map Archive). 3.2 also has a few other improvements as well.
Version 3.0 of this program supports the multi-layer DF map images. You tell it to compress one of the images, and it finds all the other images that go with it, and makes an fdf-map out of them. It also renames the images afterwards so their names start with "Done-" (so you can easily see what you've already done). It also includes a local copy of the flash viewer with it so that you can preview your fdf-map files before uploading them, if you so desire. (Note that it may not work if the flash9 ocx control is not registered; I haven't figured out how to test for this yet, and I don't know what'll happen if it's missing.)
Version 2.0 of this program (and newer) can output a .fdf-map file for use with Markavian's flash DF map viewer. He also has an upload service (called the DF Map Archive) where you can upload your fdf-map and then share the link to it with friends. His map viewer (which runs quite a lot faster than the one in my program) lets you scroll around and zoom in and out. You do need my program to create the fdf-map file - his flash app is just a viewer. (fdf-map files are usually around 15 KB larger than df-map files, which isn't much except for df-map files being so small already)
If, for some reason, you don't want to use Markavian's flash DF map viewer and map archive, you can still share the .df-map or .fdf-map files with friends, and they can use this program to create a PNG (or zip file containing many PNGs) from it (or open a map viewer). In this case you would probably want to use df-map, since it is smaller. If you try to preview a fdf-map file, the compressor will try to use the integrated flash version of markavian's flash viewer. If you try to preview a df-map file instead, it will use a rather slow and crappy viewer which uses slow picturebox crap. Decoding them to a zip and opening them in your favorite paint program is another solution.
The java version is obsolete. Ideally you should use MONO if you cannot use .NET. The rest of this description of the java version is also outdated, but here you are anyhow. I haven't edited it in some time, but for historical interest, I haven't deleted it either: I've ported the compressor to java, and you can follow this link to get it (Requires Java 5.0 (aka 1.5) or better). That's a Java WebStart thingy (if it downloads instead of running, just double-click it, or if you can't double click jnlp's to run them, do 'javaws dfmc.jnlp' from the directory it is in). The java version can ONLY make .fdf-map files. It accepts png and bmp files for compressing, but you can also force it to read another image format (like .gif), if you really want to (just type *.gif in the file open dialog). That's normally not allowed because most gifs wind up being dithered or otherwise have their image data corrupted such that the program is unable to find as many tile image matches, and thus unable to compress the image as well as it otherwise could.
The java version also lacks most of the features in the C# version - all it can do is turn images into fdf-map files, and it can't do tile identification because it doesn't know how to find your init file or font. For example, the C# version can figure it out the tile size of an image in your DF folder, and can often also figure out where your DF folder to make the select-file-to-compress dialog start in your DF folder. The java version can't do either of those things. It also uses more RAM (despite my keeping the buffer sizes the same) than the C# version. It seems to run slower too (unless I ran the java one in the event dispatch thread, in which case it ran at the same speed or slightly faster than the C# one, but then you wouldn't have a working progress bar).
The java version does have a button to go to Markavian's Map Archive, and... hopefully it will actually work everywhere. I'm using JNLP's openDocument method for it. If it doesn't work, or takes over an existing tab/window, you can blame Sun.
P.S. Java Webstart required me to sign the jar files to make them runnable*. I used a self-signed certificate which has by now expired since I first made it over 6 months ago. It still seems to run fine here, though. (I didn't want to pay fees for a certificate, and I didn't want to have to put my real address and crap in a certificate that anyone can read either, as that to me does not sound wise. But I'm a bit paranoid on the internet. :P)
* = It IS possible to run it unsigned, but you have to use particular APIs to load and save files. I implemented this, and tested it, and it has several problems which have led me to stick with a signed JAR file and using normal file selection dialogs. Specifically: The JNLP FileOpenService can (and does here) ignore the specified file types, showing all file types in the open file dialog. It also doesn't show the specified title for the dialog. The JNLP FileSaveService's dialog sometimes inexplicably fails to open after the user grants permission to it. It freezes the thread, and basically the program stops working properly afterward. Sometimes it does open, but here too it ignores the specified file extension(s), and apparently ignores any specified default filename. Finally, when I clicked OK on the FileSaveService's file save dialog, it returned null, which it was only supposed to do if the user *cancelled* the dialog. It also didn't save the file. After trying saving several dozen times, and finding it unreliable in the extreme, I said "fuck it" and went back to using the real java API for file loading and saving. This unreliability may be me using the JNLP file I/O API wrong, but if so, that would be due to Sun failing to document it properly (the documentation looks correct, but lacks important details (such as whether you can pass null or "" for the pathHint or name), and the saveFileDialog method (function) clearly isn't working as described). Or, it may or may not be because I'm using the 1.5 JDK (1.5 aka 5.0, because Sun is loony) - maybe it was broken in 1.5 and got fixed in 1.6. If so, I'm not going to compile this with 1.6 (Java 6) just to hope that it makes the JNLP file I/O API work properly. I'm using 1.5 because Apple hasn't released a 1.6 JDE for Macs yet, and because java 6 is fairly recent, so a lot of people probably don't have it yet.
On the plus side, I was able to successfully use the JNLP API to make the Map-Archive-Visiting button work.
The funny thing about that experiment was that, with the unsigned applet, which was supposed to not have the hassle of security stuff, instead of asking the user once for permission to do stuff... It asked twice.
If you find any bugs in this program, there are several ways to contact me. One way is via email. If you look at the address of this website, you may notice my google username in it. You can stick @gmail.com on that and email me with it. Or, you can tell me on IRC at #bay12games on us.worldirc.org (or eu.worldirc.org, etc), where I'll usually be named 'SL' or 'ZombieSL' (if I've lost connection and reconnected). You can send me a message on IRC with /msg or /privmsg. Also, you can often find Markavian there, and sometimes ToadyOne (the creator of Dwarf Fortress). (I'm not always actually at the computer when I'm signed onto IRC, but if you send me a message, I'll see it when I get back) Alternately, you can send me a PM on the Bay12Games forums, if you can figure out how to send them to people (sending PMs to people without finding one of their posts first is a little odd on there). My username on the DF forums is 'Shadowlord'. -->