Sorry your browser is not supported!

So I decided, since my game is heavily dependent on a large 2d sprite based display, to run a series of tests to see if there was any way that was noticeably quicker at rendering sprites than others, and the results were actually fairly surprising.

I ran all tests on two devices, my PC which is an 8 core 3Ghz AMD with a GTX670 2GB, and my Samsung Note 2 which is a quad core 1.5Ghz (I think!) with 2GB ram and some form of dedicated graphics. The etst were all done by loading a 160*100 graphic and then creating and manipulating sprites in various ways, and the graphics was a PNG but with no transparent areas (transparency and image format appears to make no performance hit at all on modern hardware).


So, the results are attached in the spreadsheet, however the basic are as follows - it made a display 8 wide by 6 tall of tiles, so 48 sprites per sync, and syncing 1000 times - so that's 48'000 sprites per test. Each test was run first by creating the sprites each time, then again by creating it once and then cloning it for every other instance.

Test 1:
Create a sprite, nothing more.
PC managed 2882 sprites per second, mobile 2802.

Test 2:
Create a sprite, then resize it to 160*0.456 by 100*0.456 to test reduction scaling speed.
PC managed 2882 sprites per second, mobile 2800.

Test 3:
Create a sprite, then resize it to 160*3.456 by 100*3.456 to test increasing scaling speed.
PC managed 2882 sprites per second, mobile 2791.


Test 4:
Create a sprite but this time the image was x4 at 640*400, then resize it to 160 by 100 to test image reduction.
PC managed 2880 sprites per second, mobile 1960.

Test 5:
Load 9 images, create a sprite from them choosing the image number at random using Random(1,9).
PC managed 2880 sprites per second, mobile 2801.


Test 5:
Load 1 images contaiing the previous 9 images, create a sprite from them but set sprite animation up and use frame switching to display the sprite.
PC managed 2882 sprites per second, mobile 2802.

So, the big surprise was that no matter how you do it, the PC seems literally never to vary. It does create a very odd cap of 2882 (the time taken was 16.660xxxx seconds) for most of them - which I presume to be a limit of either the core the code ran on, or the graphics card - maybe Paul could shed more light.

The mobile was slightly more revealing, in that it dipped slightly when enlarging images, but quite literally fell over when overly large images were used and reduced - this is oddly the reverse of what I expected and it makes more sense that scaling up a smaller image would by more taxing as additional data needs to be inserted, but reducing drops data out. But the test was conclusive, the mobile speed soared from 17.19 seconds average to 24.466 for this one test.

Using cloning over just creating the sprites also showed no particular benefit, nor did putting all the tiles into one image and using it that way, though I expect this would change using slower hardware.

So the moral is, for mobile games if you are going to scale sprites in size try and use images as small as possible (at least on Samsung hardware).

Has anyone else found anything different or any other tips on boosting sprite drawing speed?

Excellent analysis. Can you post the test suite so that we can make more comparisons?

Is the sprite resizing done by the cpu or on the gpu?

Now there's an idea. At the moment it;s just a single, very very simple routine that I was changing as I went to do various things, but I suppose I could very easily turn it into a mini benchmarking tool and output to a text log. I'll fire the code that I had here, but I think that might be a very good idea. I was planning to test some more things myself anyway, such as speed gains from breaking processes down (instead of doing something like A=((B*C)-(D/F)) doing it in stages like VAR1=B*C : VAR2=D/f : A=VAR1-VAR2) and such forth. What other things could be tested? I don't expect too many surprises to be honest, but the bottle neck on the PC and the sudden drop in performance for larger images on mobile are interesting. I wonder, as my game is designed at 1280*720 using virtual resolution, on a smaller device would I get up to a 30% increase in sprite creation by having a smaller sprite set available too? I've no idea how AppGameKit handles this if the device is capable of using the larger images.

Phaelax, I'm not 100% on that. I think AppGameKit uses 3D planes of a sort to control it's sprites so they are essentially very simple textured objects, so I'd guess the GPU for rendering and the CPU for calculation. Paul would need to confirm any of that though, and for mobiles it's likely to vary from device to device anyway. Both my phone and tablet have dedicated graphics, which is why I suspect it's keeping up quite well with the PC all things considered.

Anyway, this was the final iteration of the code that I used for the final test, along with it's media. I didn't intend this for distribution though, so it's not commented or anything.

Hi Santman,

what version of AppGameKit did you use to test its performance? I've noticed a decrease in FPS when using 3D in AGKv2 Alpha 3 and would like to benchmark different versions in the future.

Zerotown, this is all done with the last v1 release as I've yet to try any of the alpha builds.

Some 3d testing should be easy enough though. And I've had a light bulb moment on the frame cap and wondered if it was a default 60fps sync rate, or linked to the pc version being windowed - that requires exploring.

On the PC it sounds like you were running up against the frame rate limiter which keeps the program at 60 FPS or below. On the PC you can turn this off with SetSyncRate(0,0). Mobile the devices tend to have an inbuilt fps limiter that can't be turned off so you'll have to create more sprites until the frame rate starts to drop.

With bigger sprites the fill rate will be the bottleneck, which isn't necessarily how large the image is but how many pixels the sprite takes up on screen. You can read some of my notes about performance considerations here

I was thinking that, because there is a massive difference when sizing a sprite on mobile compared to PC - the PC will jprobably cope, the mobile device will probably choke... I think setting a sprite size requires the shape to be calculated again, but setting a sprites scale doesn't, so it's much faster.
Just something to keep in mind next time you need to resize a sprite in a main loop.

Thanks Paul, I did wonder afterwards about the PC. I just tried that with the PC version, it dropped to taking 0.310004 seconds, or increased from 2882 sprites per second to 154,836. Now THAT is an awesome tip, def time to try that in my main code with a custom frame limit controller.

VanB, I'll give that a whirl too, see if scaling the sprites rather than setting their size makes a difference, that should be easy to measure too.

This is exactly what I was hoping might come from this thread.