Pearl Harbor (John Prados, GDW, 1979)

Module Design
1

I’ve begun work on this my first module. I’ve encountered a few problems…

  1. I made 9 or 10 A4 scans (using a Canon all-in-one attached to a Mac) to cover the map and stitched them together in a respected freeware graphics program, though I had to size them down because they appeared to enlarge after scanning. I saved them as a png file. The file seems huge in terms of bytes. I imported it into the module successfully, but there seems to be a large border of grey around it.

  2. As mentioned above, my scans when imported into the module appear too large in size. Rodney has suggested this is to do with number of pixels. What is the best scanner resolution to use to avoid this problem?

  3. I scanned a few counters (control markers) the same way. Again, they seemed to enlarge after scanning so I resized them to fit the map. When I imported them into the module only one of them shows up when the ‘Pieces’ button is pressed, and now the module won’t save coming up with a {0} error.

Any help on these issues would be most gratefully received.

Don

2

The scans being too big in size is related to the fact that the native
size of a graphics image is based on the pixel size. Each scanned
pixel is mapped to an on-screen pixel. The traditional density for
screen pixels is 72 per inch, although some of the newer monitors have
actual densities of around 100 or sometimes even more.

For example the monitor I’m looking at right now has a resolution of
1600 x 1024 and a physical size of around 18.25" x 11.75", (22"
diagonal) so that comes out to be around 87 pixels per inch (ppi).

But using 72ppi is a reasonable estimate, especially if you are
concerned about things being too big. Now generally, I find that
having the magnified view be about twice life size is pretty good,
especially since the screen resolution is nowhere near printing
resolution (For game printing it’s probably the equivalent of 4800
dots per inch (dpi) – based on a 2400 lines per inch (lpi) printing
process). [*]

That suggests a good scanning setting would be about 150dpi, which
should give you a map and counters that appear about 2x life size.

-Tom.

[*] Traditional printing is measured in lines per inch, whereas
digital printing is typically measured in dots per inch. You need two
dots for each line that you can resolve, one to be black and the other
white. It gets more complicated with color, but we won’t go there.

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

3

Thus spake “yangtze”:

How large is the PNG file? What are the dimensions?

As for the border, what values do you have set for vertical and horizontal
padding on the Map element in the editor?

At what resolution did you scan the map?

There should be an errorLog in your the VASSAL directory in your home
directory. Please post that.

–
J.

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

4

For the best quality, you could try scanning your counters at the highest quality scan density you can, then use your image manipulation program to reduce the scale the image down to a usable size. Counters size depends on the Hex grid size you are using, but typical sizes are around 50x50 pixels to 75x75 pixels.

Quality of scanned counters can be difficult to maintain. If the counters are of fairly basic design, there is a facility within Vassal (Game Piece Images) that allow you to have Vassal generate images of counters for you using Geometric shapes, text, loaded images and NATO unit symbols.

When preparing graphics for Vassal, think of everything in terms of the number of pixels. Forget about ‘pixels per inch’ ratios.

How are you ‘importing’ them? Things don’t get set up for you automatically when building a module, you have to define each piece you use. I suggest you read some of the module building tutorials and the reference manual.

This is a bug in version 3.0.x which is fixed in the 3.1 beta version. As a new user working on a brand new module, you might like to start using the 3.1 beta version right away.

Regards,
Brent.

5

Guys, very grateful for the suggestions you have made, and the very pertinent questions you have asked. Will try suggestions, and return with answers to those questions, asap.

Don

6

Brent, re. version 3.1 beta, where can I download that from? Can’t find it on the home page. Will it work on a Mac?

7

Yes. vassalengine.org/forums/viewtopic.php?t=664

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

8

Some more detailed information as requested and promised, and a few questions, if anyone’s got a spare moment. I am reading the tutorial stuff, but I’m finding it hard to find specific answers to specific questions:

MAIN MAP???
I’ve gone back to a version of the module I was using before I added the control counters. I added one control counter made with a ‘General’ prototype with the usual ‘mark moved’, ‘delete’, ‘clone’ etc. features. It works. However, on trying to save I get:

‘A problem was found in this module. Must define at least one board in main map.’

I clicked ignore and it saved ok. Now here’s some detail related to this problem (I think):

When I start a new game it asks me which side I want to play and I choose observer, but then it goes to the map choosing screen. I don’t want this. There’s only one map and I want it to load straight up. Anyway, I just click ‘Finish’ and the map loads ok, but there’s a little ‘Main Map’ box comes up with nothing in it. I try to close the little box, but I get the ‘Game Modified. Save game?’ dialogue box. So I cancel and just ignore it.

I suspect it’s something to do with something I’m not getting in the relationship between ‘[Map Window]’ (where I added the map), and ‘Main Map [Map Window]’ in the editor. To be honest, I’m not sure I get the relationship between those two at all…

