Armory: Node “Gate” - Execution Error (C/HL targets)

[e1e5en-gd]

Thank you for contributing to Armory!

Description
The event "On Surface" is used for control and it is calculated in which part of the screen the click occurs:

When running Windows (Krom) and HTML5 (JS) - it works:

When launched on a smartphone (Android(C)), the error is, the object always moves to the left (i.s. the condition is always False):

User with nickname @QuantumCoderQC confirms the same error on Windows (C) target (thread).

To Reproduce
Build a project using Windows(C), Android(C) as the target.

Expected behavior
The game should behave the same in both Krom, JS and C.

System
Blender: 2.83.4
Armory: git, master (Aug 19, 2020)
OS: Windows 10 64-bit
Graphics card: NVIDIA GeForce 930M

Test File
error_coord.zip
APK

[knowledgenude]

I think that the problem is having integers and floats in the comparison, but if it don't behaviours the same as in Krom, maybe it need some fix

Can you test an exported APK as this:

I don't have android studio installed and it is pretty big to download now
error_coord.blend.zip

[e1e5en-gd]

@knowledgenude, tried it - doesn't work.
I added the Integer node only when displaying coordinates, because Integer is displayed to calculate the center (I was guided by the output of screenshots).

[knowledgenude]

Can you test this just to make sure that the problem is with gate node? This also can be useful if you need a workaround on this

MoveUsingMouseCoords.blend.zip

I had installed android studio but it is returning "unknown HAXE_MODULE" error

[MoritzBrueckner]

Maybe the Dynamic type used by the gate node is the problem here. I can't test it on android, so can you try to find out if a simple integer or float comparison works? If yes, we might fix this by tweaking the return types of the connected input nodes.

[e1e5en-gd]

@knowledgenude, thanks for your help, this option works.

I had installed android studio but it is returning "unknown HAXE_MODULE" error

I didn't have such an error. Sorry, I can't tell you.
My version Android Studio:
Android Studio 4.0.1
Build #AI-193.6911.18.40.6626763, built on June 25, 2020
Runtime version: 1.8.0_242-release-1644-b01 amd64
Android Gradle Plugin Version: 3.5.1
Gradle version: 5.4.1
Build Tools Version: 29.0.2
NDK: 21.3.6528147

[knowledgenude]

I've changed my OS and now Android Studio works. I did a test with this:

It works as expected, even changing the input positions in the gate node (each cube has a different trait layout)

untitled.zip

I think that the issue is with sensor/mouse coords, and i also expect that movement coords have bugs in C targets too, because i already faced a similar thing it in the past

I did one more test using 555 integer and 555.000 float without issue

[e1e5en-gd]

@knowledgenude, does not work in this version:

[knowledgenude]

Then problem is the value given by Separate XYZ. Also trying to compare it with a float is not working. Another workaround here that works is to put a Math node with 'round' between the separated vector and the gate node:

I couldn't understand, the problem is with gate node and separate xyz together

[MoritzBrueckner]

I suspect that there is an issue with comparing kha.FastFloat values as returned by the Separate XYZ node to "regular" floats, maybe in combination with dynamic types.

Changing

if (from == 0) return vector.x;
else if (from == 1) return vector.y;
else return vector.z;

in SeparateVectorNode.hx to

if (from == 0) return cast(vector.x, Float);
else if (from == 1) return cast(vector.y, Float);
else return cast(vector.z, Float);

fixes the issue for me on the Windows (C) target. But that solution isn't that good probably as it discards the advantages of using FastFloats (less precision for better performance).

[knowledgenude]

But why is this happening just with the gate node? I think that in the math node the comparison is right.

Probably don't worth to have less performance in separate xyz just for gate node, because is very common to have a lot of separate xyz in the traits.

Maybe the greater equal, less equal, etc. should be moved to the math node and compared in the gate node as booleans, or this is bad for performance too?

[MoritzBrueckner]

The Math node doesn't use kha.FastFloat, it casts the incoming values to floats at the beginning of its execution. But we can't do that with the Gate node as it should work on multiple types. Probably this issue happens in a lot of nodes.

But actually, if there is a cast in the Math node I think we could also cast to float in the Separate XYZ node. Nodes are slower than self-written code anyway so maybe it's not that big of an issue to have a tiny bit slower code.

[knowledgenude]

This makes sense, at least everything will work fine. I think Separate RGB should need this fix too

[MoritzBrueckner]

So I found a minimal working example of the bug:

var a: kha.FastFloat = 4.123;
var b: Float = 4.120;

// Without those two lines, both C and Krom would print 'true'
var aD: Dynamic = a;
var bD: Dynamic = b;

// Krom: true, C: false
trace(aD >= bD);

I've opened an issue on the Kha repo here. If it can't be fixed, we can check for FastFloats in the Gate node and cast them to floats

[MoritzBrueckner]

Looks like it is a Haxe bug (I've opened an issue on their repo). It's probably better to find a workaround instead of waiting for it getting fixed? Even if the fix would be included in the next Haxe version, Kha would need to be updated and Armory would need to update to the latest Kha version which might take a while.

[Sanva]

@MoritzBrueckner this looks like a Hashlink bug, it's working fine with C++ — I'll take a look at it this week.

[Sanva]

This works for me using Linux (C) target with this change to Kha/KoreHL → https://github.com/Kode/Kha/pull/1238 .

[e1e5en-gd]

Sorry I haven't checked it for a long time.
Everything works on Android (C).