Ignore #1, BigImage#getScaledCopy does return a BigImage.
For #2, turns out it has nothing to do with the scaling. On my hardware, internally the BigImage uses a 2048x2048 texture to hold the 1920x1200 image. The part of the texture not occupied by the image is black, as demostrated here...
Code:
public class ThingleTest {
public static void main (String[] args) throws SlickException {
BasicGame game = new BasicGame("ThingleTest") {
Image testImage;
public void init (GameContainer container) throws SlickException {
testImage = new BigImage("title.png", Image.FILTER_LINEAR);
container.getGraphics().setBackground(Color.red);
}
public void update (GameContainer container, int delta) throws SlickException {
}
public void render (GameContainer container, Graphics g) throws SlickException {
g.drawImage(testImage, 100, -1100);
}
};
AppGameContainer container = new AppGameContainer(game);
container.setDisplayMode(600, 800, false);
container.start();
}
}
If I replace the drawImage call above with this...
Code:
g.drawImage(testImage, 100, 100, 100 + 384, 100 + 240, 0, 0, 1920, 1200);
...then internally it calls getSubImage which creates a new BigImage of the correct size, not 2048x2048, and is displayed correctly. The workaround I have for this bug then is this:
Code:
testImage = new BigImage("title.png", Image.FILTER_LINEAR);
testImage = testImage.getSubImage(0, 0, testImage.getWidth(), testImage.getHeight());
...then later...
testImage.draw(100, 100, 384, 240);
Interestingly, I don't think there is a performance gain by using getScaledCopy, which is why I was trying to use it. Is this true? I thought it might be draining to scale a 1920x1200 image down to 800x600 (for example) a hundred times or so per second.
Login
Register
FAQ
Search