SCANNING
I’m a little confused that a response I got from one of you guys suggested scanning images at a smaller dpi size, but another of you suggested scanning at a high resolution for better quality then resizing in a graphics package (I’m using the freeware package ‘Seashore’ on the Mac now). Which is best? Or are both good, or does each have pros and cons?

Tom suggested scanning at 150dpi to end up with a map (and counters) about twice lifesize. I presume this can then be scaled up (unlikely to need it) or down in play by use of the zoom buttons? Will this cause a problem stitching the scans together in the graphics program? Or should any such program worth its salt be able to cope with such an image? If I scan at 300dpi then scale down 50% will this give me a twice lifesize image but at better visual quality?

The tutorial material I’ve read says to never save anything as a JPEG. Unfortunately, the Canon doesn’t seem to give the option to save scans as a PGN file, which seems the favoured option. I only have TIFF or PICT as other options for the initial save.

Having said that, the map looks fine running in Vassal, having saved it initially as a JPEG and then re-saved it as a PNG from the graphics program, also having considerably scaled it down to look lifesize in the Vassal window. So are JPEGs not as evil as the tutorial makes out? In fact, do I need to re-save as a PNG at all? Bear in mind that in the graphics package I’m stitching together about 12 A4 scans, some containing a lot more map than others, to get the final product.

I realise one mistake I made on my original scans was to allow the scanner to automatically detect document size. When I made partial A4 scans, and scanned the A5 counter sheet, and then opened the scanned image the images on those sheets look at least twice as large as the full A4 scan images. I’ve now set the scanner to consider all scans as A4 for next time.

Brent, the counters I’ve created thus far are indeed about 50 x 50 pixels. When I say I ‘imported’ the map/ counters I meant ‘added’ using the editor map/ counter window options. I’ll try to be more precise with my language. The good news is I think I understand prototypes, being sort of characteristic templates, and the order of the associated characteristics is important in terms of how they interact. See, I’m not completely useless! (unless that’s completely wrong of course…)

More detail: I’m scanning using a Canon MP140 that appears to be default set at 300dpi. I have settings of 75, 100, 150, 200, 400, 600dpi available. An option ‘Unsharp Mask’ is ticked by default. Options ‘Descreen’, ‘Correct Slanted Document’, and ‘Detect orientation of text documents and rotate image’ are all unchecked. I’m scanning from the Canon MP140 to an iMac PowerPC G4 (2.1), 800Mhz, 1Gb RAM, running OSX 10.3.4. I then transfer the raw scans to my iBook G4 PowerPC G4 (1.5), 1.33Ghz, 1.5Gb RAM, running OSX 10.4.11.

ERROR LOG
– OS Mac OS X
– Java version 1.5.0_13
– VASSAL version 3.0.15
– Pearl Harbor version 1.0

MODULE SIZE
Stands at 14.5Mb without any counters, charts etc. yet. Is that within reasonable bounds? Seems large looking at other modules, but the map is large. Is this to do with the fact that I scanned at 300dpi?

GREY AREA AROUND MAP
Maybe not a great issue, but it’s about the width of the iBook screen to the left of the map, nothing above, and about half a screen width to the right and below (padding offsets are 0, 0). Could this be to do with shoddy application of the hex-grid?

Any assistance much appreciated.

Don

9

Hi Don,

Can youpost a link to your module? It is much easier to comment if we can have a look at the module itself.

Maps contain 1 or more boards and map images are defined on the boards. This message is indicating that you have no boards defined and therefore no displayable map.

Something is not right, I can’t quite follow what you have done. Need to see the module.

That was probably me in my JPEG hate phase. PNG’s allow you to keep your artwork absolutely crisp but work best with original artwork where the colors are pure, not scans.

For large maps, it is hard to go past JPEGS for the size reduction you get.

Really need to have a look at the module to see what is happening.

Cheers,
Brent.

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

10

Thanks again Brent. I don’t have any easy web hosting so I’ve uploaded the module to the Vassal Engine site as a work in progress. It’s showing up as a new module at the top of the list. Included a screen shot :slight_smile:

Don

11

Thus spake “yangtze”:

Scanning is a very complex issue.

If you’re doing heavy processing work (like making slight rotations
of scans to get them aligned) you’ll want to take scans which give
you at least two pixels in each direction for every pixel you intend
to have in the final image. This is because image processing tends to
throw away image data, and you want to have enough image data left
at the end of the process so that you get a reasonable result after
downscaling. On the other hand, scanning a printed map at a higher
resolution than it was actually printed is pointless. For example,
on some really old maps you can see the dots from the 4-color printing
if you scan at 600dpi, and often you can see this on counters as well.

