Ya, but that's not what one would call "working normally" str.charAt should just work, Utf8.whatever should only work on things which are explicitly utf8 (normal Haxe string nowadays are not). I will get to that (or I'll just bug Hugh about it).

str.charAt should work, will look into that. Utf8.whatever is only properly working after you used Utf8.encode I think. Maybe. No idea if the thing is up to date at all, docs still talk about iso strings, whatever that might be.

Wait a minute, that isn't even supposed to work. In hxcpp fancy strings are now utf16 so Utf8.charCodeAt isn't the right thing to use in your sample.

Aha. That's likely because I activated smart_strings in hxcpp (aka unicode support) which isn't much tested yet. Will have a look tonight. That "bug fix" only takes action when writing a file.

No, that in general doesn't work at all. g2 uses g4 if it's available so when you take a look at the g2 implementation you can carefully mix it with g4 but in most situation this will mess things up - in particular if you call g4.begin instead of g2.begin.

That's a bug I think. GitHub issue please.

I updated everything to the latest Android Studio things and that fixed it by itself without me having to define char16_t again. Please test.

ok, that looks straight forward enough, looking forward to the pull request.

Oh, sounds complicated. Some sources I can look at hidden somewhere?

My fault, cleaned up a bit in my hxcpp fork yesterday and didn't yet test on all targets.

Give it a go.

Don't know, probably not. The reason that happens at all is because Windows itself pauses the message pump thread when the window is changing. When I find some time I'll put that in a separate thread to prevent it.

Guess that hasn't been implemented. Open an issue on GitHub please. Meanwhile give the android-native backend a try, that should get rid of your black bar.

android or android-native target?

That doesn't sound like a CPU bound test at all. Change the resolution, see what that does to the frame times.

Sorry, no idea why that is. JavaScript performance can sometimes be surprising but did you verify both variations really follow the exact same code paths? And is your scene even CPU bound?

Not sure it still works, I put that in years ago and nobody ever cared. It should output a shader which ends up in the Shaders class and can be used like any other shader.

ok, so it's intel graphics after all. It seems to be something about the init code at https://github.com/Kode/Kore/blob/master/Backends/System/Linux/Sources/Kore/System.cpp#L108 that intel doesn't like but I don't know what it is.

Aha. We had one other guy having a problem like that but I can't reproduce it. But he is running on integrated graphics, are you sure your installation uses your dedicated graphics?

Addendum to make it more clear:
Audio1 is a high level audio API, which has a software implementation in Kha which is used if possible (that's the mixer).
Audio2 is a low level audio API which always talks to a system API as directly as possible. This uses Kore's audio API directly when you use a C++ target in Kha.