Touch Controls Not Working

[Rusty-9]

Hi @taisel

Would you be able to provide the source code for the i53emu site? I'm having hassle getting the touch controls to work on the default Iodine one (samsung galaxy S7 in chrome browser). I can load a rom but the controls are totally unresponsive. I tried to trace through to see where they were 'failing' but the press and release events seemed to be registering as far as 'GameBoyAdvanceJoyPad.prototype.checkForMatch' and I got stuck looking further (my working knowledge of JS is kinda scratchy!).

I noticed a reference to the controls being better on the i53emu version but I want to host locally (planning on switching out the google drive integration for server storage - it's only for my own use :) ) - would you be able to get me the SC? Or maybe a pointer as to where the issue with controls might be?

Hope that is OK, and makes sense...

[Onimishra]

@Rusty-9

I havn't been able to work on this project for some time now, but I'll try to help you the best I can.
Why would you target Android in the first place? I tried to get this up to running speeds on iOS, as Android already has native support for GBA emulator while iOS does not. It is not possible to play GBA games on iOS, unless we do it through the browser. The native versions for Android uses a lot less power, includes more features and has better support overall.

For mobile (i53emu) I had to redo the entire control scheme that was already present in the stock version of Iodine. It's luckily not that hard, as taisel did a really good job at separating specific integrations into modules.
If you open the source on i53emu (cmd+alt+i on a mac), go to Sources and find folder user_script/mvi. In there is most of my additions. i53emu is put together in a hurry just to see what could be done on iOS, so don't expect the same level of prettiness as the rest of Iodine ;)
In the Setup.js file, there is a function called bindBetterVirtualControls at ~L260. This sets up my own UI to handle the touch events.

The reason this is not working in Android Chrome, is most likely due to me using "touchstart" and something about nesting. This is usually the problematic areas. Again, I might be wrong - I haven't debugged it.

Let me know what you find :)

[Onimishra]

@Rusty-9

I havn't been able to work on this project for some time now, but I'll try to help you the best I can.
Why would you target Android in the first place? I tried to get this up to running speeds on iOS, as Android already has native support for GBA emulator while iOS does not. It is not possible to play GBA games on iOS, unless we do it through the browser. The native versions for Android uses a lot less power, includes more features and has better support overall.

For mobile (i53emu) I had to redo the entire control scheme that was already present in the stock version of Iodine. It's luckily not that hard, as taisel did a really good job at separating specific integrations into modules.
If you open the source on i53emu (cmd+alt+i on a mac), go to Sources and find folder user_script/mvi. In there is most of my additions. i53emu is put together in a hurry just to see what could be done on iOS, so don't expect the same level of prettiness as the rest of Iodine ;)
In the Setup.js file, there is a function called bindBetterVirtualControls at ~L260. This sets up my own UI to handle the touch events.

The reason this is not working in Android Chrome, is most likely due to me using "touchstart" and something about nesting. This is usually the problematic areas. Again, I might be wrong - I haven't debugged it.

Let me know what you find :)

[Rusty-9]

Hello Onimishra Kind of curiosity that got me on Android :). It is the touch events, although not 100% sure where... I've kind of just dropped this now (I got some alternative controls working, although I can't remember if it was your one or not) by 'translating' the touch events into key-down/up events. Just needed to change some of the handlers in the js code. Thanks for taking the time to reply though

…

On Tue, Mar 20, 2018 at 3:17 PM, Onimishra ***@***.***> wrote: @Rusty-9 <https://github.com/rusty-9> I havn't been able to work on this project for some time now, but I'll try to help you the best I can. Why would you target Android in the first place? I tried to get this up to running speeds on iOS, as Android already has native support for GBA emulator while iOS does not. It is not possible to play GBA games on iOS, unless we do it through the browser. The native versions for Android uses a lot less power, includes more features and has better support overall. For mobile (i53emu) I had to redo the entire control scheme that was already present in the stock version of Iodine. It's luckily not that hard, as taisel did a really good job at separating specific integrations into modules. If you open the source on i53emu (cmd+alt+i on a mac), go to Sources and find folder user_script/mvi. In there is most of my additions. i53emu is put together in a hurry just to see what could be done on iOS, so don't expect the same level of prettiness as the rest of Iodine ;) In the Setup.js file, there is a function called bindBetterVirtualControls at ~L260. This sets up my own UI to handle the touch events. The reason this is not working in Android Chrome, is most likely due to me using "touchstart" and something about nesting. This is usually the problematic areas. Again, I might be wrong - I haven't debugged it. Let me know what you find :) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#62 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AjfR-IryU5IbCSwfGu8ObqSS_OKrLmchks5tgR2GgaJpZM4SkJGT> .