The image format in which you save is a completely separate issue from
what resolution you scan at. What it says in the guide about saving to
JPEGs is a bit of a gloss, because the reality is much more complex.
JPEG is a (potentially) lossy format, which means that when your image
is saved what’s written to disk is a approximation of your image. You
might possibly be able to adjust the quality (on a scale of 0-100,
where 100 is exact and 0 is garbage) when you save a JPEG in your image
program. I won’t go into how the aproximation works, but in general the
less accuracy you require in your saved image, the smaller it will be.
In order to see the effects of this, save one of your scans at, say 75,
and another at 100, and then compare the two images side-by-side. The
one saved at 75 will be a much smaller file, but you pay for that with
artifacts introduced by the approximation into the image. Moreover, once
you save at JPEG at less than 100% quality, you’ve lost some data from
your image which can never be recovered from that file. Therefore, if
you intend to do any image manipulation to an image ever again, you
should not save it as a JPEG at less than 100% quality, becuase that
will throw away data, and most image operations produce better results
with more data.

JPEGs at 100% quality are dramatically larger than JPEGs at any lesser
quality. JPEGs are find for storing scans, becuase scans are basically
photographs taken under very controlled conditions. However, most game
art is not photographic—it’s line art. JPEGs are good for storing
photographs because photographs have lots of smooth color transitions
which can be approximated using sums of sine waves. Line art is not like
that at all–it tends to have lots of abrupt changes in color, and lots
of large areas of constant color. PNGs are much better for storing this
kind of image: large areas of constant color and abrupt color changes are
hard to approximate with smooth waves, which is why you get lots of
artifacts when you save line art as a JPEG, while on the other hand large
areas of constant color compress well if stored exactly instead of
approximated, which is what a PNG does.

So, I’d recommend saving your scans as the highest quality JPEGs you
have room to store, and then saving your work on them as PNGs. This
will result in very large PNGs at first, because there will be a lot
of speckelling in areas which appear to the naked eye to be a constant
color when you look at the printed map and counters. The scanner is
much more sensetive than your eyes (and it also picks up some thermal
noise), so it reads an area which looks like a big, uniform green
rectangle to you as a big rectangle with very small variations in the
color from pixel to pixel, but on average the whole thing is green.
Areas like this, which lots of tiny variation, don’t compress well, and
on top of that look crappy. So, you can improve both the file size and
appearance of your scans by cleaning up areas which should be a constant
color. (Unit holding boxes are areas which are often like this.)

Once you’ve cleaned up your scans this way, the PNGs you save will be
quite a lot smaller.

There are more things you can do to reduce the size of your PNGs, e.g.,
running them through a PNG optimizer, and saving them at an appropriate
color depth. Sometimes it’s possible, especially with counters from older
games, to save them as indexed PNGs because you’re using 256 colors or
fewer. This will reduce the file size to one-quarter of what you’d have
with a 24-bit PNG, but you shouldn’t reduce the color depth just to make
the file size smaller—only reduce the color depth if your counters
really aren’t using more than 256 colors.

Don’t ever create GIFs. GIFs are much larger than (properly-optimized)
PNGs in all but a few cases, and don’t support various nice things like
alpha transparency, which you might want to use.

Alternatively, SVG is quite a nice format to use if you plan to make
the counters from scratch, and can also be quite good for maps made
from scratch. (SVG is a vector format, not something you’d use for
scans.)

Does that clarify things for you?

–
J.

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

12

Thanks very much J… I think I’ll leave the map as it is until I get the module working properly, and then start again on the map with a new set of scans along the lines that you suggest.

Don

13

Hi Don,

There is no module on the Files page to download.

Regards,
Brent.

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

14

Hi Brent

I’m trying to upload the module to Vassal but it’s not working for some reason. I tried it using Safari and Firefox 2 from a Mac running OSX 10.4.11. Any ideas?

Don

15

Hi Don,

I think you said it was 14.5Mb? The maximum file size for uploading to the vassalengine site is 14Mb.

Brent.

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

16

Doh! I zipped it but it’s still 14.4. Is there any other free compression I could use on the Mac that might pack it tighter?

17

Don’t worry about compression. I re-saved the map as a jpeg and it looks fine at 2Mb. I started from scratch with the module and it currently sits at 2Mb. Does the module have to be uploaded as a zip file?

18

Success! The module is uploaded.

Note, the process didn’t like Safari but uploaded in seconds using Firefox.

My pieces are 8kb and 50x50 pixels in size (which fits the map nicely). Does that sound the right size in terms of bytes?

19

Thus spake “yangtze”:

You could use gzip or bzip2 on the module, but then Windows users
wouldn’t be able to/wouldn’t know how to open it.

We need to raise the maximum file size.

–
J.

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

20

Thus spake “yangtze”:

That’s only 20% smaller than what a 50x50 24-bit image would be
uncompressed. I’ll bet that you could get your piece images to
be smaller if you ran a PNG optimizer (like pngout) on them.

–
J.

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)