Air Manager 3.0 New Lua functions and differences?

[JackZ]

Another thing I noticed: The dials seem to be slightly offset (1 or 2 pixel to the left and up) in v3.0, when compared to the 2.1.3

Here's an example with the same code ( v3.0 is above)

Still trying to figure the text display logic in v3.0. Up to now I get strange results to say the least!

An additional question to Corjan:
in create mode, when pressing the Run button, the gauge is now displayed over a black background instead of a white one as it used to be. the problem is that drop shadows are no longer visible on the black background.
Is this black background mandatory in the Open GL version?


Jacques

[Ralph]

I have that problem too, it has a 1 pixel offset.

[Corjan]

Hi,


The dial offset is actually a bug in 2.1.3, something that is fixed with AM 3.0.
I'm afraid you have to change your instrument code in order to fix this misalignment.

I have created a wiki page where I will try to keep track of any changes that have to be made between AM 2.x and 3.x.
Please let me know if I missed something.

And thanks Jacques for the comments, really appreciate it!
I will dive into the text rendering subject tomorrow. I used an example I found on the instrument once for the character positioning, which might not be very smart looking back


Corjan

[Corjan]

Also, the background will be white again in the next BETA

[JackZ]

Hi,
The dial offset is actually a bug in 2.1.3, something that is fixed with AM 3.0.
I'm afraid you have to change your instrument code in order to fix this misalignment.

Corjan

Wow, that's going to be a nightmare, converting all the gauges! Though most of the time the offset is unnoticeable.
Wouldn't it be easier to add an offset of +1right,-1down pixel to the new dial add? Eeven better would be a "compatibilty" directive to add at the begining of the code, to force javaFX to add or not this offset at Runtime. Don't know if it is possible though...

For the fonts, I have created a small test gauge in 2.1.3 and 3.0 so I can compare both texts. It's a quick and dirty one, it uses the grid function I created.

I can forward it to you Corjan if you ever need it.

Jacques

[JackZ]

I have created a wiki page where I will try to keep track of any changes that have to be made between AM 2.x and 3.x.
Please let me know if I missed something.

Corjan

Corjan, may I suggest you also specify the need to place EACH font .tff file used in a 3.00 instrument in the respective resource folder to be used by the gauge?
I understand that means duplicates in font files, but that is the price of crossplatform compatibility I guess...

I checked the file size: For Arial.ttf it's 893Kb which is quite big.
Is there a possibility to place a frequently used font directly in the AM resources folder to save space?

Jacques

[Corjan]

Hi,


I'm not to keen on creating a compatibility mode. I think it is easier to just change the dial position.

There is a 'fonts' directory in the AM installation folder. The application will also look there if it needs to resolve an instrument font.
Although I don't recommend this, the best way is still to embed the font into the instrument. Also think of when you push an instrument to another device, like the raspberry pi.

It would be great if you could you send me the test instrument. That will help me allot with reproducing this problem.


Corjan

[JackZ]

As per the font positioning difference, here's what I found so far (version 3.00 is below):

1- The text in v3.0 is slightly bolder from previous version
2- accentuated characters are improperly rendered in v3.0 (see the four characters after "AB12" in v3.0, they should be "éè")

3-The text's baseline in v3.0 is positionned using the font_size glyph's metric property, that means that the bottom of a capital letter is located at y+font_size pixels below the y position given in txt_add()

4- in v2.1.3 the text baseline was positionned using the font_ascender glyph's metric property, that means that the bottom of a capital letter was located at y+font_ascender pixels below the y position given in txt_add()
In our case, the App "Font Metrics" gives an "ascender " value for Arial 80 of 72.42pixels that means that the text's y position is "off" by(font_size-font_ascender) pixels
Below are the test tools I used (one for each AM version)

Jacques

[russ]

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 adopting the 2.1.3 error in 3.0 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. To me the nil image errors are a bigger nuisance... but I do like the fact that the fact that these previously tolerated errors are now highlighted and required to be eliminated.

[JackZ]

Fist v2.13 gauge converted towards v3.0:
The text definitely looks blurrier, probably due to the font rastering process. Maybe some "hinting" to add to characters in FreeType/SDL?

V3.0 is below

Jacques