Memory Management

  ... discussions about development with the GLES2 branch of AndEngine.

Memory Management

Postby e.r. » Sun Jun 09, 2013 9:55 pm

Hi Guys,

Since we are talking about memory anyone has a particular number that the heap should not surpass?

I was looking at some of the games developed by AE, it varies from 17Mbytes to 25 mbytes. I tried one random 3D game and the heap is around 90Mbytes.

1 - So I think our concern is the low end devices, and lower API's; anyone has a clue for AE games memory threshold?
2 - Should we consider max size of texture atlas combined compared to device RAM?
3 - Why are we saying that the unloading texture region is not recommended? any previous bad experience with this?
4 - The thing is how to actually measure this ? trial and error to see if it crashes? there must be a metric for this :?
PS: I might be approaching this wrong, any advise is welcomed.
User avatar
e.r.
 
Posts: 557
Joined: Sun Sep 09, 2012 1:41 pm

Re: Memory Management

Postby RealMayo » Mon Jun 10, 2013 2:48 pm

Hi er,
I have a different perspective than most people, and that doesn't mean my perspective is the best...
I don't want to cater to low end devices because even if I optimize my game to suit the limited memory that low end devices have, those users will still experience lag and other performance issues when playing my game. As such I'd rather identify and block those devices that can't handle decent sized graphics. So if their phone is experiencing an out of memory error when trying to load my game with normal resolution graphics, that tells me they're phone is crap. For example of you simply run the PhysicsExample.java on a crappy phone and add one hundred physics bodies to the screen, that is enough to cause lag! I don't want that kind of phone playing my game.
On a side note, the reason I say don't unload TextureRegions is because at least for my game, 75% of my TexturRegions are used in every level of my game. Unloading and reloading them every time results in the user having to wait in between levels.
User avatar
RealMayo
 
Posts: 1694
Joined: Sat Sep 03, 2011 9:25 pm
Location: Chicago, IL

Re: Memory Management

Postby e.r. » Mon Jun 10, 2013 3:32 pm

Hi RealMayo,

RealMayo wrote:I have a different perspective than most people, and that doesn't mean my perspective is the best...


I think there is no such thing as a best approach : ) each has + and -, I love to discuss this topic to see the different aspect so that we can conclude the convenient for each type of our project

RealMayo wrote:I don't want to cater to low end devices because even if I optimize my game to suit the limited memory that low end devices have, those users will still experience lag and other performance issues when playing my game. As such I'd rather identify and block those devices that can't handle decent sized graphics. So if their phone is experiencing an out of memory error when trying to load my game with normal resolution graphics, that tells me they're phone is crap. For example of you simply run the PhysicsExample.java on a crappy phone and add one hundred physics bodies to the screen, that is enough to cause lag! I don't want that kind of phone playing my game.


I used the same approach with my first games, I admit I did a lot of technical errors that was behind the crashes, but even after optimizing. I still got errors due to crappy device. My main concern is that crappy devices are becoming more and more popular, you can get a tablet for like 60$, especially in third world countries and china. Removing these devices means smaller market , that's my main concern, in addition even the new devices like the new ace and young, they are packed with 1Gbytes, but packed with android jellybean which consumes a lot more then gingerbread.
So the new devices are have more available memory? or still, since more hardware memory resource but more software demand...So we need to test the new device of the series. So it feels like "hide and seek" with the devices. . .
Removing the devices is a valid solution for me but it is at the bottom of the solution lists.

RealMayo wrote:On a side note, the reason I say don't unload TextureRegions is because at least for my game, 75% of my TexturRegions are used in every level of my game. Unloading and reloading them every time results in the user having to wait in between levels.

Totally agree, I thought there was some technical reason behind this but now it is clear. I do the same thing in my new game, but since it is a kinda relatively big project I am loading the common texture, and dynamically unloading the other small sections.

To add a hint it seems that turning off features based on device specs is a good thing, since it kinda like the user "gets what he payed for", if he paid 60$ for a tablet then he will not have the particles and shadows and others.....but that;s why I needed a reliable metric to detect this. ( Dreaming . . . --> Maybe GoogleAndroid devs will provide us with an API Android.IsCrappyDevices() :lol: )


Thanks a lot RealMayo, your feedback is always appreciated : )

If anyone else has a tip about a metric "correlated" with the device (for game construction), please feel free to share your thoughts.
User avatar
e.r.
 
Posts: 557
Joined: Sun Sep 09, 2012 1:41 pm

Re: Memory Management

Postby RealMayo » Mon Jun 10, 2013 3:43 pm

