I'm using a ShapeRenderer object to create a color gradient in my game (Screen class). The allocated memory used to grow permanently until I started to dispose my ShapeRenderer object after every call. How can I reuse my color gradient? Is there a way to paint the gradient into a texture (only once for reuse in the render method)?
public void render(float deltaTime) {
camera.update();
batch.setProjectionMatrix(camera.combined);
ShapeRenderer shapeRenderer = new ShapeRenderer();
shapeRenderer.setProjectionMatrix(camera.combined);
shapeRenderer.begin(ShapeRenderer.ShapeType.Filled);
shapeRenderer.rect(0, 0, screenWidth, screenHeight, topColor, topColor, bottomColor, bottomColor);
shapeRenderer.end();
shapeRenderer.dispose();
batch.begin();
...
batch.end();
}
Although it seems you have solved your problem, here is just a little note for you and anyone stumbling across this post with a similar question.
Do not instantiate new Objects (of any type) during every run through a loop, at all costs. The reason you were experiencing slow-down is because of exactly this. Every time you instantiate a new object and then stop using it, the JVM's Garbage Collector needs to get rid of that Object. You should always try to reuse objects. This is why pools and memory management in general (these links are for LibGdx specificially) are so important.
Your notion to make a field for the ShapeRenderer was a good one, just don't forget to dispose() it in your game's dispose() method.
Related
I am trying to draw a Sprite but it just appears for a frame when I first run my program, and then immediately disappears. I am working with a Stage, a Tiled map and two Batches, which I hope is not a problem.
It pretty much looked like the sprite was hiding behind something else, but I made completely sure that nothing was being drawn after it. So after a long time messing around, I found out that deleting the setProjectionMatrix() method "solved" my problem, since the sprite showed perfectly somehow.
I don't understand the reason why this happened at all, and I don't want to just delete the method and have sprites following the camera around, so:
Why or how would a setProjectionMatrix() method "hide" a Sprite? Is it altering the order in which my sprites are drawing? And most importantly, how do I fix it?
Here's my render method:
public void render(float delta) {
Render.cleanScreen(); //Render is a class i made with useful static stuff, like the Batch i am using.
//This method is pretty much just a Gdx.gl.glClearColor() method.
tmr.setView(camera); // tileMapRenderer
tmr.render();
b2dr.render(world, camera.combined); // Box2DDebugRenderer
stage.act();
stage.draw();
Render.batch.begin();
sprite2.draw(Render.batch); //The sprite i want to draw
Render.batch.end();
hudBatch.begin();
sprite1.draw(hudBatch); //This works fine
hudBatch.end();
Render.batch.setProjectionMatrix(camera.combined);
Gdx.input.setInputProcessor(stage);
}
Edit: Someone asked for extra info, so:
• This is what my game looks like with the setProjectionMatrix (after the first frame when the Sprite dissapears) and this is what it looks when i delete it. You can clearly see the red square(the Sprite).
• I am currently using a FitViewport.
Stage.draw() calls apply() on the Stage's Viewport, but never restores the OpenGL Viewport to what it was before. I'm guessing that your stage uses FitViewport, so it is cropping part of the screen. If you want different viewport behavior for stuff you draw outside your stage, you should create a separate viewport for that, and call viewport.apply() before you start rendering the other stuff.
Side note: if you are lazy loading anything that uses native memory (like SpriteBatch and Texture, things implementing Disposable) and storing a reference in a static variable (your Render class), make sure you dispose all of it and null it out in your game's destroy() method. Otherwise, on Android you will be leaking that stuff and it will fail to work when you reopen your game.
Another side note: In my opinion, the Sprite class should not be used unless you have hundreds of them and they aren't moving much (in which case it might have slightly better performance). Sprite is a weird conflation of an asset (a TextureRegion) and game state data. As a result, it can create design issues that you have to work around, such as when you want to animate it or flip it. It is better to create your own GameObject class that references a TextureRegion (a single instance of which can be shared by many elements), and has its own variables for position, color, rotation, etc. Then draw it with the appropriate SpriteBatch.draw method using those properties. In my game, I have a wrapper interface around TextureRegion that can alternately wrap Animation<TextureRegion> so my GameObject class can use either and it can be swapped easily. This makes the code more flexible to change.
So... I just realized my coworker accidentally deleted the viewport.update() method.
#Override
public void resize(int width, int height) {
viewport.update(width, height);
}
Is LibGDX SpriteBatch draw() smart enough not to redraw 100% exactly same sprite at each render() call?
public void render(float delta) {
Gdx.gl.glClearColor(0, 0, 0, 1);
Gdx.gl.glClear(GL20.GL_COLOR_BUFFER_BIT);
if (shallFadeOut) { // becomes true when sound message finishes
doFadingOut();
showNextScreen();
dispose();
} else {
batch.begin();
// introSprite is a static image - it never changes a pixel (splash screen)
// I need to paint it once and then just wait until sound message finishes
// DON'T NEED TO REDRAW IT EVERY render() cycle 60 times/sec (~60 fpm)
introSprite.draw(batch);
batch.end();
}
}
In OpenGL, you typically redraw the whole screen on every frame. It doesn’t make sense to wonder if the batch is smart enough to avoid redrawing the same thing, because it has to redraw it to prevent it from disappearing.
If you want to avoid redrawing anything on the screen for a while to save battery on the device, you can use GDX.graphics.setContinuousRendering(false) but that means your render() method will stop getting called so you must set it back to true using a timer or input callback.
You could alternatively use a Boolean to decide whether to clear the screen with glClear and draw stuff, but under the hood, LibGDX will still be requesting OpenGL to copy the screen buffer data between the back buffer and the screen buffer.
Not that drawing a single sprite is super trivial and probably not worth a second of thought about optimizing it.
I am afraid that I do not think any accounting is done by the Batch between batching render steps to see if a texture was already loaded and is ready to be rendered, but the texture itself might.
The batching is intended for cases where you are drawing duplicates of the same thing in the same render step so that you are not unnecessarily context switching between sprites and having to reload data to your graphics card.
The batch is as I am sure you know defined by the begin and end calls you are using, and it depends on you actually rendering all of the sprites of a particular type one after the other without jumping to render something else. This can be seen int he batch draw code here, but for readability the relevant lines are below:
Texture texture = region.texture;
if (texture != lastTexture) {
switchTexture(texture);
} else if (idx == vertices.length) {
flush();
}
To take advantage of the batch - you should be grouping the rendering of all your sprite types, and between steps, the batch does not offer any efficiencies by design as far as I can tell.
But, between batching steps or game loops, when a texture is bound, it uses a fixed target and handle as can be seen here. This means that if all you are drawing is a single sprite for several render loops, libgdx should be using your memory and graphics card as efficiently as can be expected.
It's been a while since I used LibGdx, so I feel like I'm just missing something obvious.
My render method in MyGdxGame looks like this, calling for the stage to draw itself (along with its actors), and then I try to draw a set of textures for debugging purposes.
#Override
public void render()
{
Gdx.gl.glClearColor(1, 1, 1, 1);
Gdx.gl.glClear(GL20.GL_COLOR_BUFFER_BIT);
StageManager.getCurrentStage().act();
spriteBatch.begin();
StageManager.getCurrentStage().draw();
for(int i = 0; i < 100; i++)
{
spriteBatch.draw(TextureManager.getPlayerTexture(), 50*i, 50*i);
}
}
The stage is drawn along with its one actor, but the other textures are not being drawn.
What I've tried: setting batch projection matrix off the stage camera(after calling update), making sure the texture coordinates should be visible.
The actor gets its texture from the same TextureManager.getPlayerTexture so I don't think its a texture issue.
What else should I check for to get the textures drawn as well?
Normally, your code would have caused a RuntimeException, because you're calling begin on the batch before drawing the stage. But since you actually have two sprite batches (one internal to the Stage because you didn't share the original with it), no actual errors occur.
You're missing a call to spriteBatch.end() after drawing your texture(s). And the call to spriteBatch.begin() needs to move after stage.draw().
And you should pass that sprite batch into the Stage constructor, because it is wasteful to have more than one sprite batch. Each sprite batch uses a fair amount of memory and compiles a shader.
I am making a Java game, and the game lags a lot when I paint out the graphics.
The way I am currently painting out the graphics is to make a BufferedImage, get the Graphics2D from it, then do a whole bunch of:
g2d.drawImage(loadedImages.getImage(),x,y,null);
After I print all of the images to the BufferedImage, I paint the BufferedImage to the screen.
There are a lot of images I paint to the BufferedImage. Is there a better way to do this that would speed up the painting time?
I do not know much about graphics and graphic cards. Should I use a graphics card? Should I paint directly to the screen? Should I use something entirely different than drawImage()?
The performance should be good if you're drawing a reasonable amount of images.
Make sure you're not creating new BufferedImages every time you draw to the screen. For example, you might have a Resources singleton in which you manage all of your images so that you only load and unload each image once.
If you really want more performance, you'll want to use OpenGL. See LWJGL, libgdx, or JOGL. You may also want to consider 2D graphics libraries like Slick.
I've found it useful to extend java.awt.Canvas and use
BufferStrategy bs;
void init() {
createBufferStrategy(2);// or 3 for triple-buffering
bs = getBufferStrategy();
}
and then the actual draw() method looks like
void draw() {
Graphics g = bs.getDrawGraphics();
g.drawImage(image, x, y, w, h, null);
// Draw more things here...
// You can also make calls like `myObject.draw(g)` and whatever
// you draw onto `g` within those calls will show up.
bs.show();
g.dispose();
}
This is what I use for drawing a lot of things. And then within each myObject.draw(g) call, there are sometimes multiple other similar calls all chained up. Most often my main draw() method has one or two for loops in it that just say for(Entity e: entities) e.draw(g); or something similar. Then the whole drawing chain is kicked off from there.
I realize most of the Java code to overwritten paint or paintComponent, most of them doesn't restore the old state of graphics object, after they had change the state of graphics object. For example, setStroke, setRenderingHint...
I was wondering whether it is a good practice that we restore back the old state of graphics object, before returning from the method. For example
public void paintComponent(Graphics g) {
super.paintComponet(g);
Stroke oldStroke = g.getStroke();
g.setStroke(newStroke);
// Do drawing operation.
g.setStroke(oldStroke);
}
Is this a good practice? Or it is over done?
You should not alter the Graphics object passed in at all, rather perform all your graphics operations on a copy of it which you then dispose. There'll be no need to reset the state at all then.
public void paintComponent(Graphics g1) {
super.paintComponent(g1);
final Graphics2D g = (Graphics2D)g1.create();
try {
// ...Whole lotta drawing code...
} finally {
g.dispose();
}
}
Yes, this is a very good practice to follow. You don't pay much in performance (relative to the actual painting operation), and you save yourself a mess of grief if you're making unusual changes to the graphics context. Don't overdo it though -- you probably don't need to worry about color settings, for example.
The alternative is to assume nothing about the graphics context, and set all the necessary properties before every painting, in case they're set to something wonky. Try to avoid freely creating and disposing Graphics objects for every operation.
Specific properties you should always restore if modified: (because they can do Bad Things and have Unexpected Consequences):
Transform - because modifications to this will stack on top of each other and get very, very hard to reset. Beware: this is modified by the translate, shear, scale, rotate, and transform methods of Graphics2D. Modifying transforms should be used with CAUTION.
Stroke -- because (at least in my configuration), leaving this default runs much faster than any setting even if equivalent to default. Don't ask -- it's a result of the Java2D graphics pipelines accelerating the default case using graphics hardware.
Clip: will result in weird bugs where only part of the screen draws.
Composite: most operations probably don't expect this to be something weird.
Properties to not worry about:
RenderingHints. These are things you can easy set and restore, and generally you want to leave them set a certain way (antialiasing on, etc) for the whole time the app is running. Changing RenderingHints will rarely break rendering of components, although it might make it uglier.
Background color and paint color. Most things will modify these before drawing anyway.
Font: likewise.