What is the most efficient way to sleep in libGDX. In Windows there is a way to tell an application to wait for a signal from the OS to continue so that the program doesn't have to spin for a certain amount of time. Does anyone know what this is called? But more specifically does an efficient way to do this exist in libGDX or Java? I am looking to make my application have as low footprint as possible.
You can set non-continuous rendering so it only draws OpenGL frames when you explicitly request them. This could save a lot of battery if your game occasionally has a completely static screen. Call this, and the graphics will freeze:
Gdx.graphics.setContinuousRendering(false);
While in this mode, render() is only called when you call Gdx.graphics.requestRendering();. So you can put something like this right at the end of your render() method:
boolean shouldRender = (!animationsAreComplete || userJustTouchedScreen);
if (shouldRender) Gdx.graphics.requestRendering();
You can turn continous rendering back on at any time.
Related
In Libgdx in my game I have bodies that enter my camera viewport and then exit the viewport and never return. Is it better for memory management to destroy these bodies and remove them from Arrays or sleep them?
It depends on the situation.
If you're asking what is generally the best? --- Reusage
When you reuse them, they will not stack up outside of the viewport, you won't need to create new bodies, and GarbageCollector won't need to collect anything.
But as I said, it depends on application. Mabye for your app letting them sleep there would be sufficient.
I want to capture the screen. Libgdx provides some functions defined in the ScreenUtils class.
For instance final Pixmap pixmap = ScreenUtils.getFrameBufferPixmap(x, y, w, h);
My problem is that it takes about 1-3 seconds to get that information. During that time the game loop is blocked and the user will define it as a lag.
Internally the ScreenUtils class, uses Gdx.gl.glReadPixels. If I run the ScreenUtils.getFrameBufferPixmap method in a thread, there is no lag, but it captures the screen at the wrong method, which is logical since the game loop runs and changes stuff.
Is it somehow possible to copy the GL context or save it and generate the Pixmap at a later point of time with the help of a Thread? Of course the copy/save operation should be done instantly, otherwise I don't spare anything.
I use ShapeRenderer to render my stuff onto the screen.
After little research I have found faster alternative to glReadPixels - Pixel Buffer Object which is available since Android 4.3 - https://vec.io/posts/faster-alternatives-to-glreadpixels-and-glteximage2d-in-opengl-es
It is not possible to call glReadPixels on other thread than render thread - https://stackoverflow.com/a/19975386/2158970
I have found a solution, which works in my case since I have only minor graphics / shapes. Basically I copy all the objects, which are drawn to the view, as described here. In a background thread I generate a Bitmap programmatically and use the information stored in my objects to draw to the bitmap.
I am trying to make an OpenGL game which has say 3 stages: Welcome, Battle and Armor. Each stage has different logic and works with different textures.
When is the best time to load those textures, all in the beginning, or load the ones that are used by each stage when it is activated. If so, should I then delete them when switching to another stage?
If the second method is best, how can I show static splash screen (image) while loading the textures per each stage?
Well, loading texture (especially from the sd card) can take time. The reason to load them before you need them is to avoid having a loading screen between stages. If the player will often switch between stages, and your texture are not so big, you might want to load them at startup (giving the pain of waiting for the game to load only once, even if it would be longer). You have to balance your choice between the memory that is available for you, and how much you want to piss the player by interrupting him in his playing experience.
You could also distract the player by displaying a scoreboard at the end of a stage to show him how good he's just been, instead of a loading bar.
If you can anticipate when the player will soon switch to another stage, you can try to stream the texture in background a little before, but it's a lot more complicated to do (well, especially on a mobile platform), so you'd need to do some research for that.
I think you should load them only if they are needed for that stage. Why waste memory by loading textures on your Video RAM if the player may not make it to the next stage?
You can show a dialog which is custom to your needs and dismiss it when you are ready. I don't have any samples right now.
I'm porting a really old AWT game to a really naff new device.
The game has a whole bunch of things wrong with it, including a very lax approach to thread safety: the game engine is trying to draw directly onto the screen in its engine thread using a graphics context it got from the UI thread. This doesn't work on the device.
I've managed to hack it into working, by having the engine thread draw onto an off-screen buffer and then have the UI thread periodically call repaint() on the display component and the display component blitting the buffer onto the screen, but performance sucks --- not surprising given all the context switches and double buffering.
I'm not actually a particularly knowlegable AWT programmer; it's sufficiently hateful that I've avoided it up to now. But this problem --- having an engine thread want to draw onto the screen --- must be a common one. Does anyone know of any decent strategies (and preferably example code!) of how to do this in a safe manner that squeezes as much performance out of the system as possible?
(What I'd particularly like is a safe shortcut to allow the engine thread to directly render onto the screen graphics context when it feels ready to do so, and so avoid having to tell the UI thread to request a redraw. That will let me take out a whole layer of double-buffering. But I don't know whether such a thing is possible...)
This is all on PBP 1.1.2 --- yes, it's neither full Java nor honest MidP...
Using a game canvas might help. It allows the painting to be done in the game loop, so you wont need double buffering. Another more crude approach is to use paintImmediately(). It will force the gui to repaint.
//Gui
public void update(/*may want to pass the shapes to paint*/)
{
paintImmediately(this.getGrphics()); // assuming 'this' is a jpanel
}
//Game loop
public void gameLoop()
{
// collision detection etc
gui.update();
}
I was programming a simple game and wanted to display it via the Java Graphics + Swing API. It felt a little slow, of course, so I measured how long it took to repaint, which was around 32ms. Then I read about accelerated Java graphics and used the method described here: Space Invaders
However, somehow this is even slower. It now takes around 98ms to redraw. Why is that?
Note that I am aware of libraries like LWGL and JOGL, but I don't want to use a full-blown OpenGL wrapper for such a graphically simple game.
A few hints to improve performance:
Clip and just draw the area that has changed
Don't scale anything when drawing
Use the correct buffer strategy
Use full screen exclusive mode if appropriate.
Swing isn't inherently slow. Most of the confusion about Swing comes from people who don't know or understand about the Event Dispatch Thread (and yes, it's a lot of effort to get it right).
Regarding your times, are you just calling g.drawImage between the time settings? If so, what size are you repainting, and are you doing any scaling on this call?
EDIT: Forgot to mention Pulp Core - a very nice gaming framework for Java.
Read this about timers
Use an always sleeping thread in the background to lower the system interrupt rate to get much more precise timers!
You can take a look at my code in here
A small game I've created can be found here
long renderStart = System.nanoTime()
// render stuff here
long renderTime = (System.nanoTime() - renderStart) / 1000000;
Swing will be slow for a game. Your best bet is probably an SDL wrapper, such as jsdl or sdljava. SDL is quite lightweight and supported on many platforms.
The nice thing is, well-implemented 2d graphics library wrappers implement the Graphics interface, so you should be able to try several and see which one performs best for your app without modifying your code.
I am not an expert, but Java2D supports different rendering pipelines. On my machine, switching to the OpenGL one by setting the system property
sun.java2d.opengl=true
yielded a substantial increase in rendering speed.
You may look at processing.
I agree with Nicolas, for graphics / interactivity processing is great
Try JGame. It's a simple engine for 2D games which uses GL when its available and can produce games that run on anything from a mobile phone to a desktop system.
First of all, you should check and see how much time is spent in your own code vs. how much time is spent actually drawing the frame. You may have some bug or glitch that makes it run more slowly.
You should be able to get much better performance then 98ms to draw your screen. Those game libraries will probably be using the same graphics calls as you would. But which containers you use can have a big impact on how fast things draw. I remember a couple months ago working on some double buffered graphics code, and how the back buffer was created made a huge difference in performance.
In particular, make sure you only create background image once or at least, only when your canvas resizes. In my draw code I do this:
//create a graphics backplane
if(backplane == null || !backplaneSize.equals(this.getSize())){
backplane = this.createImage((int)this.getSize().getWidth(), (int)this.getSize().getHeight());
backplaneSize = this.getSize();
}
So the back plane only gets created if it's new, or if the component is resized. This has a huge impact on speed.
I've been doing graphics programming in java since JDK 1.0. Actually I'd never heard of this BufferStrategy thing. Heh.
I've never had any trouble getting good frame rates with basic java graphics calls. Another thing to look out for is making sure that Swing isn't trying to clear the background of your component for you. That can be another source of slowdown.
Java2D performance is a bit of a dark art. It can vary between platforms, but it possible to get it to perform well.
Sometimes doing seemingly innocuous things can result in much slower performance. You want to make sure that you are using accelerated images as much as possible.
The type of the image can also be significant. I don't know the full details, but I do know that my programs were much faster using type 1 images (INT RGB) than other types such as type 5 (3BYTE BGR) because of conversion issues.
I can't tell exactly what you are doing. Your question is about Swing but you mention a Canvas and Bufferstrategy. Well in Swing you would use a JPanel which is automatically double buffered so you don't have to worry about that.
I tested a simple animation with 1000 moving balls. The Timer was set to fire every 100ms. When the Timer fired, the 1000 ball where randomly moved to a new position and a new BufferedImage was created and the panel displaying the image was repainted. The difference in time between the repainting was 110ms implying it only took 10ms to create an new BufferedImage and do the painting. The painting was done a a full screen so no clipping was done.
This posting show the example code I tested.