Skip to main content
GameDev.net gamedev.net
🔒 Locked

Big problem with memory.

Started by JohnLamock Aug 2, 2006 at 1:45 PM 6 replies 1k views
Original Post
JohnLamock
JohnLamock
Hi friends, I'm having a big problem here. We are finishing a 3D race game, using Mascot v3 API, with MIDP 2.0, CLDC 1.1. Everything is done. We were using a SonyEricsson W800i to test the game, and the problem starts when we began to test the game in another devices, specially SonyEricsson K700i. So, my problem is that the game suddently stops and quit after some minutes playing. To continue playing it normally, I have to turn the device of and turn it on again. This fact is due to lack of memory, I think. Is really that? Well, I tried to solve the problem optimizing the images, the number of polygons, reducing the tracks of the MIDI file... I'm calling garbage collector several times during the execution of the game but the problem don't stop. It takes more time to quit, but it still happening. I was googling for some documents that speaks about J2ME optimization, but none have this aproach or cover this kind of 'bug'. I don't know what can be done, and I don't know what is really causing this. Any help will be nice, Thanks in advance, John.
Thygrrr
Thygrrr
It's a bug in the K700i and likely some other phones in SE's Java Platform 3.

Loading/creating many images usually causes this bug. It seems to be a memory leak somewhere, and it's permanent memory loss (unless you power cycle the handset). That means it's cumulative: Every time you load an application, you mess up the phone's memory some more. SonyEricsson even recommends power cycling the handset regularly for better 'performance' (ya right).

There's nothing you can do about it except load/create images less frequently. It's a serious hardware or platform level bug, and it recurs in most firmware versions (maybe even all of them). It's not unlikely that there are other native functions that are also leaky; i.e. M3G texture loading, etc.

Also, when memory is critically low due to the leak, you will have strange problems starting just about any java app. Usually random IOExceptions, OutOfMemoryErrors, bright white pictures, ruined alpha channels, and other such niceties - even total handset crashes (screen flickers white/blue/babyblue until you turn it off).


I develop lots on my K700 at work (because it's always within reach), and I usually have to reboot the handset once every two days or so. Apps that load/generate a lot of images unfailingly kill the handset after just a few minutes.


PS: If you guys are looking for a publisher with good access to sales channels in Europe, you can send me the Game specs & pitchdocs and I can forward them to our content manager so he can have a look at them :)

[Edited by - Thygrrr on August 2, 2006 2:56:23 PM]
JohnLamock
JohnLamock
Hi Thygrrr,

Thank you very much for your reply. It's exactly the problem!

So after this bad news [dead], what do you usually do to transpose this problem? Load everything into memory and keep them there? This heappens only with images or with everything you create (e.g. MIDI files, MBAC files)?

Thank you,

John.
Thygrrr
Thygrrr
I think it mostly happens with images, but as I said before, I'm not exactly sure. I believe there are smaller memory leaks in other functions (especially mp3 and wav file playback appears problematic, but that could just be a side effect of the image problem - mp3 playback needs much of memory, so a corrupted heap will show symptoms much earlier). I'm also not sure whether it happens for all tyes of images, or only a given subset (images with transparency maybe? or images with non 24bpp/non 8bpp pixel formats? nobody can really tell, because you'd need a memory profiler for the device itself)

I usually load most images at once, and especially I cache the smaller and the most frequently used ones in a hashtable. It's a very simple function I use, much like the following example.
Image cachedImage(String filename){    Image result = image_hashtable.get(filename);    if (result == null)     {       result = Image.createImage(filename);      image.hashtable.put(filename, image);    }    return result;}


I have also implemented some LRU strategies for heap conservation on low-end handsets, but I never needed that.
JohnLamock
JohnLamock
Hi Thygrrr,

Thank you very much, man! You saved my life (rating 6+)! [wink]

And about the publishers contacts, I'll send you a private message if you don't care about...

Regards,

John.
JohnLamock
JohnLamock
Hello again,

This problem is a very insistent one. [crying]

I tried to make what you said. I cached all the images of the game and it keep getting out. Then, I cached all the meshes, images, sound, textures, everything... And it insists to get out suddently.

So, I coded a little app to try to catch the problem. It only creates an instance of an image every iteration and paint it. The app created more than 300000 images and didn't get out. So, I made several variations, with big images, small images, several images, big meshes, small meshes, meshes and images, objects from custom classes and the program simple dont't get out.

I really don't know what is going on. If anyone can give me another ideia, or correct me at somepoint, I'll be very grateful.

Thanks in advance,

John.
JohnLamock
JohnLamock
Hi Thygrrr,

I found the origin of the problem.
It appears to be a leak in a Particle Engine that I had made with command lists. The particles don't seems to be cleaned of the memory... I'll try to cache those particles too.

Thank you very much for the replies.

Regards,

John.
Thygrrr
Thygrrr
Interesting, so the Image memory leak is not as general as I anticipated. I assume other things factor in, as well.

Great work, JohnLamock!

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.