World in Flames is a monster. Although the physical game is also a monster, there are certainly things that can be optimised in the module.
Many of the board images are very large, e.g., the image Asia.png is 12052 pixel × 35410 pixel = .426761320 pixels, or 400 Mega pixels. Each pixel, when in memory is around 24 bits, or 3 bytes, meaning the Asia.png image takes up more than 1 GB of data.
If the board images are scaled down by factor 2 to 6026 pixel × 17705 pixel, which takes up a quarter of the memory - or around 300 MB. It is still a lot, but more more manageable. I know that Vassal tiles the images, and can thereby operate with smaller images, but the data still has to be swapped in and out of memory.
The board images (and consequently the piece images) can easily be down-scaled without loss of resolution - even when the boards are zoomed into 300% or so.
But, that’s only half of the story. The module uses embedded definitions of pieces in Place Marker and Replace with Other traits. That means, when Vassal reads in other pieces with these traits, the embedded marker (typically faction control markers) are replicated for every piece. That means, that the data is duplicated many times over and taking up a lot of memory and a lot of disk-space in the .vsav files of the embedded scenarios.
Of course, if one is to scale down the board and piece images, there are loads of other settings in the module that need to be adjusted too - such as grid sizes, offsets, and so on. That’s a lot of data to modify. Fortunately, one can use pywargame to automatise that tedious job.
I made a version of the module WiF.vmod where I did the downscaling of the module, including the various settings. There might be things that would need adjustments in this version. You can download it from the above link but please take it as soon as possible, as i will remove it from Google Drive in not too long.
The above version of the module isn’t all that smaller (749MB) than the one linked from the library (887MB), even though the image are reduced quite a bit. The reasons for that are multiple
- I did not use aggressive ZIP compression as done in the other one
- I did not do optimisation on-disk size of embedded PNGs, as I was more concerned about the run-time consequences.
- The embedded piece definitions noted above, plus the shear number of pieces, makes the embedded
.vsav files blow up in size on disk, and to some extent, also at run-time.
With the reduced board and piece images, the module can be run more comfortably with standard Vassal settings, and it takes a lot less time to open a scenario, irrespective of the minimum heap size set in the module.
Yours,
Christian