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.
Related
People usually write "draw(SpriteBatch batch)" and "update(float deltaTime)" methods in their player classes. Why don't they just write "render(SpriteBatch batch, float deltaTime)"? Because of readability? I mean, why they make two methods? They can do in single method.
Readability and ease of updating/changing is one reason.
But there are also logistical reasons. You want to be sure your whole game state is fully up to date before you start drawing, so whatever is on screen is as up-to-date as possible. If you put updating and rendering into one method for each object, then objects that are updated and drawn first might look out of date compared to objects that are updated later and affect the state of the earlier objects. But if updating and drawing are separated, you can update the entire game and then draw the entire game.
And if your game uses physics, the separation of updating and drawing allows you to update your world at a fixed timestep (at a different rate as the drawing) to ensure the game play is not affected by frame rate.
That's because you want to seperate between your game logic and your render function. It's easier to read and also helps if you want to update your game logic more often than your render logic.
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.
To start with,I am pretty new to 3D programming and libgdx.
I looked at a few tutorials and I already render the scene I want. I have some 1x1x1 blocks, created with ModelBuilder.createRect() for every visible face, so if another block covers a face of this block, there is no rect created for this block. Also the top and bottom rect is not needed, as I can never see them (except for the floor). So I thought, that this is pretty efficient. I also have Backface culling enabled and I do Viewfrustum culling. However, if I look in a direction, where many blocks are in my viewfrustum the FPS go down to 15-20. This is still okay for me, as my laptop is over 5 years old and its performance is not the best, but this answer made me think.
"ModelBuilder is used for debug only". Okay, but how should i then create my boxes? Why should i create a Model in a Modeling app (like Blender), for simple squares? By doing this i couldn't even cull the faces, which are occupied by other blocks.
So my question is:
How can i create and render those boxes the most efficient way?
ModelBuilder#createRect will create a new model for each rectangle. When rendering a (part of a) model instance, it implies a draw call. Therefor ModelBuilder#createRect is extremely inefficient. It is better to combine multiple rectangle into a single (part of a) Model. This can be done using:
modelBuilder.begin();
MeshPartBuilder mpb = modelBuilder.part(....);
mpb.rect(...); // first rect.
mpb.rect(...); // second rect.
// etc.
Model model = modelBuilder.end();
Note that this is still not efficient enough for e.g. a voxel engine. If you are aiming to optimize for voxels, you'll probably want to build the mesh (after frustum culling and depth sorting) in a custom RenderableProvider. Here's an example: https://github.com/libgdx/libgdx/tree/master/tests/gdx-tests/src/com/badlogic/gdx/tests/g3d/voxel
I have a big problem with the drawing in LibGDX. First I don´t use every physics or other complicate things in my game. I only draw sprites and put Rectangles at this for Collision Detection. I have 3 Screens in my game: splash, menu and game. So I use a Stage in the splash and menu screen but I don´t really if I use Stage in the game too or I draw with SpriteBatch? The Stage have really pros with Actions but it a little bit more complicate to use Actors. Are there other ways to do this? I don´t want to use World, because its to complicate for the beginning of game developing.
What I want to use for the game?
Actually you always draw with SpriteBatch, as Stage uses its own SpriteBatch. If you think you could need some of the advantages of Scene2ds Stage, like Actions, Groups or other things, you should use Stage. In my opinion it is really easy to use. You have your own objects, which extend Image or Actor, override their update(delta) methods, where you check if the Actor should move (Keypressed or an event for the AI). Also you should detect collisions there and take care about them. Then, if you are extending Image you don't need to care about drawing (but Image needs Drawables so you will have some problems with Animations), if you are extending Actor override the draw(SpriteBatch batch), where you call batch.draw(...).
Thats it.
A big disadvantage of Stage is the sorting. The Actor, which is drawn as first is in the background. The last Actor overdraws all others and is in foreground. You can sort them by using the z-Index, but it is not really sure.
So you may decide to use your own kind of Stage (it is more or less a list, containing all Actors, and when updateor draw is called, it is called for every Actor in this list), and add your own sorting there.
It depends on your game design, on your opinion and on your style. Look at some tutorials/examples and decide how you want to create your game.
You can use either, it depends on what kind of game are you creating. But anyway, don't create multiple instances of SpriteBatch — instead create only one and pass it to Stage constructor, because it's heavy object. (Yes, Stage uses a SpriteBatch under the hood)
Also, Stage may be extremely useful if you need any on-screen controls (buttons, joystick, etc), because you can use classes from scene2d.ui and don't reinvent the wheel (some wheels are not very easy to reinvent properly)
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();
}