Intitial Tiling Fails for Large Graphics (Maps)

Hi,
I have looked for previous posts of this type and didn’t find any that were similar so I am posting this.

I just downloaded two Vassal modules from the Decision Games website and found that the “Cobra” module works fine but the “War between the States” fails to tile correctly and hangs at 26% leaving the tiling window open. After a while it brings up the game selection menus (which work) but only displays a single fragment of the main map in the top left corner. I suspect other graphics may also be missing. I have attached the two error logs, one successful for 10MB files and the other unsuccessful for 13MB files.

The only difference I can see is the size of the graphic file being processed and that the conversion switches to FileImageTypeConverter and the process then fails.

I tried an old module that I was working on a while back (under Vassal 3.2.6) with a 13MB map file and it fails in a similar manner to WBTS. It used to tile just fine. I tried increasing initial memory heap size and it made no difference.

Hardware: Compaq NC8430 with T5600 processor and 3GB memory recently upgraded to Win8.1 from XP. Java 1.8.0_45 also recently installed (which may or may not have anything to do with it). Otherwise Vassal seems to be running just fine.

Cheers,
Reg
.

Thus spake reg129:

Hi,
I have looked for previous posts of this type and didn’t find any that
were similar so I am posting this.

I just downloaded two Vassal modules from the Decision Games website and
found that the “Cobra” module works fine but the “War between the
States” fails to tile correctly and hangs at 26% leaving the tiling
window open. After a while it brings up the game selection menus (which
work) but only displays a single fragment of the main map in the top
left corner. I suspect other graphics may also be missing. I have
attached the two error logs, one successful for 10MB files and the other
unsuccessful for 13MB files.

The only difference I can see is the size of the graphic file being
processed and that the conversion switches to FileImageTypeConverter and
the process then fails.

The tiler might be running out of memory.

The tiler runs in a separate process and guesses how much memory will be
needed. I see that you’re using Java 8, which is newer than anything
we tested aginst. If Java 8 requires more memory to do the same work
than Java 6, that would explain why this fails for you.


J.

Which is what I was suspecting… :frowning:

This appears to be the applicable area. Is there any way this setting can be increased???

Cheers,
Reg
.

Thus spake reg129:

Which is what I was suspecting… :frowning:

This appears to be the applicable area. Is there any way this setting
can be increased???

Not without recompiling, no. If you file a bug report, there’s a chance
I’ll look into readjusting the heap estimates for Java 8, but I’m not
promising anything.


J.

Hi,

I ran the resource meter and it appears that the 740kB allocated memory is indeed max’ed out even though I have plenty of system memory left. (See attached).

Another option is to load Java 6/7 for Vassal only but that is not recommended by Oracle for security reasons (Hobson’s choice here…).

By the way, is this user account valid for Bugzilla as I can’t seem to log in to report this problem but it says my account name already exists when I try to create it.

Cheers,
Reg

Thus spake reg129:

Hi,

I ran the resource meter and it appears that the 740kB allocated memory
is indeed max’ed out even though I have plenty of system memory left.
(See attached).

That’s 740_000_ KB (i.e., about 720MB).

What are the dimensions of the image you were trying to tile?

Another option is to load Java 6/7 for Vassal only but that is not
recommended by Oracle for security reasons (Hobson’s choice here…).

The warnings I’ve seen have to do with the web plugin (don’t install
it) and sandboxing. They shouldn’t affect you with VASSAL.

By the way, is this user account valid for Bugzilla as I can’t seem to
log in to report this problem but it says my account name already exists
when I try to create it.

Yes, it is, but you can’t log in at the moment because of a problem
we’re strill trying to resolve from the system upgrade last week.


J.

jpg, 9757 x 7293, 12.7MB

Thanks, I’ll try later

I have installed Java 1.7 CPU 79 and attempted to run Vassal under this version to see if it made a difference but no luck. (I don’t want to uninstall 8 ). A web search said you should be able to open a shell and set the PATH & JAVA_HOME env variables to run an application under an older version of Java. “java -version” indeed flags the older version but when Vassal.exe is run in the shell, it still uses Java 8 (as evidenced by the absolute path in the error log).

Where does Vassal pick up the Java path?? Does it get it from the symlinks at C:\ProgramData\Oracle\Java\javapath??

Cheers,
Reg

Thus spake reg129:

I have installed Java 1.7 CPU 79 and attempted to run Vassal under this
version to see if it made a difference but no luck. (I don’t want to
uninstall 8 ). A web search said you should be able to open a shell and
set the PATH & JAVA_HOME env variables to run an application under an
older version of Java. “java -version” indeed flags the older version
but when Vassal.exe is run in the shell, it still uses Java 8 (as
evidenced by the absolute path in the error log).

