This is a lovely surprise as I really enjoy this type of game.
I think current rendering can be optimised, but given that you are scrolling the whole screen partial redraws will not be as effective as you might hope. One of those things that need to be tried to see.
The way I would proceed would be to render the screen to a sprite to see if the SDK sprite system gives any quick gains. It will get better, but by how much is the question.
The best way would probably be to use the SDK tile map and sprites, but that sounds like a rather large rewrite of what you have already. it plays OK at 14fps, but it would play amazing at 30fps+.
Next I would aim to reduce the flickering (pixels that change every frame) by using careful sprite work to make sure shading and dithering align to an odd (or even) pixel grid - rather than random like Atkinson - and scrolling in multiples of 2 to align the scrolling with the dither pattern. This will reduce the amount of pixels changing every frame. Visually, it will look better on device. Whether it results in performance improvement I am not sure as the device sends dirty rows to the screen rather than dirty pixels. But, again, it cannot hurt. Preventing dither flashing/flickering on moving objects by snapping to even pixels
Sampler says this is where it is spending time:
- 33% draw
- 17% RenderGame
- 8% pgeDraw
