I'm doing a game with game loop and active rendering (using SurfaceView and SurfaceHolder.Callback).
I'm wondering how to make that work together with timed events and touch event management.
The timed events are like each xx ms something happens, each yy ms something different happens.
Touch management is update game and screen when down, up, and move.
I have made a few tries, but it looks somehow awkward and the game isnt performing very well..
On one side I have a classic game loop (in separate thread):
while running update, render, draw, sleep a bit
Now I didn't know well how to make this work with timer loops. I used handler approach - make classes which extend handler, do what they have to do in handleMessage, and call then themselves with sendMessageDelayed.
They just update game state. The rendering of the resulting changes would be done in the gameLoop.
This approach needs synchronization for update of gameloop not intefering with update of the timers.
And - besides of this I need to handle touch events - down, up, and move!
My approach here was, like in the timers, just update game state, and leave it to the loop to handle and display correctly.
I don't know if I'm maybe on the completly wrong path, noob to Androd, and made it just like i thought "could work".
For example I'm not sure if its necessary to make a game loop in a separate thread. I thought it was, to show the results of touch handling (move) according to certain framerate.
On the other side I could leave the loop and just tell to draw after each timer update, and after each touch handling, but this doesnt work well either.
The question is what's the general approach for this kind of game? (timed loops / touch event (move) which has to render to screen continuosly).
Thanks in advance.
Have you read Using Input Pipelines In Your Android Game? It presents a solution to your problem for handling input.
Related
In our javaScript game we are having a problem where "touchmove" events are slow and "janky" until an orientation change at which point they become smooth again.
The slowness returns when the game does a lot of work like loading a level.
Here is a video that show the slow touch move in action, and the orientation change which fixes the issue.
https://youtu.be/7rSqkJuOQjc
The following warning does appear in the log
Handling of 'touchmove' input event was delayed for 141 ms due to main thread being busy. Consider marking event handler as 'passive' to make the page more responive.
However, the slow events persist well after the game has stopped doing heavy lifting like loading a level and building sprites.
I cannot use passive handlers in any case becuase panning the map must preventDefault to stop the interface scrolling as well.
I assume the slowness is related to touch events as I have measured how often the touch handlers are called and they seem strange.
Will receive 5-10 events in a row in under ~20ms, then there will be one that is about 150-200ms, then another batch of fast events, and another slow one.
After the orientation change, all events are received in under 20ms
I have also measured my responses from requestAnimationFrame and they seem to be a fairly solid 16.8ms
For those intrested you can see the problem yourself at https://blight.ironhelmet.com
The problems occur in Chrome and Cordova, both native and using Crosswalk.
The problems do not occur on Safari on iOS or any tested Desktop browser.
I would like to know if anybody else had this problem and how I might go about fixing it.
Is possible to force an "orientation change" or whatever happens during an orientation change, using javaScript?
The hardware renderer was not kicking in, and the slow software rendering was slowing event processing. (drawing pixels from one canvas to another)
After an orientation change, it seems that the garbage collector cleaned up unused canvases which enabled the hardware renderer to kick in.
I have been working on a game where speed is required to score well, in the game the user is clicking on objects and using them with other objects which are held in a gridView that's being controlled by an imageAdapter. I have noticed that when I click quite fast some clicks don't register, I have cleaned up the code running when the user clicks but that doesn't seem to be the problem since I tested it just highlighting objects and not running code when clicked and it was just as slow. So is there a way to speed up the click detection, or would this be limited by the speed of the device its self, I have been testing on an htc one m8.
Return as soon as possible from the handler and run the UI update code in background with 'runOnUiThread()'.
Notice that changing view status MUST be done in the UI thread or the Android runtime will throw an exception. You can work complex calculations in background 'AsyncTask' and call 'runOnUiThread()' from within them whenever you want to update UI components.
As far as I know, there is no way to do such think. It depends on the speed of your hardware. But what you can do is to use the onTouch listener. In this way you listen only after one action(when it is pressed). for onClick it is registered 2 actions(when u press the button and when u release the button). In this way maybe you could do it faster.
You can also try this:
http://developer.android.com/guide/topics/graphics/hardware-accel.html
I am porting my game, from iOS to Android. Mostly, it's working just fine. I'm mostly using C/C++ code, with the NDK / JNI, and a little Java to manage the app life-cycle and send touches and accelerometer info to my game.
As far as I can tell, there are 2 threads, the main UI thread, and a thread created by GLSurfaceView to handle display and flipping OpenGL back-buffers etc.
So, all is working well, apart from the touches. They feel sluggish and unresponsive, compared to other apps I have tried on my devices. After doing some research, I believe the issue may relate to how I am using threads. Specifically, I think, it could be related to not sleeping the display thread after it does it's work, and so, it's holding things up on the main UI thread. Does that sound plausible?
I tried computing how many ms I need the GLSurfaceView display thread to sleep, and then sleep(), and it improves the touches, but the animation is no longer a constant 60FPS on my devices. My suspicion is that I am computing the number of ms to sleep for the previous frame, and using that number to sleep for the current frame.
Or, it could be something altogether different? I don't know. I'm still very new to Android...
Hope someone can shed some light on the matter, or point me in the right direction.
Thanks,
You don't have to sleep the GL thread. In fact, I'd say sleeping the GL thread would make it even more sluggish since it's the thing rendering the images on the screen.
Sluggish UI is caused primarily by the main UI thread being held up. If you're doing a lot of processing on the main thread (accelerometer data for example), the main thread will have to do the work first and THEN handle your user input. This can give the "feeling" of sluggishness. All touch events and non-opengl drawing events must happen in the UI thread. Anything else can occur in a background thread which wouldn't block the UI thread for an extended period of time.
Aside from that, the other possibility is you're simply overloading the processor. Your GL thread might be taking a long time to draw. It's probably receiving and handling touch events and accelerometer data. However, if the render takes a really long time, then you'd be seeing out-dated data. Thus, it again feels "sluggish". You mentioned that it's not a constant 60 FPS so this is a very real possibility. You may have optimize your drawing code so the render is faster.
I am trying to make a game on mobile with adobe air. Everything went smoothly 'till I encounter problems with mouse click event. I experience very slow response on button/movie clip when adding mouse click event listener to mimic tap/touch event on mobile. The delay time after player's finger tap the button/movie clip till the execution is 1-2 seconds (really annoying really).
So I wonder I should change to touch_tap event instead of mouse click event and hope things change for good. Unfortunately it doesn't really show any difference.
I played a lot of games on android (and I think they are made by flash) and I can not understand why their tap event and response time is unbelievably fast (almost instant after the my touch/tap on the button/movieclip). Anyone could help me shed light on this?
I don't think handling TouchEvent make THAT much difference since Flex framework currently deals with MouseEvents and there's basically no such delay.
What it reminds me though is a rare bug I met in some previous versions of FlashPlayer and (desktop) AIR where mouse and keyboard events were delayed up to several minutes(!) on some specific hardware at some specific views (I mean some set of objects on the screen). The important moment here is to say that current framerate was high and constant(!), so it's not a general performance issue. Event though Adobe says it was fixed, I'm not really sure as they didn't show any certainty about it.
So try to check if framerate is OK, if it is — nasty runtime bug... and you should try to play around with display list, blend modes, cache-as-bitmaps (if presents).
Make sure you disable doubleClick. Sometimes this is the reason for a delayed response... guess doubleClick-time for touchinputs is even longer than on desktop...
I've been reading stuff about android game development and performance optimization.
And i have two questions:
Supose i have a game, and in that game i use one thread for drawing stuff on a canvas. when I fire a bullet i want an explosion to happen at contact with another surface. will the game wait for the explosion to render and then continue to render the rest of the animations etc?
or will it all happen at the same time?
The second question is about the garbage collector, and if anyone could give me some hints or post a link to something about it regardin games performance.
Thank you very much.
will the game wait for the explosion to render and then continue to render the rest of the animations etc?
Not unless you do something to specifically make the game wait for the events to execute in a certain order. If you have synchronized access to the canvas, then all that will be guaranteed is that the two threads will not draw on the canvas at the same time, but the order in which they draw, and when they draw, is not guaranteed.
or will it all happen at the same time?
The order in which the drawing will occur may be concurrent, so you could say it's happening in the same time. However, it's recommended that only one thread draws on the canvas.
If I were you I would try to get a decent 2D/3D game engine for android and worry about your game more than the multithreading and garbage collection behind it.