Add Unit Count and Damage Display Outline

[Hepps]

@alkexr I'm easy. I do not profess to know the best way to handle this from a technical standpoint. All I know is that after rendering a near infinite number of trees, hills, mountains and houses.... I can probably design as many numbers as we could possibly need.

[prastle]

@hepps we allllll know YOUR EASY! nice ideas

[Hepps]

@prastle You only know that because we've been on a date. If you hadn't been swept off your feet by my rugged good looks and charm... you'd have not idea.

[prastle]

@hepps ROFL!
yes dear

[redrum]

@Hepps So is the main point having a nice outline for the unit numbers? If so I'd probably want to consider doing it without images first before falling back to that option. But what you propose should be theoretically doable and I'd probably agree with @alkexr to draw each digit so less images are needed.

Also the benefit of figuring out how to do it programmatically is we keep the font size options. Though I guess in theory you could do something with image sizing.

[Hepps]

@redrum I am open to all kinds of options... fast and loose that's how I like to play it.

I guess just working on a couple different maps lately I started to really see how the monochrome pixilated numbers are a huge opportunity for maps. And while antialiasing alone would be an improvement, it by no means solve the issue of maps with a variety of unit and territory colours, shading, reliefs, unit colours.....

So while pondering it I thought the best would be a outline. the reason I suggested an image is really a by-product of two things...

First I thought an outlined number was not possible to render currently. (as a font)

Second I thought if they were images then it allows the creative juices to just flow, since you could do all kinds of wonderful things both with numbers as well as backgrounds.

[alkexr]

@redrum said in Inception: A dream within a dream (Unit stack numbers display):

figuring out how to do it programmatically

In C# what I would do is to draw the number (string) to a Bitmap first (don't know java equivalent). Then for each pixel P, you take the maximum of (alpha of pixel Q * strength - Euclidian distance(P, Q) * sharpness) over all pixels Q on the bitmap, this will be the alpha of the outline. Then you overlay the original bitmap over the outline. (Strength and sharpness are parameters.) If you only take the maximum over pixels Q within a radius of (255 * strength - sharpness), then you get the same result in O(n^2) relative to the height/width of the bitmap.

[Frostion]

