Slick Forums

Hi folks,

I'm writing a StateBasedGame and everything works so far. Now I tried to keep the aspect ratio independent from the screen resolution.
As Slick is based on OpenGL I supposed I could do the following to map an internal 512x384 resolution to an arbitrary screen resolution (speak 0/0 is at the top-left of the window and 512/384 is at the bottom right of the given window):



This scales the TiledMap and the Shapes I draw to the window as expected, using OpenGL to scale everything with hardware acceleration.
The only problem I've got is that Animations simply won't display anymore.
Is there possibly a Slick-way to achieve the same result (obviously "the same result plus Animation.draw() )?

I also tried switching the znear and zfar values to check the sorting... same result. Any ideas?

In general this will cause problems down the road; i.e. if you switch graphics contexts (flush() an image graphics), then glOrtho may be called back to the original screen size.

Also, if you are rendering things at the edge of the screen (or the center) using container.getWidth/Height, this might cause issues when the width/height doesn't match the value you gave to glOrtho.

And finally, this may throw off input.

The best solution is to either write your own system that handles scaling of your game and its entities, so you know exactly what's going on, or use ScalableGame. ScalableGame is a utility intended for this sort of thing -- but it's still somewhat experimental and may introduce some quirks to your rendering. Give it a try with ScalableTest.

That's true we might want to use the new Display resize function that LWJGL provides to make this work mor reliable.

_________________
Current Projects:
Mr. Hat I
Vegan Vs. Zombies
Projects:
RadicalFish Engine - Build on top of Slick2D, Ideas, Bugs? Open an Issue ticket!

Thanks for the ideas.
I'm quite experienced coding in OpenGL but Slick is new to me, so I often go about to reinvent the wheel and afterwards find out, Slick knows how to do it natively
I guess, the wiki needs to get more detailed about the built-in possibilities, because I often find it quite straining to download and search code examples only to get the grasp of a concept. Maybe I'll contribute some entries / tuts when I'm more experienced, as I'm really convinced of Java and Slick is one fantastic library.

About your answers:
Problems coming down the road is true enough, although rendering to the borders is, in my opinion, not one of them because the whole idea of the concept is not to use getWidth/getHeight in the game calculations at all - those values are fixed, the graphics are done on one rectangle and the output is scaled to be the full window, always.
Losing input seems more severe (you're talking mouse input here, aren't you?), but should be avoided by careful coding.

Until then I use a workaround solution that fixes all problems at the moment:

(oops, that was the submit button, not the code button)



To handle mouse input I divide the mouse positions by xScale and yScale before interpreting them, thus coming back to game coordinates. This might get a bit inexact when pixel-exact picking high resolution sprites but for my 32x32 sprites it works quite well.
Of course, if the window could change dimensions I'd have to update the scale factors as soon as the window changes, but at the moment it works great.

I didn't try ScalablaGame yet as I spent the day drawing sprites yesterday so I could do more in-depth testing but might in the future, although I can't see the advantages if a simple glScale has the same effect - maybe I'll be enlightened by the effort (but then I'm using a voxelspace approach to avoid futile tests in-game and thus am independent of the screen coordinates all the time I'm not drawing...).
Of course there might be some operations lurking in the API that change the scaling to their liking, but I'd honestly expect a well coded library to push and pop external attributes which need to be altered for a single operation.

This is exactly what ScalableGame does IIRC -- calls glScale and divides the mouse coordinates. Also, instead of glScale, you can use Graphics.scale as it's the same thing. Don't forget to push/pop matrices and set a world clip.

I'm not sure how it works with things like FBOs (Image.getGraphics) as the scale for those contexts may be reset. So if you use ScalableGame or your own methods, just be weary of these things..