Android performance for sprite move

grotly

Hi all

I noticed an issue when moving a sprite on the screen on Android devices. The movement is not smooth, a bit choppy, barely noticeable, but it's there. Take for instance the Jumping Ball example that comes with the Gideros installation package. On iOS, it moves very smoothly, but on Android devices (I tried on two very fast Android devices) the movement is not smooth, the ball seems to stop for a millisecond from time to time and then move again. I tried with Gideros 2014.01, 2014.10 and 2015.02. Is anyone else experiencing this problem? Or is it a problem with my eyes that are too sensitive to movement?

SinisterSoft

It depends on the Android device and the manufacturers version of Android.

Also it depends on the garbage collection settings in your lua game - before a level starts make sure you do a garbage collection after setting it up.

grotly

Of course it depends, I'm sure. However, I tried on (now 3) different Android devices (OnePlus One, Nokia XXL and Samsung Galaxy S5). I am not talking about a complex game, but rather a very simple example, the Jumping Ball project from the Gideros examples folder. It behaves in a same "less smooth" manner on all devices. On my iPad and iPhone the same code runs very smoothly. Any idea why?

--[[   A nice example of a ball moving on the screen   This code is MIT licensed, see <a href="http://www.opensource.org/licenses/mit-license.php" rel="nofollow">http://www.opensource.org/licenses/mit-license.php</a> (C) 2010 - 2011 Gideros Mobile   ]]   -- load the background and add as a child of stage local background = Bitmap.new(Texture.new("field.png")) stage:addChild(background)   -- create a ball bitmap object (Bitmap class inherits from Sprite class) local ball = Bitmap.new(Texture.new("ball.png"))   -- in Gideros, every created object is an ordinary Lua table -- therefore, we can store our custom fields in this table ball.xdirection = 1 ball.ydirection = 1 ball.xspeed = 2.5 ball.yspeed = 4.3   -- add the ball sprite to the stage stage:addChild(ball)   -- before entering each frame, we update the position of the ball function onEnterFrame(event) local x,y = ball:getPosition()   x = x + (ball.xspeed * ball.xdirection) y = y + (ball.yspeed * ball.ydirection)   if x < 0 then ball.xdirection = 1 end   if x > 320 - ball:getWidth() then ball.xdirection = -1 end   if y < 0 then ball.ydirection = 1 end   if y > 480 - ball:getHeight() then ball.ydirection = -1 end   ball:setPosition(x, y) end   stage:addEventListener(Event.ENTER_FRAME, onEnterFrame)

keszegh

did you set the fps of the game to 60 instead of 30?

grotly

Yes, it was 60 by default in project properties, I haven't changed it. Now I tried to see how it is with 30 and is horrible indeed. But still, even with 60, I can see an extremely little "roughness" in ball's movement.

keszegh

no luck with this trick then. you can measure fps btw (there are simple code snippets on the forum i believe) to check if it is 60 as it should be. devices may lock the fps for less.

http://giderosmobile.com/forum/discussion/486/how-do-i-display-fps/p1

grotly

I used the fps code and it shows 60 or 59 so it should be ok. This is very strange and I have no idea where else to look. Next thing would be the gideros android player to check more.

SinisterSoft

@grotly have you tried loading other games from the play store written in Gideros to see if they also do the same thing?

cokeramirez

That example runs perfectly fluid in my S3. Even the one with 5 balls runs very very smooth using the Gideros player with and without scale mode. Can be an issue with newer devices?

SinisterSoft

I have an S3, various tablets and a HTC M8 (android 5) - all run ok here.

grotly

@SinisterSoft no I didn't try, but I'll give it a try today. It's weird that the Gideros example does not run ok, I am thinking of a possible problem with the Gideros Android player on my system. I will try to re-install Gideros, maybe it helps. Like I said, the problem is very hard to notice, but I think my eyes got very trained in the last few months

pie

@grotly, I don't know if that's the case: I had a very strange slow down once, only on latest and powerful android devices. The FPS printout was consistent with older (and slower) devices, but the game was lagging a lot more. After struggling for a week I noticed that my Eclipse was missing some updates from the latest android sdk which - I'm guessing - maybe was used on those new devices.
Updating Eclipse and recompiling the project solved my issue.

grotly

@pie thanks, I'll give it a try.

grotly

Ok, I think I found a way to show what the problem seems to be in Androids. I slightly modified the Jumping Balls2 sample project, just to amplify the issue, and it seems to show now what I meant. Just unzip the project and run it in Gideros Player, first on an Apple device (I tried on an iPad Mini 1st gen. but you can try on something else, just not a very old device). You will see that everything runs very smoothly. Now, run the same project in Gideros Player on the most powerful Android device you have around. See what the problem is? Of course, the effect is amplified on purpose, but this is visible for me with just a few sprites on the screen. In my game I have just about 20-30 sprites moving with that speed at the same time on the screen and it is very,very visible. The example project I have attached here has 500 sprites, but like I said, only to show the problem on Androids. On apples, even with a bit more sprites, it still runs very smoothly.

pie

@grotly I can see it now on high end android tablet: never noticed that before. Unfortunately I can't see it on iThings...

Maybe could be worth adding it to the open issues on github?

grotly

Done

https://github.com/gideros/gideros/issues/22

muro

I have got the same issue. It seems a tiny problem but it is definitely a motivation killer.
I had left to develop my game for this reason since a year. Then I had tried to determine this problem but my skills are limited.

I have tried to find the problem a few days ago, It is hard to catch with less sprite or independent sprites
* It occurs on the same y coordinate(s)
* The problematic y position changes for each start with different number sprites(mine ~200). I mean the sprite number differentiates the y coordinate position.
* All balls frequently jump/tear through the same lines(sometimes more than one)
* It occurs on both desktop player and my android device
* Sometimes the problem does not appear but grotly's example shows this problem clearly.
Many thanks to grotly

I managed to take two screenshots

I hope this issue will be resolved soon. Sorry for my google-translation English

SinisterSoft

I get it on the desktop players too - it's like the 60hz interrupt isn't synced with the screen properly.

antix

Very interesting. For some time now I have been wondering why my own graphics stutter when my FPS counter shows 59-60FPS at any given time. I figured it wasn't too important and I could resolve the issue later in development but this does seem to be quite an issue now.

Hopefully there's a fix soon

tkhnoman

I got this on desktop's full screen mode.
Then i tried to increase my VGA performance, and it's gone.

SinisterSoft

I think that the sync for the screen in the gideros code (QT) must not be the sync for the actual phone/computer - it should be. If not then they will get out of sync but still show running at 60hz, being out of sync would result in this judder. It's really aproblem on win32 QT desktop export. It goes away if you restart the game. It's always happened with Gideros though, but it would be great if there was a fix.

muro

Ping, any news? I'm not sure, I think this is system-wide vsync(vertical blank) problem and occurs on low-end devices, just a guess. May be mesa driver, GL bug(The different two SDK give the same problem) . It looks like there is a solution Gideros Player -> Frame Rate -> Unlimited Fps mode, but causes so expensive resource consumption, not a option

MoKaLux

ping, I have tested the project on a low end phone samsung J6 and it runs smoothly I guess? I ask for the issue to be closed on github unless somebody feels it still should be opened.