I have some relatively large non-rectangular game pieces (on the scale of 1500 px square, about 20% transparent) It would seem that when i try to implement the non rectangular trait for these pieces, vassal locks up, and I have to force the task to close.
My Specs
Model Dell Precision M4500
Operating System Windows 7 64-Bit
CPU Intel X 920 @ 2.0 GHz
Memory 8 GB
Video Card NVIDIA Quadro FX 1800M
Vassal version. 3.1.17
Java version. 1.6.30
I have tried it on another machine with different specs and gotten the same result (don’t have the specs on hand atm)
I have some relatively large non-rectangular game pieces (on the scale
of 1500 px square, about 20% transparent) It would seem that when i try
to implement the non rectangular trait for these pieces, vassal locks
up, and I have to force the task to close.
My Specs
Model Dell Precision M4500
Operating System Windows 7 64-Bit
CPU Intel X 920 @ 2.0 GHz
Memory 8 GB
Video Card NVIDIA Quadro FX 1800M
Vassal version. 3.1.17
Java version. 1.6.30
I have tried it on another machine with different specs and gotten the
same result (don’t have the specs on hand atm)
When you tried this, how long did you wait before killing VASSAL?
The dungeon tile deck, i want those 5 pieces to have the non rectangular trait.
I have heard that java limits its memory usage through a system variable. I thought that perhaps vassal was hitting the ceiling due to the large size of the tiles. Perhaps I would need to increase the system variable for java memory? Let’s get dangerous…
The dungeon tile deck, i want those 5 pieces to have the non rectangular
trait.
I have heard that java limits its memory usage through a system
variable. I thought that perhaps vassal was hitting the ceiling due to
the large size of the tiles. Perhaps I would need to increase the
system variable for java memory? Let’s get dangerous…
I can reproduce this, and will investigate further. It appears to be a
bug.
However: Why do you want these pieces to be non-rectangular? The
contents of the images look rather rectangular to me. If what you
really want is for some parts to be transparent (or semi-transparent),
you can achieve that just by editing the images.
The dungeon tile deck, i want those 5 pieces to have the non rectangular
trait.
I have heard that java limits its memory usage through a system
variable. I thought that perhaps vassal was hitting the ceiling due to
the large size of the tiles. Perhaps I would need to increase the
system variable for java memory? Let’s get dangerous…
I can reproduce this, and will investigate further. It appears to be a
bug.
The problem is in NonRectangular.setShapFromImage(). We’re extracting
the shape of the opaque area from the transparency mask by finding each
pixel which is not totally transparent, creating a 1x1
java.awt.geom.Area corresponding to it, and then unioning those to
another Area in which eventually becomes the shape. The problem with
this is that unioning Areas is hideously slow, and for a 1500x1500
image, you have to do this 2.25 million times. Even worse, this is not
done on a background thread, so it locks up the GUI while you wait for
it to complete.
The reason I want the pieces to use the non rectangular trait is due to the mechanics i want the piece to have. Specifically, the board is a 12x12 grid with a half square border. There are 5 such pieces and a given game could use anywhere from 2 to 5 of those tiles, arranged in a variety of ways and orientations. Once placed, they form the main playing area, to which the various playing pieces should snap into the 1 inch squares that are on the tiles.
Taking the 12x12 tiles as is, the center of the board ends up being at an intersection, rather than the center of a sqaure. Thus when the tile is placed on the mainmap, which has a square grid, pieces end up snapping to intersections, rather than the center of the squares. The solution was to create a transparent border around the tile that offsets the center of the tile to be the center of a square. This creates a transparent border around the piece that I had hoped to get rid of by using the non rectangular trait.
An alternate solution would be an option somewhere in the definition of the piece to change the point that is used on the piece to snap to a grid, rather than automatically defining it to be the center of the piece.
A related trait is Can Pivot, which allows me to define the point around which the piece rotates, rather than just the center of the piece, but it still snaps to the grid based on the geometric center of the rectangle.
It is entirely possible that a more elegant solution exists in vassal, so I am open to suggestions.
Zhavier -
What about the following? Not necessarily more elegant, but certainly faster:
After placing the pieces, use Replace With Other to replace the pieces with identical-looking pieces with the following traits:
Does Not Stack → Ignore map grid when moving
Send To Location → Map: blank, Board: blank, X: $CurrentX$, Y: $CurrentY$, advanced:
The additional advantage with this is you can ‘lock’ the pieces in place using Does Not Stack - but of course that’s also the disadvantage.
I’ve committed a fix to trunk@8072. Rather than create one Area per
opqaue pixel, we now create one Area per horizontal stripe of opaque
pixels. This dramatically cuts down on the number of times we have to
call Area.add() for typical image masks. (You will still see very poor
performance if you have an image mask where every odd pixel is opaque,
but I don’t suppose anyone will do that.)
