I'm making a game which has changeable graphics. I have large pixmap and I'm making texture out of it which I'm rendering on screen. And that works well, except that every time I want to change texture I'm actually updating the pixmap and making texture out of it and it's super slow. Those holes are made by explosions and sometime I have like 20 explosions in short period of time and lag is noticeable.
So, I'm drawing empty circle in my pixmap and then I'm making new texture out of changed pixmap and destroying old texture.
Is there a faster way to change a texture? I don't see that texture class has some drawing functions at all?
Can I somehow draw a hole (empty circle) in texture directly?
Everything you applied seems ok but I think you don't need create new texture and destroy old one. There is a good tutorial here about modifying textures using pixmap :
http://blog.gemserk.com/2012/01/04/modifying-textures-using-libgdx-pixmap-in-runtime-explained/
They implemented a PixmapHelper class that modifies pixmap by putting hole's on it calling "fillCircle" method of Pixmap as you want.
Texture has been created in constructor using Pixmap and not refreshed with any new Pixmap data after erasing circular areas.
Use the FrameBuffer class for drawing to a texture quickly. You instantiate it with the texture dimensions you want. To draw to it, call frameBuffer.begin(), then optionally gl.glClear(/*...*/);, and then draw to it as you would normally draw to the screen, finishing with a call to frameBuffer.end(). To use the texture, use frameBuffer.getColorBufferTexture().
Thank you both guys, but I was searching for easiest solution possible (that's why I'm libGDX anyway).
#Fuat, It's true, I don't have create new texture for every drawing (hole), but creating and destroying texture is not that expensive operation. Most expensive is moving whole pixmap to texture (large area). My solution that gives me excellent results and it's pretty easy is:
I'm drawing a hole (circle) at large pixmap as before.
I'm creating a temporary small pixmap, large enough just to take size of explosion (hole).
I'm copying part that was changed by hole drawing from large pixmap to small temporary one.
I'm drawing small pixmap to texture - much, much faster than drawing original, large texture. That's the crucial thing. Copying large pixmap to texture even without creating texutre again is most expesive operation. With small pixmap it's different story.
Disposing temporary pixmap.
And it works perfectly smooth now! Thanks for ideas anyway.
Hope, this will help someone too.
Related
In my game,I am planning to use Pixmap for drawing rectangle.Game logic is based on changing the size,angle,position etc of this rectangle object in a dynamic way.
Will Pixmap create any performance issues to the android game when I use it to implement the main game logic?
I have to change the properties of the rectangle object created by the pixmap frequently .Then how it will affect the entire game performance?
Do I have to find some other way to implement my requirements?Is it worth using Pixmaps ?
How it will differ if use sprite scale and rotation etc to manipulate image instead of using Pixmap?
According to your requirement As I think you have number of Rectangle. So create number of Sprite because one texture can be shared with number of Sprite.
Create one Texture and share with all of your Sprite(Rectangular object). Do your required manipulation on Sprite like color, size, rotation, scale.
And keep in mind :-
As a Pixmap resides in native heap memory it must be disposed of by calling dispose() when no longer needed to prevent memory leaks.
Is it possible/practical to get a pixmap from a modal;
ie;
ModelInstance >> Material >> Pixmap
possible? insane?
In short;
If I have a arbitrary basic textured quad, with one node, one material, one texture can I can a pixmap (with alpha) of that texture in some way?
Usecase:
I have a game with pickupable items. These objects are represented in the (essentially 3d) game world by textured quads.
To represent picking up, I was going to change the mouse cursor - which is already manually controlled by a sprite layer rendered ontop of the model layer
It would be useful to be able to thus get the image of the object being picked up so I can quickly just add a little arrow to it and use that.
I suspect the answer is "cant be done", or at least not without some ott render-offscreen business.
Now, one workaround I know is just to remember where the image resource originally came from and recreate it for the pixmap.
Before doing that, just want to ensure I am not missing something.
Thanks,
Thomas
Additional note; These images are quite small - 100x100 alpha, no more then one being picked up at a time occasionally. Performance thus isn't much of a concern.
I'm trying to draw shapes in libgdx that change constantly so I don't think using sprites will work, and I was wondering if it is possible to draw a shape using a function that is called for each pixel to determine if it should be drawn.
What I need to draw is part of a washer (an area bound by two concentric circles and two radiuses), with the circles and radiuses changing constantly.
What I want to know is wether here is a way to draw complex shapes that are determined by a function (the shape would consist of those (x,y) for wich theFunction(x,y)=true) instead of an image
Everything is possible. The best solution really depends on the details of what you want to create. Perhaps you can show an example of what you mean?
Without seeing an example, it looks you might want to start with ShapeRenderer. See the javadocs for detailed information on how to use it. That should get you started and if you find it to be insufficient in some way then you at least you have a more specific question.
Btw, using a Pixmap as suggested by #Ludevik is also possible, but since you want it to change constantly that would imply uploading the entire image each frame which is not very performant.
Would use of Pixmap help?
You can create a pixmap:
Pixmap pixmap = new Pixmap(300, 300, Pixmap.Format.RGBA8888);
and then draw pixels with specific color on that pixmap:
pixmap.drawPixel(x, y, color);
Then you can then create a texture from that pixmap and draw the texture. I'm not sure about the performance of such solution though.
See also Pixmaps in the libgdx wiki.
I'm writing a client for a multiplayer tile-based game in libGDX (for Android and Desktop).
The game world is composed of thousands of small 32x32 png images that are drawn into a large rectangular view area. The images are downloaded over the socket connection (network) as needed.
What is the best (fastest and most resource-efficient) way to store these images in "memory" so they can be drawn really fast onto the screen when needed?
So far, I have implemented a very naive algorithm that will load each and every 32x32 image into a Texture and keep that in memory indefinitly. (Pure coincidence my images got a size that is a power of two.) It seems to work, but I am worried that this is very inefficient and possible exceeds GPU resources on older devices or something.
I am aware of the TextureAtlas, but that seems to work only for static images that are packed and stored in the compiled android app. As I receive my images over the network dynamically, I believe this won't work for me.
I have found this libgdx SpriteBatch render to texture post that suggest rendering many small images into a FrameBuffer, then using this as a source of TextureRegions. This seems promising to me. Is this a good solution?
Is there a better way?
I also wonder if drawing and storing my small images into a large Pixmap might be helpful. Is this possibly a better approach than drawing into a FrameBuffer, as described above?
As I understand it from the docs, Pixmaps are purely memory-based. That might be an advantage as it probably doesn't need graphics resources, on the other hand might be slower as loading into a Texture is an expensive operation. Thoughts on this?
Actually TextureAtlas is the best way to store many images (small or not) and fortunatelly the TextureAtlas instance do not have to be created in a static way.
Take a look at
addRegion(java.lang.String name, Texture texture, int x, int y, int width, int height)
TextureAtlas'es method. It make it possible to create atlas dynamically.
So what you should do is to create empty atlas
TextureAtlas atlas = new TextureAtlas();
then add your images in some kind of loop
for(Texture texture : yourTexturesCollection)
atlas.addRegion(...);
then you can use your atlas by using findRegion or another method (take a look at reference)
Notice that for android devices it is recommended to use not larger atlas than 2048 x 2048px.
For another kind of devices (like dekstop) this value can be another (usually bigger). It is not LibGDX limit but openGL's!
In my libGDX game I have several sprites that share the same texture. Now I want to "manually" draw onto some of the sprites (i.e. I want to change some of the pixels in some of the sprites).
How can I modify a texture that is shared amongst seveal sprites without affecting other sprites?
I guess I need to copy the texture before I set it to the sprite?
You can use custom shader to customize sprite texture.
Before drawing the sprite with spriteBatch, simply say:
spriteBatch.begin();
spriteBatch.useShader(shaderProgram1);
sprite1.draw(...);
spriteBatch.useShader(shaderProgram);
sprite2.draw(...);
...
spriteBatch.end();
If you aren't familiar with the shaders you can check this link:
https://github.com/libgdx/libgdx/wiki/Shaders
Also there is option to use frame buffer object, for texture customization, but I think if those texture difference aren't that huge, this is the best solution if you are looking for best performances.
Hope that this gives you an idea.