Defining images for V4 and a boardgame standard

Development
1

One of my goals for V4 is that we develop a boargame standard in which to represent game components and game state, as well as to provide a way of associating images with those game components. I’d like to kick this off by considering what the requirements are for defining images.

As I realize it might not be clear what I mean by “defining images”, let me give an example. In V3, single images are associated with piece faces and boards. The images which are displayed by VASSAL are the entire contents of image files which are inside modules. For us, one image file produces one image within the program. ZunTzu does this differently—its design supposes that an image file may contain many subimages that will be cut out and used as piece faces. With ZT, one image file can produce many images within the program. Our buildFile is where the definition of what image files coresspond to what in-program images happens; ZT has a similar thing inside its modules.

What an image definition does is name a region of an image contained within an image file, in order that this subimage may be referred to elsewhere. (We need some synax for talking about this; I’m going to use XML for now. I don’t mean to indicate by this whether we will or will not use XML.)

In the most basic form, where an entire image file is intended to produce one image, we might have this:

The src attribute indicates the name of the file, while the id attribute uniquely identifies the image contained therein. (The idea here is that we can then refer to the image by its id elsewhere,

rather than repeating the details of the image’s source.) I believe a unique id and a source are sufficient to capture how V3 defines images.

One can imagine wanting to define arbitrary rectangular cutouts of a larger image, say, an image containing multiple piece faces. To do that, we must specify the parent image and the coordinates of the rectangle to cut out:

This would give id 43 to the rectangle (10,10)-(60,60) in image 42. (Would w and h be preferable to x1 and y1?)

Furthermore, one can imaging wanting to define a whole grid of subimages in one shot—this is essentially what one side of a countersheet is:

Then, one might refer to such images by their grid coordinates, something like “44.0.0” for the subimage in the first row and first colum of grid 44.

Questions:

  1. Does this make sense?

  2. Are there any other ways of defining images which would be useful but can’t be done using the concepts above? or that can’t be done succinctly?

2

On Wed, May 23, 2012 at 09:06:51PM -0700, uckelman wrote:

Then, one might refer to such images by their grid coordinates,
something like “44.0.0” for the subimage in the first row and first
colum of grid 44.
…

  1. Are there any other ways of defining images which would be useful but
    can’t be done using the concepts above? or that can’t be done
    succinctly?

If you are going to allow grid definitions, it seems to me to be the acme of foolishness to not allow two more properties that define a stride allowing for a common sized gutter between each chit. Euros are often layed out like that rather than the tighter grid implied by your above definition.

The other issue that stands out to me in that case is applying a mask to the pieces. In Vassal 3, you use transparency to define non-rectangular pieces. If you are cropping out of a large image, the transparency is likely not there. So, the other property that may make sense to include is something like mask=“43”, which tells it to use the transparency (or maybe intensity) as an alpha channel on the image/grid being defined.

Jeff

–
“The man who does not read good books has no advantage over
the man who cannot read them.”
– Mark Twain

3

Thus spake Jeffrey Brent McBeth:

  1. Are there any other ways of defining images which would be useful but
    can’t be done using the concepts above? or that can’t be done
    succinctly?

If you are going to allow grid definitions, it seems to me to be the acme of
foolishness to not allow two more properties that define a stride allowing fo
r a common sized gutter between each chit. Euros are often layed out like th
at rather than the tighter grid implied by your above definition.

What I had in mind is the way that sheets of counters for wargames are
laid out. Judging by what I have to hand, sheets of 1/2" counters tend
to have blocks of 20 pieces without gutters in two rows of 10, and two
colums and seven rows of these blocks, with gutters between; 5/8"
counters will have blocks of 16, and two colums and five rows of such
blocks, with another half-row at the bottom.

I wonder if Euros have more gutters because they don’t need to fit as
many pieces on the countersheets, or if it has something to do with
die-cutting the pieces, since Euros tend also to use thicker cardboard.

Would something like this be adequate?

The intended meaning is to define a 6x10 grid of images with 5px gaps
between columns and 10px gaps between rows. The igrid example I gave
above is the special case where xgap and ygap are zero.

It occurs to me now that due to the regularity of wargame countersheets,
it might be useful to define grids of grids also. E.g., one could cover
a whole sheet of 1/2" counters with the usual layout quite succinctly by
defining it to be a 2x7 guttered grid of 10x2 gutterless grids.



