Yellow Label size in case of high screen resolution

[TwinFan]

Current Situation / Problem
Follow-up to #60:
The yellow a/c labels are unreadable in VR view, probably due to high resoltuion.

Suggested Solution
Adapt label size to screen resolution.
This would be a change in the multiplayer library.

Benefits
Readable labels also in high screen resolution situations like VR.

[TwinFan]

While playing with a Parsec server with a lot higher rendering capabilities than my little MacBook I started to understand why the labels are unreadable...so I actually have a test bed.

Drawing labels is in xplanemp, XPMPPlaneRenderer.cpp, function XPMPDefaultPlaneRenderer, PASS 4 - Labels using a more or less simple call to XPLMDrawString. That call uses a font id, but has no way of passing a font size! (BTW...the two lines above deal with the color as in #53)

While searching for changing the font size found this article on a general setting in XP11. Maybe that helps, to be tested...because the API provides no way to the developer. But then there is this forum thread specifically also mentioning xsquawkbox (which uses the same library) having no chance of changing the font....

[TwinFan]

I‘ve commented here in the forums how this problem has to do with SSAA antialiasing. Should file a bug with Laminar, though.

[TwinFan]

Filed a bug with Laminar, accepted as XPD-9785. That will be listed in release notes if fixed.
Also means: I can't fix it myself but depend on Laminar.

[TwinFan]

Ben Supnik himself replied:

„This behavior will not be fixed in future updates; it is a design limitation of the plugin system. The work-around a plugin can/should do is to save the 3-d location of text drawing and then issue the text during a 2-d drawing callback, where the screen is operating in boxels and thus has known scaling properties.

cheers
Ben“

So it‘s back to me then.

_{Sent with GitHawk}

[TwinFan]

The changes solve the issue half-way: Label size is now OK with all antialiasing settings, but the label position is off when SSAA comes into play by the same factors as the label size before, just inverted. I don't find any dataref, which helps me identifying the situation...so far the only guess regarding the antialiasing setting is to read X-Plane.prf, which has a setting renopt_HDR_antial. If we read that during startup and apply coordinate fixes we are mostly correct...only if the user changes antialiasing settings mid-way we would need a way to reinit that config.