Where does Vassal pick up the Java path?? Does it get it from the
symlinks at C:\ProgramData\Oracle\Java\javapath??

I assume that have a Windows install rather than a generic one, so
you’re launching VASSAL using VASSAL.exe. Launch4j builds VASSAL.exe for
us. I wasn’t able to track down a precise statement of how it selects
a JVM, but my guess is that it looks at the Windows registry to find the
most recent usable version.

You could instead run the JVM directly:

java -jar lib\Vengine.jar VASSAL.launch.ModuleManager


J.

Thus spake reg129:

[This message has been edited.]

What are the dimensions of the image you were trying to tile?

jpg, 9757 x 7293, 12.7MB

The only thing relevant for tiler memory usage is the pixel dimensions,
since that determines the size of the raw pixel data. File type and file
size aren’t relevant.

The formula we use for setting the max heap for the tiler is 1.66*M+150,
where M is the size in MB of the pixel data for the image with the most
pixel data.

In the case of WBtS, it’s this map, which has 97577293 = 71157801
pixels. At 4 bytes per pixel, that’s 284631204 bytes, or just under
272MB. 1.66
272+150 is right around 600MB. (Your error log is showing
599MB, which is going to be due to rounding.)

We might be able to solve this by making the first and zeroth order
coeficients in the formula adjustible. The reason I didn’t opt for this
in the first place is that hardly anyone will understand how to set
these reasonably, and setting them poorly will cause many modules to
fail to tile.


J.

Correct. I have the Vassal.exe install.

I tried running directly with java as you describe above but it failed to run with “VASSAL: File ‘VASSAL.launch.ModuleManager’ of unknown type” error. Obviously a consequence of using the exe.

Looks like I will have to wait for you guys to solve this.

Interestingly someone has just released a module on Three Days of Gettysburg which is the other module I was working on. However because they broke the map into 4 x 2MB pieces it tiles and runs OK on my machine. My module with exactly the same map in one 17MB file doesn’t tile. :frowning:

(I still like my module better - it does more. :smiley: )

Cheers,
Reg

Thus spake reg129:

“uckelman” wrote:

You could instead run the JVM directly:

java -jar lib\Vengine.jar VASSAL.launch.ModuleManager


J.

Correct. I have the Vassal.exe install.

I tried running directly with java as you describe above but it failed
to run with “VASSAL: File ‘VASSAL.launch.ModuleManager’ of unknown
type” error. Obviously a consequence of using the exe.

It’s not—nothing at all to do with using the exe.

From what directory did you issue the above command?


J.

The current directory was the folder containing the Vassal.exe file and where lib\Vengine.jar was also valid.

I assume ModuleManager is a class defined within Vassal.exe?

Thus spake reg129:

The current directory was the folder containing the Vassal.exe file and
where lib\Vengine.jar was also valid.

I assume ModuleManager is a class defined within Vassal.exe?

No, ModuleManager is a class in lib\Vengine.jar.

My appologies, I had the syntax wrong. It should be:

java -cp lib\Vengine.jar VASSAL.launch.ModuleManager

The -jar flag tells the JRE to look for the designated entry point in
the JAR, and then the next argument is passed on to that class, which
isn’t what was intended.


J.

That worked better. :smiley:

Unfortunately running java 7 didn’t fix the original problem.

Cheers,
Reg

Now that’s interesting.

After upgrading to Java 1.8.0_51 I tried to load the “War between the States” module again. After it started to tile I decided to close Thunderbird and Firefox which would have freed up a heap of memory.

And the module tiled and loaded correctly!!! Woohoo!!

To see if that was it I tried to load one of my custom modules (3DoG_100.vmod) with a 17MB map and it failed (several times), even when I tried the trick of closing Thunderbird/Firefox to create some free up memory. I noted when the tiling fails the free memory (as opposed to standby memory) drops to zero. So it looks like there is a bit more to this but it does look available memory related.

Log attached. (looks like there is still an error in there).

Cheers,
Reg

One of the errors indicates that you have a corrupt tile cache, possibly due to having tiling fail. Clear your tile cache (Tools > Clear Tile Cache in the Module Manager).

Tried that back on day one. :slight_smile:

I looked at the cache in the \AppData\Roaming\VASSAL\tiles folder and a game folder was being created but the tile files were not being written (except for one or two IIRC). I would clear it either manually or via “Clear Tile Cache” before trying again but it made no difference.

Cheers,
Reg
.

Just letting you know that this issue appears to have been resolved in the Vassal 3.2.17 release. :smiley: :smiley: :smiley:

The latest WBTS module (V1.1) from the Decision Games site tiles just fine and my old 3DOG module with the 17MB map now also tiles without a problem.

Thanks a million guys. :mrgreen:
Cheers,
Reg