Sign in to follow this  
_nomad_

j2me game slows down after a while

Recommended Posts

Hi, I pre-load all the images i need for drawing the background, but when i switch background images, it slows down. I didn`t call Image.createImage() anymore since the new background has been pre-loaded already at the start...i do something like: switch(currentBackground) { case 0: Draw_Background1(); break; case 1: Draw_Background2(); break; } While I am playing with background 1, everything is fine and smooth, i tried playing with background 1 (w/out switching background) for a long time and it doesn`t slow down the game. The game only slows down after switching the background. Any ideas why this is so? it's midp 1 by the way, and being tested on a SE Z600. Thanks.

Share this post


Link to post
Share on other sites
Some phones have a limited amount of video memory, which can be quickly blitted to the screen. A few fall back to standard memory after the video memory is exhausted, which will be slower. Skizz is right--without seeing the real code, it's impossible to know what's happening--but you might try switching the creation order of the backgrounds and see if it affects things.

Share this post


Link to post
Share on other sites
It certainly sounds like that is the case (garbage collection working over time). Use the Runtime.freeMemory() method, and print it out on the screen to see the state of your free memory when the slow down starts happening. It could be that some buggy method on the Z600 is somehow leaking memory.

shmoove

Share this post


Link to post
Share on other sites
Ive just noticed the exact same thing on a t630 today, it is a memory issue with them, as far as I can figure the phone caches or places in a faster memory, some images, then by using any other images it has to swap them in and out of memory to draw them making it incredibly slow. A solution would be to only create the images as and when you need them, this leads to only a very small delay whilst the image is created but it is better than the whole game being slow. Well its worked for me, I hope this helps.

Share this post


Link to post
Share on other sites
Hi. Thanks for the suggestions/infos guys! Unfortunately, I've tried what fatjaba said (creating images only when needed and then setting unneeded images to null when no longer needed)...when i swap images for the 3rd time, it slows down already...first two times it is in ok speed...

...the images are large though, taking up 128x128 pixels combined (three images form the background, where i swap them)...and no, tiling won't do as this isn't a tile-based game...:)

i've succumbed to making the game work with one background only in Sony-Ericsson version, and four backgrounds on Nokia version...it's a bit discouraging to work on SE phones! :(

Share this post


Link to post
Share on other sites
Hi, are the images actually set to null before you load the new image? It may not have been garbage collected to re-allocate the memory. I cant think what else it might be, this works with mine but the images are smaller and I had to split them into strips to make it work at all. Each characters animations were in one file, now they are in 4, one for each direction... can you tell us any more about the game, what other images are loaded at the time? You need to free up some memory somehow. Sorry i cant be much more help.

Share this post


Link to post
Share on other sites
Yes... make sure to call System.gc() after setting the image to null and before creating the new image. Depending on the implementation, you may even need to call it twice.

Share this post


Link to post
Share on other sites
Quote:
Original post by Sneftel
Yes... make sure to call System.gc() after setting the image to null and before creating the new image. Depending on the implementation, you may even need to call it twice.


O_O

Twice? What's going on here that it would be necessary/make a difference?

Share this post


Link to post
Share on other sites
Quote:

Twice? What's going on here that it would be necessary/make a difference?
Some MIDP implementations use a generational collector which may not do a full collection each System.gc() (despite the fact that, IIRC, System.gc() is supposed to do a full, rather than incremental, GC). It's not common by any means, but we've run into it before.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this