Slick Forums

Discuss the Slick 2D Library
It is currently Sat May 25, 2013 12:18 pm

All times are UTC




Post new topic Reply to topic  [ 4 posts ] 
Author Message
PostPosted: Tue Jun 12, 2012 1:48 pm 
Offline

Joined: Wed Jun 06, 2012 12:40 pm
Posts: 2
Hello everyone.

I'm developing a tile-based strategy game and one of the options I'm hoping to implement is the change of the game's resolution during gameplay/runtime, thru an graphics section in my options menu.

The method I'm currently using is to set the AppGameContainer as a static global, but i think it's a very faulty method (and just plainly the wrong way to do it).

Is there a way to do runtime resolution-change with the ScalableGame class or something with the same functionality? How can i do it?

==========

[Criticism/Suggestion]

@kevglass

Kev,
I don't mean it in a bad way, but I'll be sincere in the way i say it...

Why is resolution-setting only available at the very first class to implement? Or more specifically, why is it not available for the GameContainer?

My point is (and again, this is just what i think; my opinion.), for the current method i still have to implement a method to do rescaling and repositioning for every GUI element (button, label, etc), and the fact the class from with most other implementations derive is being set as a static global (wide open) leaves a lot of gaps.

On the other side, I'm looking at this magical, gold-shining ScalableGame class, that seems to have all the necessary functionality for input+visual scaling, and for maintaining aspect-ratio at that, just there and ready to go.

I mean, the code for runtime resolution-change is ready (AppGameContainer), and the code for scaling is ready too (ScalableGame), so why there is not any access to either functionality from the update()'s containers? I really can't understand... :|


Top
 Profile  
 
PostPosted: Tue Jun 12, 2012 4:46 pm 
Offline

Joined: Thu Jan 26, 2012 5:40 pm
Posts: 79
I'm not really sure what your issue is. Your gui elements should be laid out relatively rather than statically, using container.getWidth() and container.getHeight(), so if the container is resized those get updated as well.

I also use a public static AppGameContainer. But if you want that to be private, simply write a public static method with width/height/isFullScreen parameters in your class that initializes AppGameContainer.

For example,

Code:
public static void main(String[] argv) {
      try {
         container = new AppGameContainer(new MyGame(
               "My Game"));
         container.setDisplayMode(width, height, false);
         container.setVSync(true);
         container.setAlwaysRender(true);
         container.start();
      } catch (SlickException e) {
         e.printStackTrace();
      }
   }

   public static void setResolution(int width, int height, boolean isFullScreen) {
      try {
         container.setDisplayMode(width, height, isFullScreen);
      } catch (SlickException e) {
         e.printStackTrace();
      }
   }


Top
 Profile  
 
PostPosted: Tue Jun 12, 2012 11:06 pm 
Offline

Joined: Wed Jun 06, 2012 12:40 pm
Posts: 2
Well, I finnaly got a grasp of how to use the ScalableGame class.
Then again, @Kev, both the docs and the example code were painfully lacking on info regarding the resolution-change during runtime. "It will be done automatically" was something very far from my thoughts and at last for me, it made it VERY counter-intuitive to implement. :(

Well, that aside, it turns out all that is needed for the visual+input rescaling is to set the AppGameContainer with:
Code:
app = new AppGameContainer(new ScalableGame(new Main(), optimumWidth /*int*/, optimumHeight /*int*/, keepRatio /*Boolean*/));

Instead of:
Code:
app = new AppGameContainer(new Main());

And it will do the rescaling for me on every resolution-change, and all be happy for ever and ever; Or actually, until I push the "Exit" button and terminate the app...

I still have one issue tough; I get the visual+input combo under-scaled (smaller than the size of the window) if I setDisplayMode with values under those I've set as optimum for the ScalableGame.

==========

As for the changing of the resolution, the problem is exactly that, setting the new resolution.
Yes, I can define a public static method on the main, just as I'm doing to have access to the class; That's not the issue.
The issue is "Why does the GameContainer not have those directly accessible?", or, in a code example, why do I (we) have to use this:
Code:
public class State_OptionsMenu extends BasicGameState {
  /*...*/
  public void update(GameContainer container, StateBasedGame game, int delta) throws SlickException {
    /*...*/
    if (btn_PrevResolution.isMouseOver(mouseX, mouseY)) {
      if (input.isMousePressed(Input.MOUSE_LEFT_BUTTON)) {
        DisplayMode temp = getPrevResolution();
        Main.app.setDisplayMode(temp.getWidth(), temp.getHeight(), Display.isFullscreen()); //Or a call to a "do the same" public static method also @ the Main class.
      }
    }
    /*...*/
  }
  /*...*/
}

Instead of something like this:
Code:
public class State_OptionsMenu extends BasicGameState {
  /*...*/
  public void update(GameContainer container, StateBasedGame game, int delta) throws SlickException {
    /*...*/
    if (btn_PrevResolution.isMouseOver(mouseX, mouseY)) {
      if (input.isMousePressed(Input.MOUSE_LEFT_BUTTON)) {
        DisplayMode temp = getPrevResolution(); //Returns a DisplayMode with the next lower resolution, from the ones available.
        container.setDisplayMode(temp.getWidth(), temp.getHeight(), container.isFullscreen());
        /*Another option that is lacking, even on AppGameContainer, is to set the DisplayMode more directly. Like "container.setDisplayMode(getPrevResolution(), container.isFullscreen());"*/
      }
    }
    /*...*/
  }
  /*...*/
}

??? :?


Top
 Profile  
 
PostPosted: Wed Jun 13, 2012 12:14 am 
Offline
Slick Zombie

Joined: Sat Jan 27, 2007 7:10 pm
Posts: 1469
To clear a few things up:
  • Kevglass no longer maintains Slick (although he of course still has access if he decides to revisit it). The current devs came in (voluntarily) as an effort to keep slick "alive" -- fixing bugs as they appeared and introducing long-awaited enhancements.
  • Resolution changing was not included in the GameContainer interface because it is implemented differently for Applets (through JavaScript/HTML) and CanvasGameContainer (through JFrame).
  • Instead of using a public static AppGameContainer, you might rather use instanceof to determine the context (Canvas, Applet, Display, or what have you). Then take the appropriate action from there.
  • ScalableGame is "experimental" at best, and will prove buggy if you ever plan to write low level OpenGL or shaders. I personally wouldn't rely on it -- instead, if my game needed to maintain a particular aspect ratio independently of window size, I would use CanvasGameContainer. Quite often, though, you can get by fine with a fixed display and smart use of layouts.

Slick is open source. If you want to change it entirely, feel free to go ahead. :) And if you want better docs, you can submit those to the wiki or pull some code changes to bitbucket. Unfortunately there are only a few docs, and we have a limited amount of time to work on Slick.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 4 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group