The question is a bit of a throw off, as I don't mean disposing the screen itself. What I am using is an enum and switch statement to switch screens, rather than the Screen and Game classes. What I am really asking here is, when I switch from one game state to the other, am I supposed to dispose all of my disposables before hand? Or do I just keep all of them and not worry about it, despite not rendering them anymore since I'm rendering a separate screen? I'd find it annoying to have to dispose all the resources on my screen every single time I want to switch to another one, so I'm wondering if it's truly necessary.
It's your choice and type of your game(Is your game having many resources).
If having lots of resources then it's better to dispose resource of one screen then load resource of another screen in memory and after that use that resource.
In this scenario show loading screen and load resource asynchronously.
If don't having lots of resources, dispose resource only when you exit from your game. Inherited Game's dispose() is best place for dispose your game resource in this scenario and call screen dispose from here. so that screen specific resource can disposed.
Quick rules can be:
If you loading something (Texture, TextureAtlas, Music, Sound etc.) at application start and you do not have problem with memory heap - dispose it at application dispose method.
But if you loading something special for your screen at screen start you should dispose it in screen dispose method.
If you do not dispose resource for ex. Texture it will be still in memory even if you dont render it. When you loading some texture inside screen without dispose it inside screen dispose method, it maybe to cause a memory leak because you load same texture second time when you start your screen again.
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'm taking the AP computer science class at my school. They never taught us about GUIs because the AP test didn't require you to know how to make one.
For our final project we wanted to make something like tron (game where bikes move around an are creating walls of light behind them in an attempt to crash the other player). Before we continue i just want to make sure we are going in the right direction. Should we use ImageIcon for the players or maybe something else?
We still have a lot to learn, but i thought this would be a good thing to start with. The reason why i'm asking is because i'm not sure if we would be able to move them without opening another window every time we want to move something.
This is probably a matter of opinion, but personally, I would use BufferedImage's as the primary image container.
The main reasons are:
They are easy to paint and easy to manipulate, you can actually draw onto them if you need to.
Loading a BufferedImage is done through ImageIO.read, it guarantees that the entire image is loaded before the read method returns and will throw an IOException if it can't read the image for some reason, which is better than ImageIcon which loads the image in a background thread and doesn't report errors if the image failed to load
Movement or placement of the images would be done, typically, by painting them onto an output Graphics context. This is (typically) done by overriding the paintComponent method of something that extends JComponent and using the passed Graphics context and Graphics#drawImage
Have a look at Performing Custom Painting, 2D Graphics and Reading/Loading an Image for more details
I have a GameScreen and after end of the level I set the screen back to GameScreen as a restart when user taps restart button. I do this this.setScreen(new GameScreen(game)); and before I do that line of code I dispose the screen itself, all the textures used in screen, font files and so on, everything except box2D (world because disposing it gives me native error and makes the game crash ). But even though I dispose assets before I set screen game still crashes after 15-20 restarts.
I have analyzed the memory usage by printing JavaHeap, and found out that the momory usage increases in every restart until certain point and then gets back to low point like this:
- Restart1: 10MB
- Restart2: 13MB
- Restart3: 15MB
- Restart4: 10MB
- Restart5: 11MB
- Restart6: 14MB
- Restart7: 9MB
I have read about memory usage and found out that this kind of behavior is normal. But still my game crashes after few restarts without even giving error message.
What could be causing this?
EDIT: I tested the game on ZTE Blade and found out that the game gets slower by every reset, but still crashes in around 15-20 resets.
The memory up and down pattern is standard for garbage collection, you only have to worry if it starts being unable to reach the previous low point after a garbage collection as that would indicate a memory leak. It sounds like there might be something you aren't disposing of but why are you disposing anything if you are just going to reload all the same assets?
Switch to using the AssetManager. If you call AssetManager.load in your Screen constructor, AssetManager.finishLoading in your Screen.show method and AssetManager.unload in your Screen.hide method you should never unload any of your GameScreen assets because of how AssetManager does reference counting and you would only unload those assets if you navigated to a different screen. Don't forget to call `AssetManager.update in your render method.
You probably have solved your problem somehow since it has been almost a year but I will just put this here anyway, hopefully it may help people who are looking for solutions to this kind of errors.
I have a similar mechanism for one of my applications and I experienced a native crash with Box2d world too. It was when I used setScreen(new GameScreen(game)) after disposing the original one.
I used to have the following kind of initialization:
public class GameScreen implements Screen {
/*Global Variables*/
...
final private static World world = new World(new Vector2(0, 0), true); //Create a world with no gravity;
...
public GameScreen(SGM game){...}
It turned out that I have to initialize world in the constructor. Now I have the following working without any crash no matter how many times I dispose and recreate it:
public class GameScreen implements Screen {
/*Global Variables*/
...
final private static World world;
...
public MatchScreen(SGM game){
this.game = game;
world = new World(new Vector2(0, 0), true); //Create a world with no gravity
I'm not sure if that was also the cause in your case but well, it's just another suggestion.
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();
}