Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rapid inputs consistently crash Android build #626

Open
Jacic opened this issue Sep 24, 2019 · 3 comments
Open

Rapid inputs consistently crash Android build #626

Jacic opened this issue Sep 24, 2019 · 3 comments

Comments

@Jacic
Copy link
Contributor

Jacic commented Sep 24, 2019

  • HaxePunk version: git
  • Target(s): Android
  • Haxe version: 3.4.7
  • OpenFL/Lime or NME version: OpenFL 8.9.1/Lime 7.5.0

It's hard to test various versions with so much under the hood changing between OpenFL, Lime, and HaxePunk, so I am currently only able to confirm that this issue occurs with the versions I have listed.

While developing my Android game, I found that repeatedly tapping the screen will crash the app. It's easy to reproduce; I found that drumming two fingers on the screen rapidly for a few seconds will cause the crash, but sometimes it takes a little longer. Here is the stack trace:

09-24 12:21:09.745 27977 28532 E HXCPP   : Called from hxcpp::__hxcpp_main
09-24 12:21:09.745 27977 28532 E HXCPP   : Called from ApplicationMain::main ApplicationMain.hx line 25
09-24 12:21:09.745 27977 28532 E HXCPP   : Called from ApplicationMain::create ApplicationMain.hx line 130
09-24 12:21:09.745 27977 28532 E HXCPP   : Called from lime.app.Application::exec lime/app/Application.hx line 150
09-24 12:21:09.745 27977 28532 E HXCPP   : Called from lime._internal.backend.native.NativeApplication::exec lime/_internal/backend/native/NativeApplication.hx line 146
09-24 12:21:09.745 27977 28532 E HXCPP   : Called from lime._internal.backend.native.NativeApplication::handleRenderEvent lime/_internal/backend/native/NativeApplication.hx line 370
09-24 12:21:09.745 27977 28532 E HXCPP   : Called from lime.app._Event_lime_graphics_RenderContext_Void::dispatch lime/_internal/macros/EventMacro.hx line 91
09-24 12:21:09.745 27977 28532 E HXCPP   : Called from openfl.display.Stage::__onLimeRender openfl/display/Stage.hx line 1878
09-24 12:21:09.745 27977 28532 E HXCPP   : Called from openfl.display.Stage::__broadcastEvent openfl/display/Stage.hx line 1171
09-24 12:21:09.745 27977 28532 E HXCPP   : Called from openfl.display.DisplayObject::__dispatch openfl/display/DisplayObject.hx line 1430
09-24 12:21:09.745 27977 28532 E HXCPP   : Called from openfl.events.EventDispatcher::__dispatchEvent openfl/events/EventDispatcher.hx line 402
09-24 12:21:09.745 27977 28532 E HXCPP   : Called from haxepunk.App::onEnterFrame haxepunk/App.hx line 9
09-24 12:21:09.745 27977 28532 E HXCPP   : Called from haxepunk._internal.FlashApp::onEnterFrame haxepunk/_internal/FlashApp.hx line 61
09-24 12:21:09.745 27977 28532 E HXCPP   : Called from haxepunk.Engine::onUpdate haxepunk/Engine.hx line 225
09-24 12:21:09.745 27977 28532 E HXCPP   : Called from haxepunk.Engine::step haxepunk/Engine.hx line 241
09-24 12:21:09.745 27977 28532 E HXCPP   : Called from haxepunk.input.Input::update haxepunk/input/Input.hx line 129
09-24 12:21:09.745 27977 28532 E HXCPP   : Called from haxepunk.input.Touch::update haxepunk/input/Touch.hx line 18
09-24 12:21:09.745 27977 28532 E Exception: Null Object Reference

From the testing I was able to do, it seems that the same touch (judging by the touchID) is being handled twice during my rapid tapping. I think the first time it's handled it gets removed when my finger leaves the screen, but then it is handled again and it's null.

@XANOZOID
Copy link
Member

XANOZOID commented Sep 26, 2019

What operating system are you developing from? I'm pretty busy and wouldn't have a lot of time to develop a solution but hopefully I can take a look at this soon

@Jacic
Copy link
Contributor Author

Jacic commented Sep 27, 2019

I'm developing on Fedora Linux.

I did some more testing, and by modifying the while loop to remove the touch input if it's null I can reliably avoid crashes:

while (i < _touchOrder.length)
{
	var touchId = _touchOrder[i],
		touch = _touches[touchId];
	if(touch == null)
	{
		_touchOrder.remove(touchId);
	}
	else if (touch.released && !touch.pressed)
	{
		_touches.remove(touchId);
		_touchOrder.remove(touchId);
	}
	else ++i;
}

This doesn't exactly fix the underlying problem, but it will avoid crashing. I'm not doing anything with multitouch inputs in my game, so this serves my purposes well enough. I can make a pull request out of this if you wish, but I'm not sure that this won't cause problems in something requiring multitouch inputs or gestures.

@XANOZOID
Copy link
Member

I can't say it will get merged, I'm not entirely in charge of those kinds of decisions right now. We don't really except "Patch" fixes though. We're also really not trying to add more features to the legacy branch right now if that ends up being the fix (IE some sort of "last input detected" feature).

I do want to take a look into it as soon as possible, I don't know when I'll have a chance to get a setup going for Android presently but hopefully soon. Have you tried testing this on multiple Android OS's and devices or just one?

Also, if you do submit a pull-request I can potentially see where your fix starts and see if I can investigate from that point on if you prefer not to.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants