Sorry your browser is not supported!

I can think of a number of ways to create a scrolling list - think gmail on your mobile, or a list of menu options that is too long for the screen. You swipe, and it scrolls downwards. I wondered what peoples opinions are?

1. Scrolling

You could either

a. scroll the screen and set the screen offset, or
b. scroll the options up and down

Option a requires that any other code takes account of the screen offset. For example the screen background needs to scroll too.
Option b means that more sprites need to be scrolled each time

I'm erring towards setting the screen offset, and scrolling the background slower, to give a parallax effect.

2. Managing number of options

In the email example, you could have hundreds of options. I am planning on having "one screenfull + 3" option sprites. When the option is offscreen + (0.5 * height), it will be recycled at the bottom of the screen, and the same for downward scrolling.

The sprites will be allocated to visible options and held in the options array. For example, an array of 100 options will have options 10 to 22 with sprites allocated. As you scroll, 11 to 23, 12 to 24, 13 to 25 will be allocated sprites etc.

3. Scrolling motion

The motion tends to be controlled by speed of the swipe. I suppose I should take the distance and timing of a swipe, and translate this to the scrolling speed, which is suppressed over time to slow it down. I could perhaps even implement box 2D and friction to handle this.

I use option 'b' for part 1, mainly because I have lots of other sprites on screen at the same time and secondly because everything is fixed to the screen.
I'm planning to also add a slower background scrolling sprite, so I think both are valid.

I don't give my list inertia since my lists are never long, but I think a simple decay would be better than using box2d to avoid collisions.

I would go for a view offset if there are a lot of items as you can still fix static menu items to the screen. It saves repositioning every sprite every loop as well.

I have done this a few ways now and that works best for me. I have an offset and an inertia. While the user is swiping inertia is left out of the equation but once they have finished I do a speed check like so:
inertiaY# = (pointerY# - prevY#) / getFrameTime()

Then reduce it every loop like:
inertiaY# = inertiaY# - inertiaY#*getFrameTime()

...or something like that.

Is someone has a good code snippet for a smooth touch scroll with inertia using screen offset ?

I achieved to have one working but it's not perfect at all at high framerate and i would like to have one which works both perfectly at 20 fps and 2000 fps

i tried a lot of things but i'm sure there is a simple way to do that.

I started to create one, but then I realised that HTML was better for the mini app I was creating. Screen Offset was definitely the way to do it though.

I needed a background sprite and text for each option.

I had an array of options, and enough option sprites for one screen + 2 options. The idea was that as one option disappears off the top (or bottom) then you move the sprite and text to the opposite end. Assign the sprite to the relevant option and update the text with this option too. Then you only ever have just the right amount of sprites and text.