ive made a rather simple game and ported it to several devices. but my expectations got a real hit when i saw the performance on the sony-ericsson T610. when i hit a button, my game object reacts up to a second later. in the animation sequences frames are skipped etc.
now im asking myself if i have to optimize more brutally or if there are common problems with this device …
i have had the same problems with this mobile, really its slow, and no only in games, also in menus, etc…
HAR HAR HAR !
i got that freaky little bug!
i knew the odd thing that t610 cant handle image files larger that 255px and that some older versions have problemes with images larger than its screen resolution.
but now another wise tip:
never ever use big images !
i splitted my 128x128 background image into four 64 tiles and voila! my fps counter boosts from 3 up to 12. at this point its quite playable for t610 relations…
The T610 has a finite (and quite small) amount of fast ‘graphics’ memory.
Once this is filled, images will be stored in regular slow ram.
The key to optimising for the T610, is to keep the number of images currently loaded to an absolute minimum at all times. (by swapping unneeded images out of memory etc etc)
80 KB of video RAM to be exact. The moment you have more images that can be stored there they will get loaded into normal memory and that’s when the performance takes an extreme drop.
shmoove
hmmm, but wheres the difference of having a 64644 or
128*128 image ? both are 16k of pixels to store.
i nothing else changed than splitting the big image.
the video-ram should be filled like loading the 128x128 image… ???
The T610 uses a 2-byte per pixel format, so a 128*128 image is around 32 kb.
shmoove
ok, nice information, but this does not explain, why theres a difference between splitting an image and do not so.
with a little difference of reference overhead (which only lasts on the heap) many little images take as much video ram as on big images (as long as the amout of pixels are the same).
I can’t say for sure.
I assume you have other images as well in addition to this background image(s). Maybe there isn’t enough space in the video RAM for the whole background, but 3 out of the 4 split images do fit there and give you the performance boost.
Have you tried playing around with the order in which you load images?
shmoove
hmmm, could be a reson. but one thing would wonder me.
to get the performance hole i checked a button deactivating the rendering of the background.
every time, the bg didnt get rendered the performance increased. but the bg-image was still in memory i only switched a flag inside the program.
i really dont know how the t610 manages the loading of the vid-ram (does it load only needed images into it or does it load ALL possible images permanently into the vid-ram).
btw: there are many not understandable things out there:
on the nokia 7210 i had the issue that my images seemed
to break the heap limitations. as i removed the splash screen, the whole thing worked.
then i thought, it would be a nice idea to set the image reference of the splash-image =null, let the gc enough time to get rid of it and then to load the other ingame-images.
but it didnt work … and i dunno why …
finally i had to reduce the color depth of my images to free memory.
Well, on the Series 40 Nokias (like the 7210) the problem is with the non-compacting GC. Loading big images late in the game might be problematic because even when there is enough free memory, it might be too fragmented and there won’t be a block big enough for the image. This problem exists in many other phones, but seems to be a lot worse on the Nokias.
The background is still in memory, but the thing that is slowing you down is when you try to paint it. If an image doesn’t fit in the video RAM, then the actual process of drawing it onto the screen (copying the bits from the regular memory to the screen’s buffer) becomes extremely slow. If you’re not drawing the image then there shouldn’t be any effects on performance, except for maybe the fact that the garbage collector might kick in because you’re running low on memory (but this is very easy to control). Just having the image loaded into memory doesn’t slow you down.
shmoove