The resulting images could again be referred to using their (nested)
grid coordinates: “1.1,3.9,1” would be the tenth piece in the second row
of the fourth block from the top on the right side of the sheet image
with id 1.

Hmm.

The other issue that stands out to me in that case is applying a mask to the
pieces. In Vassal 3, you use transparency to define non-rectangular pieces.
If you are cropping out of a large image, the transparency is likely not the
re. So, the other property that may make sense to include is something like
mask=“43”, which tells it to use the transparency (or maybe intensity) as an
alpha channel on the image/grid being defined.

I had been intending for masks to be specified at a higher level than
this, e.g., as part of defining piece faces:

My reason for this is that knowing what the mask is can be useful for
defining non-rectangular faces (as we do now)—the mask is needed not
just for adding transparency to some parts of the image, but also for
indicating which pixels are “in” and which are “out”.

Would anyone ever want to use different masks for these purposes? Doing
that would mean either having transparent pixels which are “in”, or
having opaque pixels which are “out”, both of which sound potentially
confusing to me.

–
J.

4

My experience as a press operator leads me to suspect this is because the pieces in Euros tend not to have the same background color between pieces, or between all the sides on a single type of piece?

5

Thus spake irishwulf:

“uckelman” wrote:

I wonder if Euros have more gutters because they don’t need to fit as
many pieces on the countersheets, or if it has something to do with
die-cutting the pieces, since Euros tend also to use thicker
cardboard.

My experience as a press operator leads me to suspect this is because
the pieces in Euros tend not to have the same background color between
pieces, or between all the sides on a single type of piece?

I know that alignment problems were common for games before the 90s, so
you had more leeway with the die cutting if adjacent pieces had the same
background colors. But I’m looking at a game from 2010 (GMT’s Nothing
Gained But Glory) where one of the countersheets has no fewer than eight
different colors extending to piece edges. These are in the standard
layout for 1/2" counters, and the cuts are flawless. Given the many
color changes between adjacent pieces, if they’d been off by 1mm, maybe
1/3 of the pieces would have eded up an ugly mess. So, the capacity
exists to be extremly precise these days—but maybe it’s cheaper if
you don’t need the precision? No idea, just speculating now.

–
J.

6

Regarding grids of grids:

It occurred to me that one way of achieving this is to permit horizontal and vertical repetition to be specified independently, like so:

  <img src="foo.png" id="42">
   <for y0="0" step="120" rows="7">
    <for x0="0" step="520" cols="2">
     <for y0="0" step="50" rows="2">
      <for x0="0" step="50" cols="10">
       <img w="50 h="50"/>
     </for>
    </for>
   </for>
  </img>

This would cover a standard sheet of 1/2" counters (with no selvage on the top or left sides—to add that, adjust the outermost x0 and y0). The intended meanings of the attributes of the for elements are:

  • y0: the leftmost edge
  • x0: the uppermost edge
  • rows: the number of rows
  • cols: the number of columns
  • step: the width of each row or column

x0 and y0 are relative to their parent’s coordinate system. The step attributes in the outermost two for elements are what produce the gaps between the 10x2 blocks of pieces. (10 columns of 50x50 pieces are 500 long in total, but the outer column step is 520, thus producing a 20px gap.) An img element without x and y attributes is intended to pick those up from its parent, in this case, the for elements enclosing it.

If there is no need for specifying horizontal and vertical repetition independently, then the same thing could be done a bit more succinctly:

  <img src="foo.png" id="42">
   <grid x0="0" y0="0" xstep="120" ystep="520" rows="7" cols="2">
    <grid x0="0" y0="0" xstep="50" ystep="50" rows="2" cols="10">
     <img w="50 h="50"/>
    </grid>
   </grid>
  </img>

This might be less error-prone, as it forces both dimensions of a grid to be specified at once.

Another capability we could easily support is grids with overlapping images:

  <img src="foo.png" id="42">
   <grid x0="0" y0="0" xstep="25" ystep="50" rows="2" cols="10">
     <img w="50 h="50"/>
    </grid>
  </img>

Because the xstep is 25 but the image width is 50, this would produce a series of images where the right half of one image is the same as the left half of the next image.