• Robert

    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).

    posted in Kode read more
  • Robert

    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.

    posted in Kode read more
  • Robert

    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.

    posted in Kode read more
  • Robert

    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.

    posted in Kode read more
  • Robert

    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.

    posted in Kode read more
  • Robert

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

    posted in Kode read more
  • Robert

    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.

    posted in Kode read more
  • Robert

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

    posted in Kode read more
  • Robert

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

    posted in Kode read more
  • Robert

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

    posted in Kode read more
  • Robert

    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.

    posted in Kode read more
  • Robert

    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.

    posted in Kode read more
  • Robert

    android or android-native target?

    posted in Kode read more
  • Robert

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

    posted in Kode read more
  • Robert

    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?

    posted in Kode read more
  • Robert

    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.

    posted in Kode read more
  • Robert

    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.

    posted in Kode read more
  • Robert

    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?

    posted in Kode read more
  • Robert

    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.

    posted in Kode read more

Looks like your connection to Kode Forum was lost, please wait while we try to reconnect.