Thanks for your response.
A tip back to you...
The following two phones cannot play Traktor Digger...
Samsung xCover
Samsung Rugby
I don't know if it will help you at all to compare those phone's specs against my game's memory footprint as an example of limitations.
Btw lol, I have never analyzed my game's heap size :lol: If you do happen to analyze my game as part of your research, please let me know what you find ;)
User avatar
RealMayo
 
Posts: 1694
Joined: Sat Sep 03, 2011 9:25 pm
Location: Chicago, IL

Re: Memory Management

Postby e.r. » Mon Jun 10, 2013 7:54 pm

I tried traktor digger, man your total heap size is around 70 Mbytes, and it seems there is a leak :S

try this scenario and loop it around 20 times:

Go into the game load level 1
hit back --> quit --> in level selector load level 2
hit back --> quit --> in level selector load level 3
hit back --> quit --> go to level selector --> go to main menu
and back to level selector --> load level 1

The heap went from 70 to 75 mbytes, and didn;t come back down even after a while (tested on gnex).
PS: I read the total heap sizes that is given in the table when using this:
adb shell dumpsys meminfo "packagename"

I am having also a leak in one of my games that uses multiple activities, i even used the same code of my newest game to clean the sprites and bodies ( the new code is gfx tested in a single activity multiple scene and works 100%), but i can't figure out where the leak is coming from when activity is destroyed ! Currently investigating music and sound since this is the area where I haven't checked for leaks yet
User avatar
e.r.
 
Posts: 557
Joined: Sun Sep 09, 2012 1:41 pm

Re: Memory Management

Postby RealMayo » Mon Jun 10, 2013 8:24 pm

LOL wow, thanks for that info! I suspect it might be a leak in my sound/music. I'm curious if you re-ran that same test after selecting in my game to have no sound.
I guess on a positive note I was able to get 5 million users while my game had a 75MB heap size. I guess you could consider that your upper threshold of a heap size for new games LOL.
User avatar
RealMayo
 
Posts: 1694
Joined: Sat Sep 03, 2011 9:25 pm
Location: Chicago, IL

Re: Memory Management

Postby e.r. » Mon Jun 10, 2013 11:02 pm

and 3 hours later... my leak reason is found, still the typeface....same as in the below thread
https://code.google.com/p/android/issues/detail?id=9904

When having a single activity you create a single typeface and you use it everywhere, when having multiple activities, you recreate each time and killing the activity does not free the typeface.

I think we need a Static solution as they mentioned in the thread......wait what? Static :twisted: ;) ?

Anyone knows how to free the Typeface allocated? Because killing the activity does not free it
User avatar
e.r.
 
Posts: 557
Joined: Sun Sep 09, 2012 1:41 pm

Re: Memory Management

Postby RealMayo » Mon Jun 10, 2013 11:11 pm

Very interesting, @er! You're like an E.R. Doctor performing surgery and finding all the tumors :lol: ;) Nice work!
User avatar
RealMayo
 
Posts: 1694
Joined: Sat Sep 03, 2011 9:25 pm
Location: Chicago, IL

Re: Memory Management

Postby RealMayo » Tue Jun 11, 2013 2:21 am

Here's another extreme basis of comparison...
adb shell dumpsys meminfo com.rovio.BadPiggies
User avatar
RealMayo
 
Posts: 1694
Joined: Sat Sep 03, 2011 9:25 pm
Location: Chicago, IL

Re: Memory Management

Postby smartus » Tue Jun 11, 2013 3:57 am

My main concern is that crappy devices are becoming more and more popular, you can get a tablet for like 60$, especially in third world countries and china.


I live in part of the world, where you can get a million different cheap tablets for $60 (from the same manufacturer in China :)) and I tell you this: Half of the people here will buy Samsung Galaxy S4 1-2 days after release (the others are Samsung haters who buy HTC One). Yeah, it costs them a month salary, but it is a status thing...

Now these tablets sometimes even come with illegal software and people who buy them usually give them to kids to play some super simple game and break it in the process. BTW I bought a HaiPad from China for equivalent of $57. It come with quite low memory, but it is actually quite fast. The only problem is low quality screen (pixels are not square, the viewing angle is about the same as on those old monochromatic LCD displays :roll: ), sound is crap, I had to replace the usb cable. But the GPU & CPU are actually quite fast.

But hey, this tablet actually made me start making games!
User avatar
smartus
 
Posts: 510
Joined: Fri May 10, 2013 4:17 pm

Next

Return to GLES2

Who is online

Users browsing this forum: Exabot [Bot] and 160 guests