Need no screen update, only input update
Monkey Targets Forums/Android/Need no screen update, only input update
| ||
| Is there a good way to render a scene and have the next 1000ms no rendering? Afaik I can't just return without rendering from OnRender because a few Android devices might then show garbage. My game actually draws nothing new for about a second, but input processing should really become a bit faster (I know, touch input lags anyway). Maybe I should try to hack into my android mojo an OnShouldIRender() where my game can return false if nothing new is to draw? Then "BeginScene" would not be called at all. Is this the only way? Am I missing something completely? *unsure* |
| ||
| SetUpdateRate(1)? I guess that would also only update OnUpdate() slowly, too. |
| ||
| I also made bad experiences with returning from OnRender() on android devicec. But it never was any garbage, but flickering. I could remove this by render the last screens for 3 or 5 continuing OnRender()s. After this the flickering was removed and I could return immediately. A second way would be to GrabImage the screen after the scene is rendered. If the creation of the scene really needs a lot of performance (>50msec) . From the following OnRender() you show the Image instead of the scene. My third way is to reduce SetUpdateRate() to 10. But never tried it during a game. Only at the OnCreate(). It is optimal for app, which render screens without movement on the screen. What "Inputs" do you try to speed up? |
| ||
| Replace "a few Android devices might then show garbage." with "alarmingly, a bucketload of Android devices will show garbage." Stupid Android. Quite how it manages to successfully break "Don't do anything!" is beyond me. Yeah, the best option is to try to grab the screen and keep redrawing that OnRender().. It might take a while to initially grab the image, but given you're about to essentially freeze the device anyway, it probably won't be too much of an issue. ..or come up with a simple no-nonsense screen to take it's place until you're done. A simple Loading Bar will probably do the trick. |
| ||
| What "Inputs" do you try to speed up? TouchHit(0) My feeling was that touching other buttons in android was faster than touching the ones in my game. And since my current game is very special, not hungry for a lot of frames, the idea popped into my mind to try to give the touch stuff more cpu time. @ Midimaster @ EelectricBoogaloo @ grabbing the screen: yes, but ... I'll need more memory for it. If rendering the scene did not start at all, the image on the screen would persist, wouldn't it? Though I've looked at mojo.android.java I've got yet no idea how OpenGLES works on android, whether I can choose to render when I want. My asumption is that mojo just decides every UpdateRate per second to begin a new scene. If it was like this, I could change it to start a new scene only when my game currently wants to render. |
| ||
| I used to know where to find where this stuff is controlled but looking at recent versions of mojo everything seems to have changed... If you just wanted to do computations, you could simply set a slow update rate, and call your computation code repeatedly from OnRender. With regard to I/O, it's probably system dependent how fast you can get at it and/or respond. Failing that, I guess you'll have to go adventuring into the native code, or else hope its fast enough as it is. Maybe you could optimise your renders so they are very fast and don't slow you down. |
| ||
| Found it.. in the timer code there's _androidGame._view.requestRender(); and now I've removed this and addded BBAndroidGame._androidGame._view.requestRender(); lines everywhere where I think it should update. PS: ..which makes no sense. But doing need_new_render = true; at these places does make sense, and requesting (or not) the new render at the end of OnUpdate. So... actually, monkey-design-wise OnUpdate could be a method returning a boolean, and if you decide to return OnUpdate with true, that would mean no rendering is requested until the next OnUpdate returns. But it would probably only help really slow card games not to drain resources. |
| ||
| That's a neat idea! OnUpdate does currently return an int which is evidently reserved for expansion. I don't know what if anything Mark has in mind for it, but maybe he wouldn't mind sparing one bit for a "don't render" flag! Obviously there are other ways to set a no-render flag. And there might be limits on how long you are allowed to avoid rendering on an Android, but this wouldn't really be too much of an issue. |
   |