Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Newcomers AppGameKit Corner / Not getting a smooth scroll on Android phone

Author
Message
Scifictus
9
Years of Service
User Offline
Joined: 7th Feb 2015
Location:
Posted: 27th Mar 2015 13:28
Hi lovely forum people

I am coding something akin to an infinite scroller. It's super smooth when testing on the PC but very jittery when testing on my Android phone. It is quite simple code, not too many sprites, no physics or 3D elements, and having looked at the time it takes to update all the sprites etc. there is plenty processing headroom per Sync() left (I checked this on the phone of course). The jitters are random and are not happening upon any obvious event in my code.

So having ruled out the obvious things (complex code, too many large sprites etc.) I am left assuming that it is something environmental. I am thinking maybe when I run my application it is not getting the main processing thread on the phone and is quite far down the pecking order at runtime, so all the other stuff going on in the phone is taking priority (but I'm new to this so could be talking out of my proverbial!).

Has anyone had similar problems? Is there a way to force your application to be the 'main thread' on the processor etc.?

Mike
baxslash
Valued Member
Bronze Codemaster
17
Years of Service
User Offline
Joined: 26th Dec 2006
Location: Duffield
Posted: 27th Mar 2015 16:35
There are a lot of possible causes for this. Is there some way you can share the basics of the movement code so it can be tested? Otherwise we'll all be guessing at the cause which is a waste of your time.

Using AppGameKit V2 Tier 1
Scifictus
9
Years of Service
User Offline
Joined: 7th Feb 2015
Location:
Posted: 27th Mar 2015 17:21
Of course. The basic structure of the main loop is as follows:

1. Detect collisions
2. Get gesture input
3. Update player position/animation
4. Draw a new row of the 'map' (a row of 5 sprites) if applicable
5. Scroll all on-screen sprites manually (inc their Y coordinates)
6. Update some player stats and score etc.

I originally built the game using Tweens (and still had the same problem incidentally) but reverted to manual control of sprite scrolling so I could speed up and slow down at will.

In step 4 when I draw the next row of sprites (if the player has progressed appropriately) I go through multiple for/next loops to interogate arrays for each sprite and see if that sprite is off-screen. If it is then I bring it on screen at the position on the 'map' and then it is controlled by step 5.

I would say I have no more than 15 'large sprites on screen (less than 512x512 each in native size) and no more than 40-50 small sprites (less than 150x150 each native size) on screen in any given sync(). No sprites have physics enabled. I have tried making all off-screen sprites invisible to unload the GPU but this has made no discernable difference.

For debugging purposes I look at the total of GetPhysicsTime() + GetUpdateTime() when running on the Android phone (an HTC One so not rubbish) - and the average total value per Sync() is around 0.000550. There are spikes though - the highest spike I have seen in this figure is about 0.010300 - but usually much less than this and it is not occuring regularly at any noteworthy point in the code - these spikes can be milliseconds or seconds apart.

So if I understand correctly (please correct me if I'm wrong!) there is still bags of processing power available per Sync() given the typical figure of 0.000550 above...so something not code-related is causing these spikes which I assume are giving me these slight jitters in the otherwise smooth scrolling. Hence my assumption it was environmental.

Let me know if you need more detail....
Scifictus
9
Years of Service
User Offline
Joined: 7th Feb 2015
Location:
Posted: 27th Mar 2015 17:39 Edited at: 27th Mar 2015 17:42
P.S. - I just tried skipping the entire "draw new row of map" routine (so literally only 10 or so background sprites on screen - none of the main sprites) and I still get the jittery scrolling and spikes....and a total average of 0.000430 per sync...so again this seems to indicate something that is not to do with the code itself?
Scifictus
9
Years of Service
User Offline
Joined: 7th Feb 2015
Location:
Posted: 27th Mar 2015 17:44
...and in case it's useful, I am setting up my screen as follows:
SetVirtualResolution(1080,1920)
SetDisplayAspect(0.5625)
SetOrientationAllowed(1,1,0,0)
EnableClearColor(0)
Funnell7
13
Years of Service
User Offline
Joined: 8th Sep 2011
Location: UK, England
Posted: 27th Mar 2015 17:51
15 large sprites at approximately 512x512 on screen? Sounds like this may be a fill rate issue. If you are rendering more than approximately 1.5 times the screen you will likely get issues as you describe. Try deactivating (as this stops it from being rendered) those large sprites and see if that makes a difference...

Using AppGameKit V2 Tier 1
Scifictus
9
Years of Service
User Offline
Joined: 7th Feb 2015
Location:
Posted: 28th Mar 2015 17:20
Thanks Funnell7 - have tried this - taken out all my backgroun sprites and just left the small foreground/level spritees and still get the same effect, and similar values. There's so little being drawn on screen now I could probably draw each frame by hand in less than a 60th of a second!

Pretty sure (as far as I can be) that I am not overloading the GPU each Sync().
Scifictus
9
Years of Service
User Offline
Joined: 7th Feb 2015
Location:
Posted: 28th Mar 2015 18:36
Also I have tried playing with SetVSync and SetSyncRate but that doesn't seem to resolve this issue either. Any other ideas anyone?
Greenwich
9
Years of Service
User Offline
Joined: 10th Dec 2014
Location:
Posted: 29th Mar 2015 18:37
This might be one of those cases where it's worth sharing your entire code and sprite set so that we can inspect it and try to help. Blindly guessing won't be helpful.

If you're holding back because you're worried that people might steal your code, (1) that's highly unlikely here, (2) stealing code that's currently poorly-functioning would not make a whole lot of sense, and (3) you can just put "licensed CC BY-NC-ND" to formally protect the code from derivation or commercial use.

It's mean time. *averages*
Funnell7
13
Years of Service
User Offline
Joined: 8th Sep 2011
Location: UK, England
Posted: 30th Mar 2015 13:16
The only other thing I can suggest without looking at your code, would be the device itself... Is it a low end device? Can you perhaps export an .apk and attach to this thread, I'll try on my device...

Using AppGameKit V2 Tier 1
Conjured Entertainment
AGK Developer
19
Years of Service
User Offline
Joined: 12th Sep 2005
Location: Nirvana
Posted: 30th Mar 2015 20:44 Edited at: 30th Mar 2015 20:47
Quote: "If you're holding back because you're worried that people might steal your code, (1) that's highly unlikely here, (2) stealing code that's currently poorly-functioning would not make a whole lot of sense, and (3) you can just put "licensed CC BY-NC-ND" to formally protect the code from derivation or commercial use."

Refer to TGC Forum AUP concerning the copyrights of your posts...


5.1 states "...The postings made in the Forums remain the copyright of their respective author."

The link to the AUP is at the bottom right of forum pages in the footer.

You don't need to show your whole program, but showing the troubled parts is the best way to get help with your code.
Just show the chunk of your code that pertains to the problematic functions, or prepare your self for a potential long session of trial and error in fix guessing.


I see you are using percentages for sprite placement... SetDisplayAspect(0.5625)

"The alternative approach is to call SetVirtualResolution to control the coordinate system and place sprites using screen coordinates instead of using percentages." ... AppGameKit Help

I use the SetVirtualResolution for games, and have not had any problems scrolling animated sprites.
It might be a lot of working switching over if you are far along in your development, but if you are just getting started then you may give that a try.
Or, you may have a really simple fix to something you are overlooking in the code you have, but you have to post it to get help with that code.


Coding things my way since 1981 -- Currently using AppGameKit V2 Tier 1
Scifictus
9
Years of Service
User Offline
Joined: 7th Feb 2015
Location:
Posted: 10th Apr 2015 13:15
Hi All - thanks for the various posts and apologies for the late reply...Easter hols etc.

No qualms sharing my code but it's over 1700 lines so far, with much repitition, so I'll take you through all the key parts.

I set my screen up as follows (to use a virtual resolution)



I load images as follows:



and create array-held sprites as follows



After a basic menu screen I layout my sprites in their starting positions (off-screen at 1100,2000) and make them invisible. The main game loop then takes over and reads my map array and places the sprites in the appropriate position across the top of the sceen (hidden by a score panel initially). It goes through the sprite array until it finds a sprite that is off-screen (i.e. not being used) then puts it in position and makes it visible.



In the above code the differential# is just a variable that tells me how much to offset the Y coordinate by, based on the position of the sprites on the previous row, so that they all join up nicely.

Then I manually scroll all sprites on screen as follows:



Then I detect collisions as follows: (in this case it is a pick-up so the score is incremented and the sprite is put back off-screen and made invisible, ready to be re-used).



(Swimmer is the player sprite). And those are the main nuts and bolts - obviously these elements are repeated for each sprite I have (other items, background sprites etc.) and there is a routine to detect player swipe, manage gameover etc but these are the bits of code I am using to perform all the on-screen draws. Finally at the end of the main game loop is a



I am using an HTC One, so not an old or underpowered phone, I have tried remming-out a bunch of sprites (including all background sprites) so literally only have the coins and a few others on screen (40 sprites of less than 100x100) and I still get the same problem.

I'll put together a build and add a link for you to try on your own devices to see if you get the same issues....but in the meantime do you see anything obviously wrong? As mentioned previously, the stuttering applies to the whole screen, does not appear to occur on specific events (e.g. each time a new row of sprites are drawn) and is unaffected by reducing the number of sprites on screen. This is what still makes me think it is environmental on the phone...possibly the application is not getting the main processing thread etc. But I am just guessing.
CJB
Valued Member
20
Years of Service
User Offline
Joined: 10th Feb 2004
Location: Essex, UK
Posted: 10th Apr 2015 15:55
You could try using setviewoffset to achieve the scrolling rather than updating the position of each sprite. Not sure if this will cure the scrolling trouble though.

Also, you could try making zz a float rather than int (i.e., use zz# instead of zz) as you might be getting some rounding effect causing the stutter.

i hope you get it sorted!

V2 T1 (Mostly)
Uzmadesign
Scifictus
9
Years of Service
User Offline
Joined: 7th Feb 2015
Location:
Posted: 10th Apr 2015 17:03
Thanks CJB - I actualy noticed that shortly after my post and updated the zz's to floats...but no change to the scolling issue.

Remember that I am not receiving any scrolling issues on the PC when testing - everything scroll's perfectly - so if it was a 'maths' issue I would expect to see the issue in both environments.

Unfortunately I cant use setviewoffset because I have a parallax effect in place.
CJB
Valued Member
20
Years of Service
User Offline
Joined: 10th Feb 2004
Location: Essex, UK
Posted: 10th Apr 2015 17:59
How are you calculating gamespeed#? If it is based on something like getframetime() (or a manually calculated version of the same), you could try storing the values of the last few frames and work out an average between them to give a smoother result.

V2 T1 (Mostly)
Uzmadesign
Scifictus
9
Years of Service
User Offline
Joined: 7th Feb 2015
Location:
Posted: 10th Apr 2015 18:57
gamespeed# is actually just an integer (starts at 12, increments 2 per level-up) and I use this as the amound to scroll each sprite per game loop (i.e. per Sync() ). The only place I use getframetime() is here:



And I only use tweens for one sprite - the player - which is a non-scrolling sprite. All other screen elements are manually scrolled by increasing their Y coordinate by gamespeed# each game loop.
Scifictus
9
Years of Service
User Offline
Joined: 7th Feb 2015
Location:
Posted: 10th Apr 2015 19:03 Edited at: 10th Apr 2015 19:04
OK so I have put a quick APK build here.

Press anywhere to start. Swipe left and right to change lane, swipe down to dive and up to surface. Press the score panel to pause. For testing purposes you should swipe left until you are running on the side, where currently you won't encounter any enemies and will continue to run indefinitely, allowing you to focus on the scrolling. Obviously this is choc-full of placeholder graphics for now!

I'd be grateful if you would try this on your own Android device and let me know if you see the jittering - it's subtle but irritating nonetheless. There are two debug figures onscreen - top centre (on top of the oxygen bar) is the running per-frame average of GetPhysicsTime() + GetUpdateTime(), and top left shows the highest 'spike' so far of these figures.
isaackoz
9
Years of Service
User Offline
Joined: 6th Feb 2015
Location: Spacecyber
Posted: 16th Apr 2015 03:48
Hi,

I just installed this one my HTC One M8 and I don't notice any jittering yet. When I swipe left and right, it is pretty smooth for me (at least I think so) and up and down are smooth also. My running per-frame average of GetPhysicsTime()+GetUpdateTime() is 0.029953 and my average highest spike so far is about 0.000320.

Hope this helped, if you need me to test anything else just ask me.

~isaac
Funnell7
13
Years of Service
User Offline
Joined: 8th Sep 2011
Location: UK, England
Posted: 16th Apr 2015 11:27
Scifictus, apologies, your mail ended up in my junk folder... I too am not getting any jittering, it plays perfectly smooth for me. I let it run until Speed Level 10 (I doubt anyone will ever get that far lol!)... I have a Samsung S6 which granted, may not be the best of test devices seeing as it is so new...

You have a good game there I like how you can dive down as well, very clever, good work!

Using AppGameKit V2 Tier 1
Scifictus
9
Years of Service
User Offline
Joined: 7th Feb 2015
Location:
Posted: 16th Apr 2015 12:01
Thanks Funnell7 and isaackoz for your help - much appreciated.

So it looks like maybe it is just a quirk of my HTC One then....clearly I need to expand my test suite!

Thanks Funnell7 for your encouraging words on the game! Yes much work to be done on balancing the level speed-ups etc. And yes the ability to dive is what makes it fun for me - gives you a way out of tricky situations, scope for power-ups (increased lung capacity etc.) and just makes it feel a little more deep (no pun intended) than the usual endless scrollers (in my somewhat-biased opinion anyway!)

Thanks for the help...I'll crack on with the game now and just try and make sure I do wider device testing as I go....looks like the code is functioning as well as it can.

Login to post a reply

Server time is: 2024-11-23 11:24:01
Your offset time is: 2024-11-23 11:24:01