It’s an accurately-scaled, global map at about 50 miles / hex. I’m
working up a global, WW2 module and I’ve currently got smaller maps
covering the significant areas (Europe, China, SE Asia, East Africa,
etc) but that approach drives me to a bunch of complicating, special
rules and some sort of small, global display to get forces from one
theater to another.
I was going to suggest making your hexes smaller, but that’s fairly small already.
Instead, I suggest cutting your map image into sections. If you cut your map into three rows of three sections each, the size of each section would be 1/9 of the size of the overall map. Then, create a Board for each of the 9 map images, and add all 9 Boards to one Map. This way, VASSAL will never need to load a single image which is more than about 130MB in memory.
Yeah, that’s where I started - but with six sections (two rows of three columns) but still had memory problems. I didn’t know if there was any memory advantage to having maps in pieces vs. one-big map, so I’ve tried both.
Not being sure where the limits are, perhaps 9 sections will work where six didn’t? I’ll give it a go.
Also, I many times simply resort to 255 colors (.gif). For the very high quality maps, you can sometimes, but not always, detect the difference. But the reduction in map size is sometimes worth it. For medium to low quality maps, most users won’t notice.
From the sample you gave, your map may not benefit from this, as not too many colors are apparent. However, have your graphics program count the colors. If there are over 256 colors, reduce it. See what it looks like. Then compare file sizes. Save the reduced color map as a .gif to make sure only 256 levels are retained. Reducing to 256 colors in other formats many times will not produce equivalent reductions in file sizes.
Also, I many times simply resort to 255 colors (.gif). For the very
high quality maps, you can sometimes, but not always, detect the
difference. But the reduction in map size is sometimes worth it. For
medium to low quality maps, most users won’t notice.
From the sample you gave, your map may not benefit from this, as not too
many colors are apparent. However, have your graphics program count the
colors. If there are over 256 colors, reduce it. See what it looks
like. Then compare file sizes. Save the reduced color map as a .gif to
make sure only 256 levels are retained. Reducing to 256 colors in other
formats many times will not produce equivalent reductions in file sizes.
Also, I many times simply resort to 255 colors (.gif). For the very
high quality maps, you can sometimes, but not always, detect the
difference. But the reduction in map size is sometimes worth it. For
medium to low quality maps, most users won’t notice.
Reducing the color depth is useless for reducing the amount of
memory VASSAL uses for an image. All images are 4 bytes per pixel,
regardless of how many colors you use. All reducing the color depth
will do is make your image look worse.
uckelman,
So, to be 100% clear (not that you haven’t been clear, but I just want to make sure I understand correctly), the filesize of an image only affects the download size of the module, but has nothing to do with the runtime performance of the vassal engine, correct?
For example, a 10 MB bitmap (.bmp) image will perform exactly as a 1 MB jpeg of the same image when playing the module. The only cost of the 10 MB file is the bigger download. Right?
BTW, I went to six images for my ‘huge’ map and, sure enough, it worked. A bit sluggish, though, when moving from section to section and I have a fairly decent laptop - might be a problem for lower end computers.
uckelman,
So, to be 100% clear (not that you haven’t been clear, but I just want
to make sure I understand correctly), the filesize of an image only
affects the download size of the module, but has nothing to do with the
runtime performance of the vassal engine, correct?
For example, a 10 MB bitmap (.bmp) image will perform exactly as a 1 MB
jpeg of the same image when playing the module. The only cost of the 10
MB file is the bigger download. Right?
Yes.*
*You might see a small difference in intial load time for larger file,
but two images containing the same image data will always perform in
the same way once the image data is loaded.
BTW, I went to six images for my ‘huge’ map and, sure enough, it worked.
A bit sluggish, though, when moving from section to section and I have
a fairly decent laptop - might be a problem for lower end computers.
You’ll find that this will be dramatically better in 3.2 than in 3.1.
There are 3.2 development builds here, if you want to see the difference
yourself:
uckelman,
I tried the latest build (VASSAL-3.2.0-svn7798-windows.exe) and it failed when “tiling” the huge map sections. The build worked fine on other VASSAL modules I’ve got loaded, so it seems like a size limitation of some sort.
Re: Reducing the color depth is useless for reducing the amount of
memory VASSAL uses for an image. All images are 4 bytes per pixel,
regardless of how many colors you use. All reducing the color depth
will do is make your image look worse.
However, a smaller size map file will make the size of the Vassal MODULE smaller. Isn’t that correct?
Thanks for the information regarding the display characteristics.
Yes that is correct, but that should not really matter unless your using a computer built before circa 2000. Diskspace is not an issue anymore, nor should it be for anyone.
The only reason I can think of where module file size is that important is because of download time concerns, but then, if that is the case, you should be using SVG files for your graphics instead of the standard raster formats (gif, jpg, png). Not only are the SVG files usually smaller than the others, they are also better quality. Reducing color depth or converting from png to gif/jpg format to save disk space though is the wrong thing to do - sure you’ll save space, but your module is going to suffer as has already been pointed out.
Thanks, Tim. I downloaded and tried that version with same results - it appears to be working fine for my other modules, but the one with the huge map sections (6 boards of 8845 x 6643 pixels) fails when Tiling. See image below.
I have another question regarding VASSAL v3.2. Given that it’s “Tiling” images, do you think it will make any difference for a huge map whether it’s broken into six boards, each tiled separately, or will it be just as efficient to have one giant board that will be tiled?
the latest build is VASSAL-3.2.0-svn7805-windows.exe. Try with it
Thanks, Tim. I downloaded and tried that version with same results - it
appears to be working fine for my other modules, but the one with the
huge map sections (6 boards of 8845 x 6643 pixels) fails when Tiling.
See image below.
Your problem is likely that the max heap for the image tiler is too low.
I’ve changed it so that the max heap for the image tiler depends on the
size of the largest image to be tiled, but can’t upload a build right
now due to the limited bandwidth at this internet cafe. I’ll be able
to upload a new build for you on Monday.
I have another question regarding VASSAL v3.2. Given that it’s “Tiling”
images, do you think it will make any difference for a huge map whether
it’s broken into six boards, each tiled separately, or will it be just
as efficient to have one giant board that will be tiled?
In order to create tiles for an image, we have to be able to load the
whole image. While low-end machines are capable of displaying tiled
images of any size, they’re not generally going to be able to handle
slicing extremely large images. E.g., an image with 300MB of image data
(at 4 bytes per pixel) might not be sliceable on a machine with only
512MB RAM.