GordonMolek
commented
5 months ago OK, some progress.
[image: image.png]
The right counter is based off of (what I believe to be) a 1,000 x 1,000 "pixel" SVG base image. It is constructed in game by compositing a:
German base color counter image A "slow turret" white square image A red 11 front armor value image A red superior front armor square image A black 8 side/rear armor value image A white tracked movement type symbol image A text field for the 88L main armament A text field for the red 12 movement points value A text field for the "3/5" machine gun values A path image for the Tiger tank (rotated from a base image suitable for the wreck side of the counter, e.g., pointing 90 degrees/to the right)
Obviously some sizing and positioning issues need to be finalized but I think this is a pretty good proof of concept. I think armor values probably make the most sense as images rather than text fields as there are a limited set of values (including the unarmored "star") and they need to be properly aligned with each other and the superior/inferior symbology. Similarly for rate of fire and breakdown numbers. I think MPs, MA and MGs can be left as text fields. The database for the counters would then be a mix of text fields and identifiers for different SVG files to overlay. Will that work?
On Wed, Feb 21, 2024 at 9:50 AM Gordon Molek @.***> wrote:
Thanks, I'll look into that.
On Wed, Feb 21, 2024 at 9:15 AM Joel Uckelman @.***> wrote:
The default unit for SVG is pixels (but these are not screen pixels, they're abstract pixels). I would not recommend using any of the other absolute units, as you will inevitably come to grief by ending up with a mix of units.
— Reply to this email directly, view it on GitHub https://github.com/vasl-developers/vasl/issues/627#issuecomment-1956901141, or unsubscribe https://github.com/notifications/unsubscribe-auth/AYLTFUVWMMTKQQWQ6BCHTCDYUYFQTAVCNFSM4LRCVSM2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJVGY4TAMJRGQYQ . You are receiving this because you were mentioned.Message ID: @.***>
uckelman
apbills
derimmer
zgrose
BigAl737
I'm opening this topic to record a history of discussion concerning SVG file format implementation into VASL. An older closed thread (#218) provides a little more history.
So what do we gain by using SVG?
To answer this I ran a test, the results of which are in the screen shot below (double click the image to get full clarity).
The top row is normal VASL using a png image for the basic piece and VASSAL handles the rotations.
The middle row uses an SVG image for the basic piece and VASSAL handles the rotations.
The bottom is an SVG image for each rotation orientation using an added Layer trait. VASSAL is NOT handling the rotations. However, all the rotated images in this third example that you see are generated with the removal of the ruCTtur prototype. This is important to point out because with the inclusion of the ruCTtur prototype, VASSAL would handle the rotations. It's interesting to note that the SVG image for each orientation maintains better clarity than the above examples. If VASSAL handled the rotations (i.e. with the inclusion of the ruCTtur prototype), the results were almost identical to the middle row.
As expected, clarity is maintained with SVG images, even when zooming in. What I didn't expect is the improved clarity attained even when rotated through the use of a Layer trait.
A side benefit with SVG images is the improved clarity for backside information (smoke availability, CS, etc). Here's a screen zoomed in at 150%. I can make the superscripts more legible. Same order of formats as above.
The Has Info window amplifies this information as well but simply zooming in on a SVG wreck depiction allows easy reading of the notes information. With this being the case, I don't see the need to use the Replace With Other trait for Wreck depiction. I can generate a Wreck prototype that offers the same menu selection options as the current wreck counters. These menu options could be hidden from view until the Wreck layer is active. The only thing we lose is the ability for different information in the Has Info window. Typically the only thing in that window for a Wreck counter is the CS # and MG armament. Using SVG, the CS# is easily visible now and if you do need to check the MG armament, just momentarily flip the counter over to it's non-wrecked side.
Finally, SVG offers more benefits if the Mouse Over Stack trait is changed to show units in an unrotated state. Here's a screen showing what that would look like zoomed in at 150%. Easy for my aging eyes to read for sure.
For comparison, the top most screen shot shows these same images at 100%.
What are the SVG drawbacks?
You need to start with an SVG image to gain the benefits. Vectorizing a raster image isn't gonna gain you anything. Hence, the vast majority of current VASL images will probably never be vectorized.
An SVG image is larger than a png or gif image. A 60x60 SVG image is about 65kb vs about 6kb for a png image. Eventually the addition of SVG images will increase the size of a module. And remember that to achieve the clarity in example 3 above, each SVG counter contains 6 SVG images.
I do see benefits for SVG though. Markers can be more readily vectorized to achieve better readability. New additions to VASL (like BFPs OtO2) can be vectorized from the get go. VASL can process both gif, png, and SVG in a manner transparent to the player.
I've opened this issue for education and discussion. Please consider what I've posted here and chime in with your thoughts.
Allan