Would it even be practicable to work with a file anywhere near that large? My computer (with 64GB RAM) struggles a bit with the biggest map I’ve tried, which was “only” 375 MB…
Please try a build of VASSAL-3.7.6-SNAPSHOT-c38828a-fix12874 from our builds archive. Does that fix the problem for you?
1 Like
I’ll try it later tonight and will most def report back here… Thanks again for your time on this.
Very happy to report that the module with the 32k x 20k map fired right up, no problems! 
Thank you so much! Next, of course, is to try 64k x 40k (buhaha, just kidding!). 
But if you have a few minutes, it’d be helpful if you could answer a couple of other questions I have relating to large games in VASSAL…I suspect that many others might find the info helpful as well!
-
To fix this problem, did you change from a Java integer to a different data type, such as a long? Just trying to figure out what memory constraints are out there, although I hope not to come close in future.
-
when is the tiler heap relevant? Just the first time a module is loaded (and after purging the tile cache), or every time a module is loaded)?
-
When setting the tiler heap, is it simply “more is better” (as long as you have the RAM), or do you need to worry about the heap being large enough so that there is not a contiguous block of RAM available? For instance in my case I’ve got 64GB…right now I used an 8 GB heap to load the large map. Is there any sense in boosting it to 16 GB, etc?
-
From what I’ve seen, it looks like the tiler heap applies to the map, and the “module heap” applies to stuff like counters, etc.? Or not? Is there any relationship between what the tiler heap is and what the module heap should be?
-
Is png definitely the best file format for large maps? Any sense/possible to use SVG or something else?
Thanks SO MUCH for your time and assistance!!!
Yes. It’s pretty much inconceivable that you could have an image where the number of pixels times four would be larger than 2^63-1.
The tiler runs only when there are missing tiles, which would happen if you’ve never loaded a module before, clear the tile cache, or add new images to a module.
No. A max that is too high could cause your machine to thrash. If you look at the errorLog after tiling, you can see the how much memory was actually used. You shouldn’t need to set the tiler max heap to dramatically more than that.
The module max heap is for everything that the module needs to load, including the map tiles. Not all the map tiles need be in memory at once, whereas it’s not feasible to tile the map in the first place without having the entire map loaded. The module max heap and tiler max heap aren’t related in any direct way.
SVG isn’t pre-tiled, because doing so would defeat the purpose of SVG. I suspect that it would perform poorly at the size of your map, but that’s only a guess. I’m sure it would be possible with a better SVG renderer, but we’re not getting a better SVG renderer in V3.
Super-helpful, thanks!
One last question (for now!): it sounds like there isn’t much point to cutting up large maps before adding them to VASSAL, since the tiler already does that, and you’re not reducing the overall memory requirement for the map…is that correct?
Couple of issues with large maps.
I personally find large maps difficult to maintain and work on, probably due to insufficient RAM, haven’t done much map work for a few years.
Not everyone has 64MB of RAM, so if your maps are too large, some users may not be able to set the Tiling heap large enough to tile the map. i.e. anyone with a 4MB machine, and maybe even an 8Mb machine will not be able to use your module if (for example) a 6000MB tiling heap was a requirement…
This is certainly true; even with 64GB it is a huge pain to simply save map files and export them to png–probably took an hour to export my latest map from GIMP to png. But worth it to me, I can arrange the work flow so that the time-consuming stuff happens overnight, etc.
Good point, but in my case I’m confident that no one but me will ever play my module…I am making it for myself to meet my unusual specifications and have no interest in distributing it to anyone else. Making a module is also, however, a good way of learning VASSAL and perhaps in future I’ll be able to help bring other games to the platform.
I have what is likely the largest map ever placed in a Vassal module (39,007 x 51,605 pixels, 256 colors).
Originally developed in version 3.2.17, I had to break it up into 18 boards to get it to tile.
Now that I am using 3.6.17 (and we have 3.7+), I have not tried loading the entire map as one board, or even breaking it into fewer boards.
You may find you need to break your map up into multiple boards in order to successfully tile. You could try breaking it into four and see if that works.
1 Like
Thanks a big map! Which module is it in? Aren’t you the person that has done the TSWW modules?
Thanks for the tip on breaking it down into smaller submaps; I’d gotten the impression from these forums that that didn’t do any good.
While I was able to get the 32k x 20k map to load pretty easily, I have NOT been able to load a bigger map (40k x 25k). When I try to do so, the tiler launches, but then just stops…no error messages, no crashes, computer does not freeze, etc but the tiler just won’t progress beyond 0% (or once, up to 8%). I am not sure if I need a map that big, but it would be nice :). I have been too busy the last week or so to spend much time on this but hopefully will have time next week.
Yes I designed & maintain the TSWW series module. The maps and counters for every game are in module extensions, so I only have to maintain a single module for the entire series (13 publications I think).
The giant map is every TSWW ETO, MTO, and Africa map combined into one. It runs from Eire to the Urals, and from Svalbard in the Arctic to Mombasa, at about 15 miles to the hex! The printed maps are about 15 x 19.5 feet.
In most large-map modules, the map consists of a single board. Typically, individual boards are only used in those games where board configuration is selectable. Despite what others may have said, I found that Vassal does not (or did not in 3.2.17) tile the entire map at once, it tiles one board at a time. That enabled me to break the map down into boards that would successfully tile. I seem to remember trying 12 boards and even that was unsuccessful. I had to go to 18 (3 x 6) for that giant map.
1 Like
The tiler needs enough memory to load the largest image; splitting a large image into sections reduces the size of the largest image, so reduces the amount of memory required by the tiler.
Splitting an image into sections makes no difference after tiling, as the images which are loaded after that are the tiles, not the original image.
1 Like
This has always been the case. Maps are not, and have never been, tiled. Maps are assembled from Boards, and only Boards have images. Only individual images are tiled.
Thanks for the tips; later this week when I have more time, I will try to break up the 40k x 25k map into four parts to see if it works. Not sure if I’ll ever work up to a map as large as yours, but even if I do your title will remain, because my module will never be released to anyone but me. But I will post here about future successes/failures, just so that other module creators have some data to work from. This thread has been really helpful to me, so thanks everyone!
So I just wanted to post here that after breaking the 40k by 25k map into four chunks it loaded relatively easily. I think I’ll try one more a bit bigger, something like 40k x 30k or 32k, then stop, I shouldn’t need anything bigger than that. The main issue is that working with images that large is a pain; everything takes forever…just exporting the full png (from GIMP) probably takes about an hour.
1 Like
What is the pixel density of the map? Have you experimented with jpg etc. formats to see if you can reduce the footprint?
The image file format will make zero difference for performance in Vassal, but using a JPEG instead of a PNG will introduce visual artifacts in exchange for a smaller file size. A JPEG might save from GIMP faster or might not. Regardless, you should not save your source image as a JPEG, as you’ll reduce its quality and make all subsequent edits less clean—so you’ll still be stuck saving your source image as a PNG, and only exporitng to JPEG.
Better save it as a TIF and export it to any format you want.
SVG is (web-compatible) vector format. Stay away from it if you don’t have any clue about vector graphix. I
don’t think it’s compatible with VASSAL anyway.
I actually use SVG for all of my counter images, but one of the devs advised against using SVG for maps. Will look at TIFF though, so thanks for that tip.
I don’t know neither your counters nor your gamemaps.
Most of my gamemaps are combined pixel + vectors.