Fix rotated frames not rendering on Hashlink

[rifxii]

Closes #3433

This seems to solve the previously mentioned issues I had with rotated frames not rendering on Hashlink.

Judging by what I saw while testing, it seems that the HL compiler is inlining MatrixVector.set by using pointers of the given variable. So instead of the set function in MatrixVector.copyFrom performing this[0] = -b; this[1] = a;, it's instead doing this[0] = -this[1]; this[1] = this[0]; and messing up the whole matrix.

I also found setting a reference to the variables before set() also fixes the issue WITHOUT the removal of the inline but I'm not sure which one is better to deal with and if there's any sort of performance loss from removing the inline.

Example:

#if hl
final a:Float = a; 
final b:Float = b;
#end

set(-b, a, ...);

[MaybeMaru]

If you haven't already this should probably be reported to the Hashlink or Haxe repo too. Seems like a very important issue with the target.

[rifxii]

After a bit more testing I've discovered that the odd behavior with Hashlink is able to be reproduced on the other platforms that I've tested. I created an issue on the Haxe repo regarding this: HaxeFoundation/haxe#12331.

I'll close the PR for now since this seems to be a non-flixel issue.

[Geokureli]

Reopening this issue, in case other people have this issue and don't know who to blame, or want to track when it's fixed.

Thanks for tracking this down and making a new issue, I'll monitor and close this when it's fixed

Edit: Oh wait, this is a PR, I'll post the link on the actual issue

[Geokureli]

Also, I've been extremely busy and forgot about this PR, if this prevents the error, I'm okay with merging this, since the haxe change won't fix haxeflixel's minimum supported haxe versions.

Do you still think this should be merged?

[rifxii]

I've been using this change for the past day while testing my project and I haven't had any problems happen so I'm not against merging it. Would this require another PR in the future to update the conditional to check the user's haxe version if the issue is fixed in a future haxe release?

[Geokureli]

I've been using this change for the past day while testing my project and I haven't had any problems happen so I'm not against merging it. Would this require another PR in the future to update the conditional to check the user's haxe version if the issue is fixed in a future haxe release?

We could make it #if (haxe5 || !hl) now, or we can wait until it's fixed to add it. If now, people using haxe5 won't be able to use rotated frames until it's fixed in haxe. IMO, using either haxe5 or rotated frames are both very uncommon... up to you

[rifxii]

When typing that reply I completely forgot that this issue in particular only affects Hashlink, whoops. I think leaving the current conditional alone is fine since I'm not sure if anything would need to be fixed on Hashlink's side and if so, their updates seem to be on a yearly schedule so that wouldn't be anytime soon.