Page 1 of 1

Understanding module size impacts (solutions)

PostPosted: December 12th, 2016, 3:27 pm
by msward1
I'm trying to understand the impact of modules size (functionalities) on the usability of a module.
And what impact this size has and how I can rework my modules to make it usable.

To all you Vassal guru's out there I'd like to heard your comments and recommendations.
I have a module I've just recently completed (sort of) which weighs in at about 136MB.
In the testing of this modules I've have a plethora of user issues.

Unable to load the module.
Unable to save a module scenario.s
Extremely slow loading of the modules and/or scenarios.
Commands which take minutes to complete.

So I've had users bump their Vassal (and individual scenario) heap sizes. Helps a little.
I've streamline the module so there are no excess images or files.

Still the module seems to be marginally usable.

So suggestions?

Re: Understanding module size impacts (solutions)

PostPosted: December 14th, 2016, 11:24 pm
by jimpyle
What's the size of your map in megabytes?

Jim

Re: Understanding module size impacts (solutions)

PostPosted: December 14th, 2016, 11:42 pm
by uckelman
Unused images in the module will have no impact on memory usage when the module is loaded. Dimensions of your map images will. (Note that dimensions are distinct from image file size, which is mostly unimportant.)

Re: Understanding module size impacts (solutions)

PostPosted: December 15th, 2016, 2:26 am
by msward1
Ahh.
Thanks guys.

Got 3 maps 122x33, 122x33 & 122x58 (inches).
12.5, 23.5 and 58 (MegB).

Tried to minimize the number of maps to avoid the splice join stacking issues (Bug:1860944).
Guess that was a mistake.
Dam.

Re: Understanding module size impacts (solutions)

PostPosted: December 15th, 2016, 2:42 am
by Brent Easton
The important thing is the Dimension in pixels, not inches. Vassal doesn't know anything about physical size, only pixels. Those maps sound very large, depending on the Pixels per inch, which is most probably causing your problems. I tend to cut large maps to pieces around 3000x5000 pixels and have no problems. Those numbers are somewhat arbitrary based on some early maps I worked on and I've kept using that size. Somewhat larger would probably work also.

If the maps are hex based, then you can avoid any issues with units stacking on map joins by making sure you cut the maps so the cuts do not run through any hex centers.

Re: Understanding module size impacts (solutions)

PostPosted: December 15th, 2016, 2:59 am
by msward1
Thx Brent.
I'm about twice that and more.
11628 x 3143 (95.76px/in)
11628 x 3289 (95.94px/in)
11788 x 5604 (95.94px/in)

Guess I need to rethink the map sizing.
I did try the splicing off the hex center didn't seem to make much different.
Maybe I was still to close.

Re: Understanding module size impacts (solutions)

PostPosted: December 15th, 2016, 3:15 am
by Brent Easton
I would cut each of those maps into 2 and see how that goes.

Here's a sample showing where I make the cuts, no where near hex centres

Re: Understanding module size impacts (solutions)

PostPosted: December 15th, 2016, 1:12 pm
by uckelman
Thus spake msward1:
> Ahh.
> Thanks guys.
>
> Got 3 maps 122x33, 122x33 & 122x58 (inches).
> 12.5, 23.5 and 58 (MegB).
>
> Tried to minimize the number of maps to avoid the splice join stacking
> issues (Bug:1860944).

Are you sure that's the correct bug number? Last I checked, we didn't
have any bugs with numbers of more than five digits.

> Guess that was a mistake.
> Dam.

Dimensions in _pixels_ is what matters for memory usage.

--
J.