• W

    @Robert Yes, basically the API I use take care of keyCodes only, (did not plan to support text input)
    So if you could have such keyCode API that would be great.
    Thanks for the info

    posted in Kode read more
  • W


    Looking deeper into Kha and this is looking great. I have one question about the Keyboard API though:

    One thing I like to have across all my project is stable input API so the game logic (even the one that interact with the input) can stay untouched.

    To have that I usually wrap the library specific input API into my own input API. With Haxe I can use typedef/abstract to limit the runtime overhead of such API conversion.

    With Kha, though the api is too much different to have a zero overhead. The reason is that Kha Keyboard API use two params for the keyboard Keys (a enum + a string (used only for character keys))

    Why is that so ? Is it because of some platform ?

    I can see that the html5 backend use a conversion function on each keypress (that are characters) to output such string.

    Would it not be better to use int as key (keyCodes) ? (through the use of abstract enum : http://haxe.org/manual/types-abstract-enum.html)

    Regarding the split of Char and string in two param for the keyboard event callback, Kha could use a Enum constructor for Char like so :

    enum Key{

    This would avoid the need of two param.

    Do not get me wrong, I actually kind of like this idea of grouping Char and other Key type but would like to know more about the reason behind it, especially considering the overhead for the conversion.


    posted in Kode read more

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