I am designing a game in Open GLES on Android in Java.
Obviously I am using lots of textures and soon I will run out of memory.
I am quite new to Android and Java, but I figured that the easiest way to go round this problem is to destroy the objects with bitmaps, which I don't need at the moment, let the garbage collector reclaim the memory which they occupied, then re-create those objects at the late stage when I again need the respective textures.
Something like this:
background = null;
then when I need the textures in background object:
background = new Background(context);
seems pretty straighforward, except that is, that the context (which I need for my class background to function, as it loads the textures from it via BitmapFactory) is not passed into onDrawFrame(GL10 gl) function where my main game loop is and where I need it !
If I try to add context as a second parameter after GL10 gl, I get an error - this does not seem to be possible.
Does anybody know how to pass context into onDrawFrame, or other way how to clear the context objects from memory and then reinstate them again ?
Thanks in advance for any help.
How to pass context into onDrawFrame
I wouldn't pass the context into onDrawFrame. You won't be able to anyway if you are using the GLRenderer approach. It provides the method onDrawFrame(GL10 gl) and you are expected to just do your rendering there.
The context can be passed to the Renderer much like you have done via the constructor (this is ok) as you will need it, like you have correctly pointed out, to load resources and such like. The important thing is not to leak it. The context will come from the overarching activity that is currently active. It will be freed eventually assuming you didn't leak it when the activity is finished()
We used a TextureManager class to handle allocating the bitmaps and keeping track of what is loaded. You can make these bitmaps Weak or Soft references if you want to be really aggressive about how the Garbage Collector deals with them (We did at one point, but no longer do...although we might change it back). We used the TextureManager so we could track what resources were being loaded and handle clearing them up again (If you do this you can log exactly what is going on a little bit easier and track down leaks). When you are done with a bitmap ideally you want to call recycle() on it then let the Garbage Collector do its thing. Whenever a game object needs a bitmap it just queries the TextureManager for it which _can_ load it on demand if needed or tell us that we have not actually allocated it or that we ask it to be allocated but it is now null (generally an indication that the Garbage Collector has eaten it ...which can happen as if no game objects are referencing it and the garbage collector runs it is likely the bitmap will be collected).
Some extra information on how we structured things (not even sure it is the correct way to do things but it works for us) and might give you some insight. We actually use the Canvas and the GlCanvas and use the onDrawFrame(Canvas) or onDrawFrame(GL10) of the Renderer to run our game loop. Essentially constantly having the renderer updating and delegating the drawing into the Canvas or GL context to an object such as a Scene (Which could be a level or just an animated menu etc). So all our onDrawFrame does is a standard game Loop. By adopting the same interface switching between OpenGL and standard Canvas is not a huge problem (Obviously the way you deal with textures and bitmaps between them differs a bit but our abstractions and TextureManager help us with that).
The context can be passed to the Renderer much like you have done via the constructor (this is ok) as you will need it, like you have correctly pointed out, to load resources and such like. The important thing is not to leak it. The context will come from the overarching activity that is currently active. It will be freed eventually assuming you didn't leak it when the activity is finished()
We used a TextureManager class to handle allocating the bitmaps and keeping track of what is loaded. You can make these bitmaps Weak or Soft references if you want to be really aggressive about how the Garbage Collector deals with them (We did at one point, but no longer do...although we might change it back). We used the TextureManager so we could track what resources were being loaded and handle clearing them up again (If you do this you can log exactly what is going on a little bit easier and track down leaks). When you are done with a bitmap ideally you want to call recycle() on it then let the Garbage Collector do its thing. Whenever a game object needs a bitmap it just queries the TextureManager for it which _can_ load it on demand if needed or tell us that we have not actually allocated it or that we ask it to be allocated but it is now null (generally an indication that the Garbage Collector has eaten it ...which can happen as if no game objects are referencing it and the garbage collector runs it is likely the bitmap will be collected).
Some extra information on how we structured things (not even sure it is the correct way to do things but it works for us) and might give you some insight. We actually use the Canvas and the GlCanvas and use the onDrawFrame(Canvas) or onDrawFrame(GL10) of the Renderer to run our game loop. Essentially constantly having the renderer updating and delegating the drawing into the Canvas or GL context to an object such as a Scene (Which could be a level or just an animated menu etc). So all our onDrawFrame does is a standard game Loop. By adopting the same interface switching between OpenGL and standard Canvas is not a huge problem (Obviously the way you deal with textures and bitmaps between them differs a bit but our abstractions and TextureManager help us with that).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement