I am a bit confused regarding what really limits a module’s size, whether it’s file-size, image size before/after compression or raw pixel dimensions. I am hoping to use a giant map which is currently rendered as a .png at 11.6 MBytes. It is 26535 x 13286 pixels. Is there any hope that this could work in VASSAL?
Thanks in advance,
Thus spake mroyer:
I am a bit confused regarding what really limits a module’s size,
whether it’s file-size, image size before/after compression or raw pixel
dimensions. I am hoping to use a giant map which currently sits at 11.6
MBytes, but is 26535 x 13286 pixels. Is there any hope that this could
work in VASSAL?
File size for images doesn’t matter at all. For VASSAL 3.1, what matters
is how many bytes in memory an image uses at 4 bytes per pixel. Your map
will occupy 1.3GB of memory when VASSAL is running, so probalby won’t be
usable by many people.
For VASSAL 3.2, the only time that the full image will be loaded is
when it’s being sliced into tiles, which happens the first time a module
is used. It won’t require so much memory for normal use, but many people
still won’t have enough memory to do the tile slicing, so the module
won’t be usable for them.
Why is your map so large?
–
J.
Why is your map so large?
Mostly to be cool 
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.
Since I have all the raw info for the global map, I thought I might try to put it all onto one giant map image so I could just use generic rules, whether moving one hex or half-way around the world. … and it would have been VERY cool too.
Thanks for the answer,
-Mark R.
Thus spake mroyer:
Why is your map so large?
Mostly to be cool
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.
How many pixels long are your hexsides?
–
J.
How many pixels long are your hexsides?
I’m using the hex grid directly in VASSAL (the map doesn’t have hexes), and they’re about 64x55.4 pixels.
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.
-Mark R.
I too am working on a large ww2 game, I am interested in hearing more about your project, perhaps comparing notes.
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.
File size on disk does not matter
For more on graphics and files see
vassalengine.org/wiki/Faq_mo … and_Images
vassalengine.org/wiki/Image_formats
vassalengine.org/wiki/Faq_mo … e_limit.3F
-----Original Message-----
From: messages-bounces@vassalengine.org
[mailto:messages-bounces@vassalengine.org] On Behalf Of Hagar
Sent: Tuesday, September 06, 2011 6:59 PM
To: messages@vassalengine.org
Subject: [messages] [General Discussion] Re: Huge Map - Is it possible?
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.
Read this topic online here:
https://forum.vassalengine.org/t/huge-map-is-it-possible/4241/9
Thus spake Hagar:
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.
–
J.
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.
-Mark R.
Hi Don,
I am working on a highly-modified derivative of AP’s Third Reich.
Take a look here for an idea:
stprocup.com/phpbb3/viewforum.php?f=8
Contact me at mroyer1 at comcast dot net if you like.
-Mark Royer
Thus spake mroyer:
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:
vassalengine.org/~uckelman/builds/
–
J.
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.
-Mark R.
the latest build is VASSAL-3.2.0-svn7805-windows.exe. Try with it
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?
-Mark R.