Module Map Repaint Very Slow

As a noob on my first module attempt I’ve run into an issue.

When I load up the module to play and put a bunch of counters on the map, the computer bogs down and takes a very long time to repaint the map as move it around. At first I thought it was the map size (an 8 MB jpg) so I did some cleaning of the scan and got the map down to about 3 MB and still the same problem, although not quite as bad.

So, I went extreme and created a one-color “map” image the same pixel size of the original map. The pseudo-map is only a 42 KB jpg image. I loaded it and it also exhibits the issue. So, perhaps it’s counters? Each counter is about a 4 KB jpg image. I have perhaps 150 on the map which doesn’t seem like an excessive amount to me.

Besides counters and map, could anything else be driving this issue? (My computer is a new Dell precision M4500 laptop.)

Thanks in advance for any help and suggestions.

-Mark R.

Try converting your JPG graphics to PNG. I’ve found that JPG’s don’t work nearly as well in Vassal.

Thus spake mroyer:

As a noob on my first module attempt I’ve run into an issue.

When I load up the module to play and put a bunch of counters on the
map, the computer bogs down and takes a very long time to repaint the
map as move it around. At first I thought it was the map size (an 8 MB
jpg) so I did some cleaning of the scan and got the map down to about 3
MB and still the same problem, although not quite as bad.

So, I went extreme and created a one-color “map” image the same pixel
size of the original map. The pseudo-map is only a 42 KB jpg image. I
loaded it and it also exhibits the issue. So, perhaps it’s counters?
Each counter is about a 4 KB jpg image. I have perhaps 150 on the map
which doesn’t seem like an excessive amount to me.

Image file size is completely irrelevant for image rendering. What is
relevant is image dimensions. How wide and high is your image?

What module is it that you’re using?


J.

Thus spake DrNostromo:

Try converting your JPG graphics to PNG. I’ve found that JPG’s don’t
work nearly as well in Vassal.

I’d like to see the evidence you have for that. Every image, once it’s
loaded, is supposed to be put into the same format in memory. Can you
show me some JPEGs which don’t work well?


J.

2884x2511

One of my own still being created.

-Mark R.

Thus spake mroyer:

“uckelman” wrote:

Image file size is completely irrelevant for image rendering. What is
relevant is image dimensions. How wide and high is your image?

2884x2511

That’s not especially large.

What module is it that you’re using?

One of my own still being created.

It would help for troubleshooting if you could put your module somewhere
that we could download it.


J.

Sure :slight_smile:

In the attached zip is a module with 3 images a gif,jpg and png. The png is easy to spot but which image is the gif and jpg is more difficult. The gif is the better of the two though because it doesn’t butcher the alpha as bad as the jpg format .

Its easy to blame vassal for their appearance but it’s really not vassal that is the issue but the image format itself - but we’ve always known that and the reason this probably happens is (the blame vassal bit), when someone is using a utility such as photoshop or paintshop pro, these programs show your image how it’s supposed to look while manipulating in them but they will let you save as another format without previewing (if you want to like any good graphics program) so you dont see your real end result until after you’ve put the image into vassal and you could end up with something like this example mod shows. :open_mouth:

One should always use the export/preview options the graphics software one uses provides as a result to know what your going to get. :slight_smile:

That would be great. Thanks for any help!

http://www.stprocup.com/non-website/JP%20Third%20Reich
stprocup.com/non-website/AtStart1939B.vsav

Caveat: The .vsav file was saved when I had a larger map (3846x3348) and counters (70x70) so all the counters are offset from the current hex-grid. The current module has a map at 2884x2511 and 50x50 counters. Intuitively it doesn’t seem like that should be relevant to my issue, but as I uploaded the files it occurred to me maybe it is a factor.

(Also, just for everyone’s info, due to copyright issues the finished module will be for personal use only. I purchased the game because there exists a VASSAL module. However, I discovered after the fact the publisher won’t allow the module to be distributed - therefore I’m making my own so my friend and I can play since we can’t get together face-to-face regularly like we use to in the pre-kids days.)

This seems more like a graphics quality issue vs. the screen repaint speed issue I’m facing… true?

-Mark R.

yes.

My mistake. In the past (like 2 years ago) I had trouble using large JPG’s. I just ran a test with a very large map in both PNG and JPG format. You obviously have made some improvements to how graphics are handled since 2 years ago as I found no difference between the two.

Thus spake DrNostromo:

I’d like to see the evidence you have for that. Every image, once it’s
loaded, is supposed to be put into the same format in memory. Can you
show me some JPEGs which don’t work well?

My mistake. In the past (like 2 years ago) I had trouble using large
JPG’s. I just ran a test with a very large map in both PNG and JPG
format. You obviously have made some improvements to how graphics are
handled since 2 years ago as I found no difference between the two.

Yes, we did. There will be further improvements in 3.2, as well.


J.

On Mar 18, 2011, at 2:27 AM, Joel Uckelman wrote:

Thus spake DrNostromo:

Try converting your JPG graphics to PNG. I’ve found that JPG’s don’t
work nearly as well in Vassal.

I’d like to see the evidence you have for that. Every image, once it’s
loaded, is supposed to be put into the same format in memory. Can you
show me some JPEGs which don’t work well?

I’m wondering if this is a quality of reproduction issue and not a performance issue. Certainly for line art and text, the image you get from a JPEG will generally be worse than from a PNG.

Thus spake mroyer:

“uckelman” wrote:

It would help for troubleshooting if you could put your module
somewhere
that we could download it.

That would be great. Thanks for any help!

stprocup.com/non-website/JP[1] Third Reich
stprocup.com/non-website/AtStart1939B.vsav[2]

I can’t open your module file. It appears to be corrupt.


J.

Yup… I believe you are correct that the module may be corrupt.
I can open it, but with the slow-repaint issues noted in the opening post.

I completely re-built the module using the same exact image (.jpg and .png) files and my slow re-paint issues appear to have gone away. It now performs a snappy repaint of the map.

I can’t imagine what I might have done first time through to screw up the module.

Thanks for looking into it for me.
-Mark R.

Thus spake mroyer:

“uckelman” wrote:

I can’t open your module file. It appears to be corrupt.


J.

Yup… I believe you are correct that the module may be corrupt.
I can open it, but with the slow-repaint issues noted in the opening
post.

If you can open your module, then it’s not corrupt in the same way that
the one you uploaded is. The internal ZIP file structure of the one you
uploaded is not right—it looks like it got truncated when you uploaded
it.

I completely re-built the module using the same exact image (.jpg and
.png) files and my slow re-paint issues seem to have gone away. It now
performs a snappy repaint of the map.

I can’t imagine what I might have done first time through to screw up
the module.

Thanks for looking into it for me.

I’m glad you found a solution.


J.