Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Pseudobob]

I recently created a composite map that can be found here: http://i767.photobucket.com/albums/xx314/kerog6/CollageFlat_zps1eac4edf.jpg

It was made manually. I had to go into the embark screen, scan the map in four or five rows, and hit "print screen" every time I wanted to save a portion of the larger-detail map available on the region screen. I also cropped and saved it in MS paint after that, and photo-merged them all in Photoshop, but that arduous task is not the point.

[EDIT] I realize that was a pointless exercise, I could have exported it straight from legends mode.

I'd like to know; is there a way to export the entire local map (by 'entire local map' I mean a single file containing all possible 'local' screens, in order)? I want a true map of this place but I don't want to go through the locals manually, for obvious reasons. Or, even better: a file containing the entire local map in in-game detail? That one's a bit of a stretch but I'd take it if I knew a way to get it that didn't involve embarking millions of times.

[ORCACommander]

wow you do realize a map based on local would multiply the resolution by 16^2 right?

[Pseudobob]

wow you do realize a map based on local would multiply the resolution by 16^2 right?

Yes, if I could get a map of that size I would. Although I've been looking around and it doesn't seem possible, so unless this thread yields any results I'll proceed with the region-size map.

[Azated]

I doubt any computer in the world has the processing power to do what you're asking.

[Draco18s]

A pocketworld would result in an image 43,520 wide by 52,224 pixels tall, using the default tileset.

That's a total image size of 2,272,788,480 pixels.

At 3 byts per pixel of color, your raw image would be 6,818,365,440 bytes (6658560 KB, 6502 MB, 6.35 GB).

Assuming a 10:1 compression ratio (based on the information I can find, this is the best GIF can do, and PNG is 10-30% smaller, so this is close to an ideal situation) that leaves you with a 650 megabyte png!

[Zanthra]

Nasa's Blue Marble releases most of their composites as 21,600x21,600 pixel images  (http://visibleearth.nasa.gov/view_cat.php?categoryID=1484&p=1).  Computers are often not optimized for such high resolution images, but they generally can handle them.  Another thing is breaking it up into several pieces and then using something like the google maps code to zoom in on it would work well.

[Calathar]

My understanding is that the local view is generated whenever it is loaded, and that the actual local map is not stored in memory anywhere.  I think you're out of luck without Toady's algorithm to generate the local maps.

01/22/2012 Toady One After fixing that crash bug I mentioned, I started up map maintenance today. The basic idea is that the cities have far too many objects to just dump everything on the disk quickly/compactly, so it has to regenerate them when you revisit a site and then try to patch things up based on what you did before. This works nicely enough when there are few changes, but as we do more and more to cities in play, we'll have to adapt this process as needed. It makes the game more sensitive to the random number seeds as well (in my first bugged test, I walked off with an amulet, and when I went back to town, instead of the amulet not being in the town, some random rat weed in the market ended up not being there because it wasn't regenerating the town 100% consistently), but them's the breaks. There's still various debris left from optimization and the sponsorship critters, and there's time left to spend on that, but this is the last part that really needs an effort to finish this release off.

[puke]

DF Maps actually compress amazingly well, much better than 10:1.  Take a look at the map packager on Markavians DF Map Archive.  It basically parses out what a tile is, and only stores each tile once (probably compressed).  The rest is just a list of what tile goes where. 

Probably less than 1 byte per tile, depending on how many tiles you've got.  Lets call it 1, allowing for 256 tile possibilities.  That would make each region tile about 580K, not including whatever small overhead it takes to store your tileset.

Not too bad.  Generating the image though... trickier.

[Draco18s]

He's trying to save it as an image though, not in an arbitrary superpacked format.

[lue]

In theory, you could "just" loop through all the local views, convert them to a more easily manipulateable form, and pull up the desired font, and draw the features into an image, then later manually stitch together all the local views. I say in theory because in reality this feels like a Difficult Thing™, even taking out the "discover how maps are stored" part.

My understanding is that the local view is generated whenever it is loaded, and that the actual local map is not stored in memory anywhere.  I think you're out of luck without Toady's algorithm to generate the local maps.

If that is the case (would make sense), then I'd only bother with generating a detailed map of the geography and whatever other features aren't generated on-the-fly (There's likely some indication of the kind of vegetation present in a location, so this theoretical local-map-making application could randomly plaster the geography in the appropriate vegetation).

I just realized another consideration: z-levels. I personally would go with "the highest non-open-space tile" for each spot, and then a separate local-resolution heightmap. (3D maps of the world down to the best resolution... )

[Kiloku]

Maybe we could code something to automate the whole proccess of navigating the map, screenshotting the "Local" section and then stitching the screenshots? Would still take a huge amount of time to finish and would need the computer to not be used while it runs, but is still feasible and wouldn't require human interaction...
Quite brute-forceish, though.

[lue]

(BTW, when I'm thinking of local section, I'm thinking of the squares defined by those times when you cross a boundary that causes the game to pause for a moment).

Could definitely be done, and in fact would guarantee getting some of the generated stuff (letting you see, for example, the population of a site, the kinds of animals that can be found in an area, etc). The only problem would be the z-levels, which could be handled by a flying adventurer going to the lowest and highest point of each local section.

I can't help but wonder if it would be faster for a program to be written to parse all the local map data or for a program to just play through the map in Adventure mode and take screenshots. (I would think parsing the map data externally would be faster, because it avoids all the irrelevant stuff the game has to do, but I would be surprised if generating that information externally doesn't provide a significant difference over DF's existing methods.)

[Crashmaster]

related;

http://www.bay12forums.com/smf/index.php?topic=129208.0

[SmileyMan]

One problem you would encounter is that the local map is a slice through a z-layer. Are you going to pick one layer for the whole map, or do you want to calculate the top tile?

So you either have a boring map, or a whole extra layer of complexity in the way.

[lue]

I would program it to take the topmost non-empty space, and then also generate a heightmap. It misses out on caves and such, but it's the least complicated way of generating such a local map (and also, along with the heightmap, allows you to create a 3D model, if your computer can handle it ). It also would match how the maps exported by Dwarf Fortress already look.