NanoVG API not rendering data correctly (stretched) Blocker Bug

[MSFS 2024] Bug Reports WASM
,
1

Version: v1.2.7.0 (MSFS 2024)

Frequency: Always

Severity: High BLOCKER

Similar MSFS 2020 issue: No

Context:NanoVG API not rendering data correctly (stretched images)

Attachments: None

Bug description:

Thank you for fixing the previous WASM loading package bug, which has enabled to move us further with MSFS 20204 compatibility, the fix and the expertise is much appreciated. Unfortunately a new issue has arisen:

This bug is new to MSFS 2024 patch 3 (v1.2.7.0), in our internal testing with past MSFS 2024 versions, we did not experience this bug at all, so this is a newly introduced bug.

Screenshot from MSFS 2024 showing the bug is at the bottom of this message!

This happens in WASM: after creating a bitmap using the provided GDI class, of size 650 by 768 pixels: nvgCreateImageRGBA (internally: fsRenderCreateTexture)
And then render it with: nvgUpdateImage (internally: fsRenderUpdateTexture), the MSFS display engine draws the image stretched (as shown in the image below), analyzing under the debugger, the nvgUpdateImage, calling renderGetTextureSize (internally: fsRenderGetTextureSize) returns an internal bitmap size of 652 x 768 pixels.

This bug could be related to some internal MSFS 2024 calculations being changed, it happens with other resolutions as well.

This is a core MSFS 2024 bug blocking our product completely. Could we please have an expedite fix on this bug so our users can use our product? It was frustrating to have to wait for the WASM loading bug to be fixed, only to be hit by a new bug.

It would be great if this bug can be released as a hotfix before the holidays.

Thank you and we are looking forward to your reply.

Best regards,
Tiberiu
TDS Sim Software

Repro steps:

gfx->DrawImage(g_BitmapGraphics.imageDrawing, 0.0f, 0.0f);
which on first step calls:
from nanovg.cpp nvgCreateImageRGBA with 650, 768px

then on each new draw, the same function:
gfx->DrawImage(g_BitmapGraphics.imageDrawing, 0.0f, 0.0f);
calls:
from nanovg.cpp nvgUpdateImage
intnerlly:
ctx->params.renderGetTextureSize(ctx->params.userPtr, image, &w, &h);
width is returned as 652(WRONG!!!)
height is returned as 768(correct)

image
image739Ă—605 74.6 KB

6 Likes
2

After a bit of more research, modifying the panel.cfg LCD gauge size from 650*768 px to 652x768 px will result in the screens rendering correctly.

However this is not feasible for modifying +50 add-ons and a few hundred panel.cfg by each aircraft developer and breaks past compatibility.

2 Likes
3

Please get this fixed ASAP, we need the TDS!

1 Like
4

Please help prioritize this fix. We’ve been patiently waiting for the previous WASM fix released yesterday to clear the usage of the TDI and other similar addons, so getting this newly introduced bug was pretty upsetting.

1 Like
5

Hi everyone,

Just in case you haven’t noticed, this issue is tagged as “bug_logged” which means it is being investigated/fixed. We will let you know when the fix is likely to be released.

Best regards,

Eric / Asobo

5 Likes
6

@EPellissier

I believe this issue should be high priority. I have several testers/customers with crashes. I have traced it specifically to nvgCreateImageRGBA/fsRenderCreateTexture.

When nvgCreateImageRGBA/fsRenderCreateTexture is created with data from memory(upload texture data), some customers are getting CTD with Access Violation 0xC0000005 errors.

2 Likes
7

Hi everyone,

We believe we have found the fix for this new issue. Unfortunately I don’t have an ETA yet.

Best regards,

Eric / Asobo

3 Likes
8

Hello @EPellissier ,

Thank you very much for the prompt response and for the bug fix, this is very much appreciated!

Tiberiu

9

Hello @JoshC_FSim ,

You are correct, creating the texture with null data does not provide the bad coordinates and does indeed seem to be working well, it is an excellent find and through this I thank you very much for sharing it!