Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (538)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (601)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  [LibGDX] Managing Screens  (Read 734 times)
0 Members and 1 Guest are viewing this topic.
Offline Gibbo3771
« Posted 2014-02-11 11:00:34 »

I am in two minds on how to handle this, I am working on a little manager class that controls game state and screens and just wondering if it is a bad idea to keep screens in memory?

Basically if the user clicks play on the main menu, game state changes and screen is changed to play, but main menu is kept in memory for later.

Is this a bad idea? Should I just init the screen all over again? Obviously the game screen would have to be recreated or else it would start off at wherever the game was last.

But is it ok to keep a reference to other screens?

"This code works flawlessly first time and exactly how I wanted it"
Said no programmer ever
Offline Grunnt

JGO Kernel


Medals: 95
Projects: 8
Exp: 5 years


Complex != complicated


« Reply #1 - Posted 2014-02-11 11:15:10 »

I am in two minds on how to handle this, I am working on a little manager class that controls game state and screens and just wondering if it is a bad idea to keep screens in memory?

There is no probem with that as long as your screens do not do something exceptional that requires a huge load of memory. Just don´t update them. I use a Stack of screens in which I just update the topmost one. Its nice & simple, and works like a charm.

Offline Gibbo3771
« Reply #2 - Posted 2014-02-11 11:17:28 »

I am in two minds on how to handle this, I am working on a little manager class that controls game state and screens and just wondering if it is a bad idea to keep screens in memory?

There is no probem with that as long as your screens do not do something exceptional that requires a huge load of memory. Just don´t update them. I use a Stack of screens in which I just update the topmost one. Its nice & simple, and works like a charm.


Hm right at the moment I only have 3 screens, MainMenu, Options and Play. They will be stored within a nested inner class in the Manager class, any other way you recommend in doing this?

I simply pass the Manager into pretty much every constructor that requires it, so anything that can alter the game state or screen.

"This code works flawlessly first time and exactly how I wanted it"
Said no programmer ever
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Grunnt

JGO Kernel


Medals: 95
Projects: 8
Exp: 5 years


Complex != complicated


« Reply #3 - Posted 2014-02-11 11:34:28 »

Here's rougly what I did (dont have the code with me right now, so its much simplified):
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
public class Game {
   public Stack<AbstractScreen> screens

   public void update(float delta){
      screens.peek().update(delta);
   }

        public void init(){
      screens.push(new MenuScreen());
        }
}

public abstract class AbstractScreen {
   protected Game game;

   public AbstractScreen(Game game) {
      this.game = game;
   }
   
   public abstract void update(float delta);
}

public class MenuScreen extends AbstractScreen {
 
   // ... constructor stuff

   public void update(float delta){
      if (playButtonIsPressed){
         GameScreen gameScreen = new GameScreen();
         game.screens.push(gameScreen);
      }
   }
}


So essentially any screen that is pushed on top is instantiated anew, and any screen that is deactivated is removed from the stack and garbage collected. Try to design your game in such a way that screens do not (or as little as possible) reference to each other.

Best make the screens in seperate files / classes, and not as inner classes; its much easier to keep an overview this way instead of when you put everything in one Huge Messy Class.

Offline Gibbo3771
« Reply #4 - Posted 2014-02-11 11:51:11 »

Here's rougly what I did (dont have the code with me right now, so its much simplified):
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
public class Game {
   public Stack<AbstractScreen> screens

   public void update(float delta){
      screens.peek().update(delta);
   }

        public void init(){
      screens.push(new MenuScreen());
        }
}

public abstract class AbstractScreen {
   protected Game game;

   public AbstractScreen(Game game) {
      this.game = game;
   }
   
   public abstract void update(float delta);
}

public class MenuScreen extends AbstractScreen {
 
   // ... constructor stuff

   public void update(float delta){
      if (playButtonIsPressed){
         GameScreen gameScreen = new GameScreen();
         game.screens.push(gameScreen);
      }
   }
}


So essentially any screen that is pushed on top is instantiated anew, and any screen that is deactivated is removed from the stack and garbage collected. Try to design your game in such a way that screens do not (or as little as possible) reference to each other.

Best make the screens in seperate files / classes, and not as inner classes; its much easier to keep an overview this way instead of when you put everything in one Huge Messy Class.

Yeah my screens are in seperate classes but the Manager class has a ScreenManager class nested inside it that simply holds reference to the screens.


"This code works flawlessly first time and exactly how I wanted it"
Said no programmer ever
Offline Grunnt

JGO Kernel


Medals: 95
Projects: 8
Exp: 5 years


Complex != complicated


« Reply #5 - Posted 2014-02-11 11:58:35 »

Yeah my screens are in seperate classes but the Manager class has a ScreenManager class nested inside it that simply holds reference to the screens.

Ah cool, then we're takking pretty much the same approach.

Offline Gibbo3771
« Reply #6 - Posted 2014-02-11 12:05:59 »

Yeah my screens are in seperate classes but the Manager class has a ScreenManager class nested inside it that simply holds reference to the screens.

Ah cool, then we're takking pretty much the same approach.

Yeah looks like it, only problem with this is that my main menu and stuff will have animations so I will have to reset everything, probably faster trashing it and re-creating it lol.

"This code works flawlessly first time and exactly how I wanted it"
Said no programmer ever
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

rwatson462 (29 views)
2014-12-15 09:26:44

Mr.CodeIt (20 views)
2014-12-14 19:50:38

BurntPizza (42 views)
2014-12-09 22:41:13

BurntPizza (76 views)
2014-12-08 04:46:31

JscottyBieshaar (37 views)
2014-12-05 12:39:02

SHC (50 views)
2014-12-03 16:27:13

CopyableCougar4 (47 views)
2014-11-29 21:32:03

toopeicgaming1999 (114 views)
2014-11-26 15:22:04

toopeicgaming1999 (102 views)
2014-11-26 15:20:36

toopeicgaming1999 (30 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!