Sorry your browser is not supported!

All,
We are developing a puzzle game and it is going very well. We really enjoy AppGameKit v2 and think it is an amazing product for us to develop with.

However, after playing for 3 hours on my android phone, I got the following message: ERROR: Ran out of GPU memory on line xxx (See attached)
That line is actually a SYNC() [of course, since that updates the screen]

The reason I am looking for a debug / GPU Memory check command, is to be able to find what is going on.

Here is our GAME code structure

1. Preload Images [ All images: 4MB as jpg & png ]
2. Preload Fonts [ TTF : Only 2 - 61K ]

then after that we have sub-menu's and play cycles, for each of these we do the following:
a. Delete All Sprites
b. Delete All Texts
c. Create Base Sprites (1 for each type of graphic used in this section)
d. Clone any and all sprites needed in the playing field
e. Create All Texts as needed in this section
f. Make these visible as needed
g. When user leaves the MENU / CYCLE
g1. Delete All Sprites
g2. Delete All Texts

Since it takes me about 3 hours to get the error, as well as the fact that we delete all sprites & texts every time AND we don't load any new images/fonts.
It seems to suggest there is a memory leak somewhere or a garbage collection issue, that makes the memory slowly fill up until it hits the threshold.

To confirm that it is not a particular level that causes this by creating too many sprites, we never exceed 1,000 sprites ( 90% of which are 60 x 60 which would be 3600 x 4 = 14400 bytes per sprite ) never more than 8 overlap.
After it crashed, when I start up again, and continue from the same level everything works great again for 3 hours or so.

What would really help me is the ability to check the available GPU Memory in various places in the code, to see if there are area's where it goes up, but not down. Maybe we missed something in our logic or can identify where the problem occurs.

Without a resolution for this problem we cannot publish the game, because it would crash at some point and that is unwanted behavior.
I have not yet been able to test it on iOS as extensively, so do not know if the issue exists on both platforms. I have not seen it on windows yet, but my machine has 32GB internal memory.

Any and all help is much appreciated.

Have you tried all the benchmarking debug stuff?

Play the game with FPS message at the top, to see if its running low over a period of time.

print(screenfps())
sync()

If is running low, got bad loops

Damo

Done that, no difference. Also use the screen draw counters etc. No difference.
Did the same with timers around specific sub-routines, no difference.

This is why it is so hideous and impossible to identify.
And, please note, it is not a speed problem, but a memory fill problem. It keeps adding (or not freeing) GPU memory.

If I could measure GPU memory allocated or free in my code, I could find out where the culprit is.
But now I have nothing to go on.

Wasn't this an issue that was fixed in an earlier version, where the libPNG library which AppGameKit uses to load all images wasn't closing the file or something, so was just filling up the buffer until it crashed?

GPU memory problems is usually too many images or 3D objects. Based on you game code structure, if you are never loading any images after the initial setup and you have no 3D objects, then the most likely cause is the font images. Every call to SetTextSize creates a new font image with the new sized characters on it, and keeps the most recently used sizes cached in case they get used again, it's possible it is keeping too many around, but each image is fairly small. Are you doing a lot of resizing of text objects? Also the larger the size of the text and the more characters it has then the larger the font image will be.

Did you do any minimizing of the app during the 3 hours or was the app on screen the entire time? Minimizing destroys the OpenGL context so AppGameKit saves the image data in RAM and then reloads the images when resumed, but it doesn't delete the saved data in RAM in case another minimize happens. It's possible this is contributing to the problem.

Number of sprites and their sizes shouldn't be an issue as they don't store anything on the GPU.


Is that file size? If so then the image will be decompressed into GPU memory so the actual size of each image will be width*height*4 bytes in memory.

I've uploaded a debug version of the Android player here that will print the current image memory usage to the screen (including font images), which might help track it down. I'll add this as a command for the next version.

Paul,
Thank you for your detailed and thoughtful answer.
It certainly has helped me forward in my thinking.

We deployed the new TFF images and call SetFontSize in the closing of the level (once the user solved it) we scale rapidly from size 5 to 100 I believe and then jump out.
However, we do that every level, and I had played over 25 already before the GPU memory occurred. So, if it works once within memory I would expect it to work every time.
Also, this cycle may be interrupted at any time by me clicking on the screen, OR a PostOnFacebookWall() process.

I did not minimize the app, since that would create the lost TTF font issues and would prevent me from continuing forward.
I usually compile the the code into an APK package and then download it to my phone to play, since that is how it would be released.
But, I will try the player, see if anything jumps out at me.

Truly appreciate the new command in version 2.0.23.
Working in AppGameKit v2 has been such a joy for us, so thank you, thank you, thank you, for all you are doing.

I will keep you appraised of the progress with this issue.
James

Paul,
Your Android player did the trick.
In one of our menus there was a tiny little loop that loaded 180 buttons every time we got there. (31MB every time -> 750MB after playing 25 levels)
We are moving this to the pre-load and the problem will be gone.

We did also see that the TTF SetTextSize added memory continuously, but that was only 0.9MB per time. So we will no longer use the SetTextSize with the TTF fonts but create a different effect.
It was awesome to see the memory counter roll up every-time we got there.
I think adding this command to the AppGameKit command set will help a lot of programmers see what the memory effects of implementation choices are and find alternatives where needed.

Thanks again for your help.
James

This is a great debug feature for assessing media impact, thanks for adding it!



I am wondering if there should also be a SetTextScale() command that would scale the previously generated font image to a given size without needing to regenerate any font images or consume additional memory. This would be suitable for transitions and other purposes that don't require perfect TTF display. Alternatively, consider adding an optional flag to SetTextSize() that would indicate whether to regenerate the font image (true by default) on size change, or to merely scale the previously generated one as a standard sprite. On this front I'd also propose the ability to set text positioning by offset (and also scale by offset if a scale command were to be added) although the SetTextAlignment is useful enough in most cases.

Thanks again Paul.

Nice one, very useful.

Thanks Paul!

I have confirmed that the cycle of fast FONT resizes does add memory use.
However, as soon as I delete the texts with DeletAllText() the memory is returned and freed up.

Just an FYI for the next person who needs to know.
James