next »

[eri0o]

Hello everyone.

I did a write up taking a quick look at Touch Handling APIs in Game Engines. I am trying to figure out a good API to handle touch input in a game engine.

So far, I feel the way to go is giving finger ID and touch position per touch, a way to poll these touches, and all events to pass them for people who want to handle them through events. What else is important when designing a touch API?

[encelo]

Hi eri0o, I can tell you what I did for my engine called nCine.

Initially touch input was only supported by the Android backend, that's why the touch event and API resemble so much the Android ones.
When I added the touch support to the SDL2 and Qt5 backends I had to, in a way, simulate the Android API.

If you want to know more about how I handle the input you can ask me questions and also watch this

.

[eri0o]

Hey Encelo! Thanks for answering! For now my only backend is SDL2, but I don't want to be exactly like it because in the future I may need to switch backends or have another backend side by side with it.

I noticed you using the mouse, so this is one worry, with an approach like the one used in GameMaker or the Pointer API in the Browsers, the code between mouse and touch becomes interchangeable, which makes things a lot easier to test and develop and overall maintainability, since I can easily reproduce a reported bug using the mouse instead of having to load the thing in an Android Phone or Emulator to verify things.

I like the overriding of virtual functions you use, this makes easy for the IDE to verify you are really overriding an existing method, which avoids getting events that don't get called because the person typing it misspelled/had a typo, which has happened to me in JS when adding event listeners and spelling the event string name wrong by accident.

You offer events and polling, when I do make games I find it easier to poll than handle events, offering both is to favor different styles or is there any particular reason for offering both?

[encelo]

Yes, you are correct, I treat the mouse as a separate kind of event.
As you said I could have treated the touch as mouse events but then I would have lost some flexibility.

I prefer to offer to the user the possibility to perform this kind of "mouse simulation" if it is needed but without embedding it in the engine as the only way available. I don't want to remove the ability to use a mouse on Android (which I deem useful for GUI based tools, like SpookyGhost) or to use a touch screen on a desktop machine as a first-class input system.

I offer both events and polling as they are two faces of the same coin and they allow for different programming styles, as you said. Besides, some backend might offer just one approach or the other and having both makes the API always consistent.

[eri0o]

Thanks for the answers Encelo! Designing and coding engines is super hard, so all I have to say now is great work with nCine! Also, very cool you make videos to talk about it, it makes it easier to pickup and understand! 

[encelo]

Thank you eri0o, I wish I had more time and patience to prepare more videos.

[rupy]

I think it's very hard. My solution if Android drops Java so I can build a release without needing to download a couple of GB of crap is to make bluetooth dual analog stick controller mandatory.

That does require you to get a stand for your pad (phone is too small) but that is the only way you can play a analog input game on a pad IMO.

I was surprised when I tried to play many Android games that almost none support an external bluetooth gamepad... not even 3D games like roblox!?!

[encelo]

I have tested my framework on Android with all my gamepads, both Bluetooth and USB, and they all work just fine.
From the Xbox 360 and PS4 ones, to the Nyko Playpad Pro and the 8Bitdo SN30 Pro.
I just had to use a bit of JNI to expose part of the Java API to the native side.