Just outlining the current numbers would be a great improvement! The default white numbers can be hard to see and distinguish on bright territory backgrounds. (Yes, I know that I can change colors... But I don't want to )

[redrum]

So here a first go at it:

And with a large number of units:

Before:

[Hepps]

@redrum How is that possible? How was this able to be done so quickly?

[redrum]

@alkexr That's a bit more graphics kungfu then I'm doing at the moment. Initially, I'm just outlining the text by first drawing it at the 1 pixel over northwest, southwest, northeast, and southeast positions with the outline color and then drawing the text in the center with the text color. As well as enabling anti-aliasing.

[Hepps]

@redrum All good. I just thought this would be a much bigger undertaking...

"To the uninitiated everything appears to be made of magic"

[redrum]

@hepps Well, my pretty simple approach took about 5 minutes. Ask and thou shall receive

Open to trying some other ideas if folks want. Probably gonna at least add an option to set the outline color as well.

[Hepps]

@redrum That was my very next question.

I'm going to use inception more often. It appears to be highly effective as a title.

[redrum]

And did unit and bombing damage as well:

[redrum]

And the update font preferences:

Any thoughts on defaults? Unit color/outline as white/black seems good. But black numbers with white outline are a bit jarring. Maybe do a gray for default outline for hit and bombing damage? Also should the default font size be a bit bigger? 12 seems really small on most screens/maps.

Current defaults:
private static final int MAP_FONT_SIZE_DEFAULT = 12;
private static final Color TERRITORY_NAME_AND_PU_AND_COMMENT_COLOR_DEFAULT = Color.BLACK;
private static final Color UNIT_COUNT_COLOR_DEFAULT = Color.WHITE;
private static final Color UNIT_COUNT_OUTLINE_DEFAULT = Color.BLACK;
private static final Color UNIT_FACTORY_DAMAGE_COLOR_DEFAULT = Color.BLACK;
private static final Color UNIT_FACTORY_DAMAGE_OUTLINE_DEFAULT = Color.LIGHT_GRAY;
private static final Color UNIT_HIT_DAMAGE_COLOR_DEFAULT = Color.BLACK;
private static final Color UNIT_HIT_DAMAGE_OUTLINE_DEFAULT = Color.LIGHT_GRAY;

[redrum]

Last but not least the PR with the changes: https://github.com/triplea-game/triplea/pull/3488

[Frostion]

Personally I think 12 is nice. Especially since the unit pictures themselves are pretty small. If pictures were bigger, then the text should of course also be set to be bigger.

[prastle]

@frostion The colour blind bastd chimes in white is best but either are an improvement just my 2 cents

[Cernel]

I'm a little bit shocked that this thing that has been discussed so much turned out to be such an apparently fast thing to do.

Some considerations on my part:

1. I definitely believe 12 font size is absurdly small I cannot believe it is ideal for anyone. I'm on a 27" full HD, not having any relevant visual impairments, and using 24, and know that many are on smaller screens or laptops. I would say default 24, but it should really at very least be 16.

2. It would be good if the "Edit Map Font and Color" are set per map, not generally, as you can prefer different settings per map (maybe a button with "setting all", for all maps) and the mapmaker can set the defaults in map.properties, especially now that a better zoom is being made (I think the most extreme example to date is Conquest of the World, in which you would want to have a much bigger font size than other maps).

3. Currently there is an issue (it can be argued it is a bug) with using Font Size together with name_place.txt: it draws the name from the left, thus their barycentre shift to the right when you increase the font size, making such an option scarcely useful, unless you are drawing images in place of names (see below) (you can test this with Pact of Steel, setting Unit Size at 24: Eastern Europe will be in the middle of itself and Belorussia and most name will overboard to the right, basically obtaining the opposite of what name_place.txt is supposed to be for). If this issue is not solved (in a way to keep the barycentre fixed, even tho the drawing is from the left), and especially if the default is changed, I then advise name_place.txt to be made ineffective in changing position of names not recalling images (meaning still working for 270BC but not anymore for Pact of Steel).
   This is also a liability to changing the default font size, as this option works in drawing names from the left, and I assume it has been optimized in current maps having it for font size 12, which is not advisable to keep as reference, if it is changed as default; so I don't really know how this issue can be feasibly solved. Maybe it is just anyway better to reserve the name_place.txt for image based names only (this would need updating pact_of_steel), tho the option itself does have a value, since sometimes the autoplace is not so good, and you may not want to go as far as having images for all names.
   A way to solve this issue may be to have a setting for specifying, inside the "name_place.txt", what font size such coordinate are meant for, and having the engine, then, assuring the barycentre stays the same when changing Font Size. In this case, pact_of_steel would need to be updated to specify a value of 12 for it, assuming a new default. If the settings are customizable per map (see the point above), we can, instead, just assume the reference is the setting. In this case, pact_of_steel would need to be updated to specify Font Size 12, generally.

4. The Font Size setting defines the dimension of the regular names, but not of those drawn by calling images (it will change the dimensions of the names of World At War, but not of those of 270BC). I guess this is an advisable behaviour, as now, at least, as you can assume that images based names have been tailored for the map closely (so I agree better not having an option for specifically zooming them, also because of the placing issues at the point above), but this is somewhat generally incongruous, so it may be advisable splitting the Font Size setting between "Territory Name and PU Font Size" and "Unit Font Size".

5. "Territory Name and PU Color" is wrong (PU means Production Unit, and identifies resource stocks, not territories productions (your PUs are the money you have, not what you can get)). It should be "Territory Name and Production Color".

6. Are you sure it is still necessary to keep that bug disclaimer at the start? Any chance that bug is not so relevant anymore, after so many years?