Air Manager 3.0 New Lua functions and differences?

[JackZ]

I think we should look forward and not backwards. We have already corrected over 50-60% of the instruments for OpenGL by tweaking them, To now render this majority incorrect by fixing the 2.1.3 error seems counter productive. Once all instruments are corrected there is no advantage going forward. It really takes only a few minutes to realign the objects and adjust text on most gauges. It is a pain but once we are past it, it will be done.

Agreed about "looking forward", but the idea of a directive such as "#v3.0compatible" was to give the opportunity to simplify things, since you can add it or not in the code.
Anyway...Apart the ASPEN or other glass cockpit gauge which contains LOTS of texts, most of the instruments only contain one or two texts resources.

Jacques

[russ]

I am confused. Are there any fonts "built-in" to Air Manager? If not could we have some basic fonts included so that every font file used does not need to be duplicated in many different instruments.

I nominate the whole Arial package, the digital-mono-7 and that Milspec font that JackZ found for a few. Don't know if it is possible but I see arial is almost one Megabyte in size so why carry this unneeded overhead around in many different gauges.

[russ]

JackZ...the Aspen is a difficult instrument when it comes to text but it is so worth the work. Happy to help if I can...after FlightSimCon though as that has me busy right now.

[Corjan]

Hi,


I have taken a look at the text rendering in AM 3.0.
There was a problem in converting the characters in the lua script (UTF-8) to the memory layout FreeType uses. That has been fixed (on Windows at least, still have to test on Pi etc.). I will include this in the next BETA, somewhere at the end of the week probably.

There is in fact an ascending and descending value in FreeType, but from what I read, these values are kinda unpredictable. I'm leaning to not add those into the calculations, that is also what all (at least the once I saw) FreeType examples seem to do.
https://www.freetype.org/freetype2/docs ... step2.html

I'm not sure why javafx renders the text thinner than FreeType does. You would expect them to be the same . Not sure what to do about that, I'm afraid there will be some changes between AM 2.3.1 and AM 3.0 when it comes to text.


Corjan

[JackZ]

Conversion calculations using font metrics will always be a workaround in order to convert text position from one version to another. The idea is to have them done by hand and yield to at least an offset parameter to be added.

You are right Corjan, though, font metrics are not consistent within each font file, as font developers sometimes do not adhere to the standard definitions. As an example, I noticed
that the digital-7 returns wrong metrics values when compared to Arial for example. Aniway this can give some hints about the y_offset to be added to the original y value in v2.1.3.

As per the font rendering difference with JavaFX, I noted from the Freetype documentation that there is two ways of rendering a character: an antialiased and a monochrome one, the antialiased being by default
Maybe this behavior comes from this parameter?

The second parameter is a standard render mode to specify what kind of bitmap we want. For example, it can be FT_RENDER_MODE_DEFAULT for an 8-bit anti-aliased pixmap, or FT_RENDER_MODE_MONO for a 1-bit monochrome bitmap.

Jacques

[JackZ]

I've also found this parameter: FT_Pixel_Mode
Wow, it seems that text rendering in OpenGL is far from a paved road...

https://www.freetype.org/freetype2/docs ... Pixel_Mode

Jacques