[Rusty-9]

Hello Onimishra Kind of curiosity that got me on Android :). It is the touch events, although not 100% sure where... I've kind of just dropped this now (I got some alternative controls working, although I can't remember if it was your one or not) by 'translating' the touch events into key-down/up events. Just needed to change some of the handlers in the js code. Thanks for taking the time to reply though

…

On Tue, Mar 20, 2018 at 3:17 PM, Onimishra ***@***.***> wrote: @Rusty-9 <https://github.com/rusty-9> I havn't been able to work on this project for some time now, but I'll try to help you the best I can. Why would you target Android in the first place? I tried to get this up to running speeds on iOS, as Android already has native support for GBA emulator while iOS does not. It is not possible to play GBA games on iOS, unless we do it through the browser. The native versions for Android uses a lot less power, includes more features and has better support overall. For mobile (i53emu) I had to redo the entire control scheme that was already present in the stock version of Iodine. It's luckily not that hard, as taisel did a really good job at separating specific integrations into modules. If you open the source on i53emu (cmd+alt+i on a mac), go to Sources and find folder user_script/mvi. In there is most of my additions. i53emu is put together in a hurry just to see what could be done on iOS, so don't expect the same level of prettiness as the rest of Iodine ;) In the Setup.js file, there is a function called bindBetterVirtualControls at ~L260. This sets up my own UI to handle the touch events. The reason this is not working in Android Chrome, is most likely due to me using "touchstart" and something about nesting. This is usually the problematic areas. Again, I might be wrong - I haven't debugged it. Let me know what you find :) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#62 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AjfR-IryU5IbCSwfGu8ObqSS_OKrLmchks5tgR2GgaJpZM4SkJGT> .

[taisel]

mobile was left in an incomplete state.

• The control bar needs to be redone for it.
• The audio backend needs to be replaced with an upcoming version that is able to jack into touch events a developer specifies so iOS restrictions can be removed and so it can be unmuted.

Tangential to this, I wonder if you noticed that meltdown/spectre kinda is forcing every browser to use the single threaded version again (The off-thread settings, it'll be greyed out on platforms that disabled sharedarraybuffer or don't support it). This affects mobile the most. It can be re-enabled in firefox settings. Even phones nowadays are dual/quad/hexa core, so we can offload the graphics thread for like a 40% gain.

[taisel]

mobile was left in an incomplete state.

• The control bar needs to be redone for it.
• The audio backend needs to be replaced with an upcoming version that is able to jack into touch events a developer specifies so iOS restrictions can be removed and so it can be unmuted.

Tangential to this, I wonder if you noticed that meltdown/spectre kinda is forcing every browser to use the single threaded version again (The off-thread settings, it'll be greyed out on platforms that disabled sharedarraybuffer or don't support it). This affects mobile the most. It can be re-enabled in firefox settings. Even phones nowadays are dual/quad/hexa core, so we can offload the graphics thread for like a 40% gain.

[Onimishra]

And do you think this will become available again in the future, or will a hardware update be needed in order to mitigate the flaws? (meaning sharedarraybuffer will not be reintroduced anytime soon).

Yes, the audio backend needs an update in order to get it to work on iOS. This was one of the reasons I didn't complete i53emu - I knew that writing a new audio backend out of scope for the time I had to put into it.

[Onimishra]

And do you think this will become available again in the future, or will a hardware update be needed in order to mitigate the flaws? (meaning sharedarraybuffer will not be reintroduced anytime soon).

Yes, the audio backend needs an update in order to get it to work on iOS. This was one of the reasons I didn't complete i53emu - I knew that writing a new audio backend out of scope for the time I had to put into it.