On android the context could be lost when the application goes in background, so i must save the texture first and reload it after. How can i do this ?
I don't want to save it to a file (but if if possible it's a beginning for me), but i would rather prefer to save it to an array of "bytes"
Right now i keep in memory the bits used to create the texture, but i think it's not really efficient
Related
I am working on an Android project a bit like Minecraft. I am finding this a great way to learn about OpenGL Performance.
I have moved over to a vertex buffer object which has given me huge performance gains but now I am seeing the down sides.
I am right in thinking I need a vertex buffer object per:
Different mesh
Different texture
Different colour
Am I also right in thinking that every time the player adds a cube I need to add that on to the end of the VBO and every time the user removes a cube I need to regenerate the VBO?
I can't see how you could map a object with properties to its place in the VBO.
Does anyone know if Minecraft type games use VBO's
Yeah if you malloc() a memory space then you need to create new VBO-s. If you want to expand it because you need more memory. If you want to show less then I guess you could play with IBO-s but again you have to rearrange the VBO at some point.
I'm not really sure what you mean by object properties but if you want them to be shown then I think you'll need different VBO-s for each kind of property/cube-type / shader pairs. And draw them in groups.
If you want to store other kind of properties then you shouldn't store it in VBO that you pass to OpenGL.
I have no idea what Minecraft uses but my best advice is that you store the not likely to reach cubes in VBO-s and the the likely to use cubes in easy to modify container. (I don't know if it would help or not)
Take an application containing a glSurfaceView which loads several separate images on start (GLUtils.texImage2D(GL10.GL_TEXTURE_2D, 0, bitmap, 0); for each image).
This application will then have to call gl.glBindTexture(GL10.GL_TEXTURE_2D, texture pointer int) before it can proceed to draw a different texture to a "texturable square" gl object.
Is it recommended to instead load one bitmap with all the textures (ie: a sprite sheet), and then create an array of "texturable squares" that each map a different area of the giant single image, like that gl.glBindTexture(...) only needs be called once...?
Or perhaps is there no significant difference between the two techniques?
As far as I know, once a texture has been loaded via texImage2D, binding a texture is simply a matter of pointing the native OpenGL library to the correct preloaded texture, so performance wise, it shouldn't be costly.
However, you raise a good option which you should probably consider regardless of performance issues.
Normally, the textures you need don't have to be in power of two dimensions, but are set to that size anyway because of the requirements of OpenGL. This often results in a very wasteful memory allocation. Utilising "sprite sheets" as you put it can help save the time & memory of loading multiple bitmaps into textures which are usually larger than the parts you'll be rendering anyway.
For this reason, I would recommend using sprite sheets anyway, simply because it saves calls to texImage2D (which are quite costly), and potentially saves memory as well. If you properly manage the texture coordinates when switching between objects you want to render, this is the method I would recommend.
I need to find a way to track positions where the loaded textures are drawn. When some of the loaded textures are overwritten, i have to delete them from memory.
I have a Remote User Interface (RUI) server which sends me a lot of small images, which are assembled and then shown on the RUI client's screen. In this scenario, i have no clue which textures are behind some other textures, so i am unable to delete them. Also, overwriting must be complete (texture behind must be totally hidden).
Is there any efficient way to achieve this tracking and deleting?
My use-case is something like this: i have a menu with button images stored on a server. Whole screen is made of fragments (buttons, scrollbars, animations etc.).
For example, when i click on a button, server sends me a multiple thumbnails of pictures stored in its storage, and i display them in ,for example, right half of the screen.
On other button click, list of songs, videos, ebooks or something else are shown.
I need to remove textures of picture thumbnails from memory and then show list of songs, for example. In this way, overwriting will disappear, and my memory usage will be significantly reduced.
My openGL ES 2.0 implementation is on Android platform, where whole job is done in JNI layer. There is no complicated drawing, just decoding png images, converting to textures, and basic textures displaying.
You can do something along the lines of reference counting to keep track of how many times the same image has been used. When an instance is entirely occluded or off-screen, you decrement the reference count, and delete all the textures with 0 references.
Reference counting could be as simple as a std::map<Texture, int>.
Your occlusion check could just be an O(n^2) AABB intersection/containment test and an extra O(n) test against the screen's AABB. If that's not fast enough for you, try a better data structure like a quadtree or spatial hashing.
Depending on how your application is set up, you could also track instances of your texture with a type of smart pointer and figure out when all of your hidden views have been deleted.
That being said, this is probably a waste of time unless you're actually bound by the amount of VRAM on the device or getting close to it. Loading/unloading images from either disk or a network location is going to be orders of magnitude slower than just keeping it in VRAM if you have it available.
I am currently working on a game for Android. The game is a real time strategy game that uses tiles or cells and has actors (units, trees, rock, etc.) that will occupy those cells.
In my game, cells and actors are objects that have their own draw method. For fear of speed problems, I currently decode the resource in the map class and feed the decoded image to the object's draw method.
Like this:
_waterCell = BitmapFactory.decodeResource(context.getResources(), R.drawable.watertile);
...
_row.get(Cell).draw(_waterCell, canvas, _paint, _X, _Y);
This is fine for now, considering I have few cell types and only one actor but how would I go about this when I have hundreds of images to decode without having to decode the resource every time I draw the object? And if I were to decode all of my resources in the map class, would it cause out of memory errors?
I cannot say whether decoding the resources would cause an out of memory error since I don't know their size. However, the decoding of the resource itself, assuming there is enough memory to handle whatever is being decoded should not cause an out of memory exception. The more likley result is, depending on how frequently you need to decode resources, it will just slow your app down.
Have you considered using a cache? If you're decoding resources you could use a simple LRUcache as demonstrated in the android docs to avoid repeating this process. If you decode your resources as needed, store them to the cache, and then check the cache fore their presence before decoding again - you can probably save yourself a lot of time.
I have an application where I am generating many Bitmap objects. Once I create a bitmap, all the remaining bitmaps will be the same size.
Currently I can I load/create a new bitmap in about 50-80 ms on my phone, which works for what I need. However due to the rapid pace of creating these I am hitting constant GC.
I would like to re-use the same bitmap object, but am not sure how to do this through the sdk.
I did compile libjpeg and load my images through the NDK and re-use my bitmaps, however my loading speed dropped to about 200 ms, which is too slow.
I'll post code later when I have it in front of me.
Questions:
Is there a way to re-use my bitmap objects to avoid GC?
Is there a faster way to load my images through the NDK? Is it possible to hook in to the way the OS is loading the bitmaps? I know about libjpegTurbo, but I cannot get it to compile currently(another topic for another day).
Any other thoughts on the best way to do this.
Why not use a hashmap to store your bitmaps? Then when you load a bitmap, check to see if its in the hashmap first and if it is you can reuse it. If it is not in the hashmap, save it normally and then insert it into the hashmap.
I would recommend using IntBuffer(s) which contain the pixel data that you need to swap out. Then, create one bitmap of the size you need, and when you need to swap out the pixels, use bitmap.copyPixelsFromBuffer(). I imagine it will be MUCH faster than allocating/deallocating bitmap memory every time you need to change the pixel data. It might be a good idea to keep the buffers in a hashmap if you want to keep them in memory for quick retrieval.
Optionally you could use setPixels() with an array of int's. The nice thing about copyPixelsFromBuffer() is that no pixel conversion is attempted, and there are less options, so it might be a little faster.