I've used System.exit(0) before to quit my game. But as this is a no-no in Android I tried calling just activity.finish(). Now if I start the game again right after quitting it, all textures are messed up (white, stretched, or otherwise messed up).
I'm using both managed and unmanaged textures in AndEngine. And AndEngine version 1 (so no OpenGL ES 2.0).
What are all the unloading I should do manually before quitting the game to avoid this from happening? What do normally unload with OpenGL based Android games? Any tips and tricks are very welcome.
Well this is a really old question. But my problem really was that I had static references to (actually Scala objects) that would hold on to the textures even after finishing the activity and only killing the process would help. Really bad design. Be careful with your references on Android.
Related
I'm always worried about optimization when it comes to game design and need to ask more experienced kivy users about some concerns.
Which one is truly faster?
Lets say you stored your graphic instructions in class attributes. If you're going to have a number of graphics updating on the screen every frame, but you're not adding or taking away from the canvas, Ask_Update seems to be the qualified choice.
Lets say you do add and remove graphic pieces around enough. Would it be better to just Clear the Canvas and canvas.add the stored instructions back?
or
Would it be better to call Clear after every removal or addition? That would seem like a pain in the tail vs just Clearing and canvas.add the graphics back.
Vectors....
How optimized are Vectors? Is the function/method a slow process? Just wondering because I've used 3D engines in the past that had some slow calls and it's usually the mathematical ones.
What is considered a good frame rate for a game app running on a hand-held device?
I also wonder about deleting instances. Does kivy have some special call for deleting an instance or would the usual del call (after running a cleanup function) and python garbage collection be enough?
I'm researching now because I don't want to develop something only to realize I wasn't aware of Kivy 'dos-and-donts'.
Clearing the canvas is inefficient, don't do that unless you actually want to remove everything.
You don't need to call ask_update in general.
Kivy's Vectors aren't particularly optimised, they're just wrappers around lists, but this probably isn't actually a problem for you.
A good framerate target is 60fps.
You can look at KivEnt for a game engine with particularly good performance with Kivy.
There's some possibility for an android OpenGL application of GL context loss while on background. So, to keep things simple, if you're got unexpected Renderer.onSurfaceCreated call - whoah, you're lucky. System wiped you out and you have to recover all you GL stuff from scratch.
One thing that rather bothers me and google documentation seems to keep silence about - how could one firmly and efficiently reproduce the issue during development?
Good day,
I am developing an adventure game in AIR for Android. I am instantiating levels from the library (movie clips), each containing at least one HD resolution bitmap.
When the game starts, it occupies about 150MB of memory, including the AIR runtime and the SWF. Out of this 150MB the SWF is about 12MB at this time.
As the game progresses the memory consumption of the AIR runtime increases, while the memory used by the SWF remains at around 15-20MB. When the total memory consumption reaches about 350(!)MB, the OS intervenes and kills the app.
I was careful to reuse objects whenever I could, and nullify any unused objects to make them eligible for GC. GC seems to be working as it should, as the memory used by the SWF remains steady around 15-20MB. I can see it drop from 20 to 12 from time to time when GC kicks in.
Things I've tried:
Removed all cacheAsBitmap and cacheAsBitmapMatrix properties.
Exported each level into a separate SWF and loaded them from there instead of the library.
Forced the GC hack just to see if it has any effect.
Fiddled with System.pauseForGCIfCollectionImminent(n) with different values for n.
Tried different acceleration modes (direct and auto) thinking maybe the GPU is at fault.
All failed, memory consumption just runs away.
This happens only on Android. On a PC everything is fine, the whole thing takes up about 250-300MB, and this number remains steady, no matter how many levels I load one after another. Didn't have the chance to test on iOS yet.
I would really appreciate any ideas or insights into how to make this problem go away.
Thanks.
1) Easiest way to find memory leak is to use Adobe Flash Builder. Just run profiling.
2) Also good way to exclude leaks in future: create function which will be used for "cleaning". E.g. it will null all local variables of instance and so on. Something like usual c++ destructors. Then, before nulling your object, just call this method.
Working on an app that uses a MainActivity->RelativeLayout->GLSurfaceView.
When exiting the app (OK, per contractor requirement) via Activity.finish(), on next launch it will start in its initial state (OK, per contractor requirement) but all textures will be white.
Closing the application via System.exit(0) fixes this, so it's pretty obvious that some form of
OpenGL resource is not being freed.
The textures should all be freed, since there's a manager for them, and none seem to leak.
I'm looking to replace System.exit(0) with something that flushes all OpenGL resources (if possible) ?
Is there something like a context destroyer exposed on Android ?
I am using AndEngine GLES 2.0. sometime when I resume my activity there is a complete blackout in the game. Although update and touch events of sprites are working but there is a complete blackout on screen. what is the problem?
AndEngine assumes the EGL context was invalidated, and thus must reload all your resources. This typically takes a non-negligible amount of time, causing a black screen.
Efforts are underway to eliminate this problem on Android 3.0+ where possible, but it will likely always affect Android 2.x
My problem is solved now. Blackout is due to the memory management. I was loading engine every time user plays the new Map. One should load engine for only one time and use Layers.