Tons of new Stuff in Libgdx!

For the next 4 days (including today), i put together a nasty todo list for libgdx 1.0. Today i finished off all the things i planned for today. So hurray me 🙂 What’s new?

Displaymode Enumeration and Fullscreen Support
A feature that’s been on my todo list for a gazillion years already. The Graphics interface has a couple of new methods that allow you to query for available fullscreen display modes and set them with a single call. Here are the new methods:

Before you can change the display mode you have to make sure you can actually do that. Nothing will fail per se if you try to change a display mode when that feature is not supported, but it is good practice 🙂

These two methods return the available fullscreen display modes. The first one returns all of them, the second one returns the desktop display mode currently set. Usually you want to go fullscreen with the width/height of the desktop display mode. However, if you want to be fancy you can enumerate all display modes with the first method, present them to the user and let them chose what fullscreen resolution they want to run with.

Sets a DisplayMode retrieved via getDisplayModes() or getDesktopDisplayMode(). This will return whether that action succeeded. In case it did your ApplicationListener will also receive a call to its resize() method later on.

For the brave among you, you can directly try this method. Specify the width and height of the resolution in pixels and away you go. Note the last parameter. If it is false you will switch back to windowed mode. This method also allows you to resize your window in windowed mode 🙂

You can call all these methods at any time, except for the dispose() method. Usually you’ll call them in create() and render() when appropriate.

Also note that these methods have no effect on Android of course. The getDesktopDisplayMode() and getDisplayModes() methods will return a display mode specifying the native screen resolution. Setting a mode on Android does not work for obvious reasons. If you don’t need fullscreen on Android remember that there’s the AndroidApplication.initializeForView() method!

Here’s the DisplayMode class in all it’s glory:

You can’t instantiate that one, use the getDisplayModes() and getDesktopDisplayMode() methods.

VSync
Another new method:

Straight forward. On Android that method has no effect. In Lwjgl it will either synch to the display refresh rate (which might fail) or use a cpu synch that tries to cap the framerate. The later was the default until now. Both suck. Jogl manages to vsynch with the display just fine it seems. More on the Lwjgl vsync stuff in a bit.

Querying the Buffer Format
The buffer format is a term i totally made up. What i mean by it is the number of bits for the color buffer, the depth buffer, the stencil buffer as well as the number of samples used for MSAA (anti-aliasing on the desktop).

Here’s the BufferFormat class:

To query the buffer format used by the OpenGL surface call the following Graphics method:

The BufferFormat instance will then tell you with that color, depth and stencil depth you are operating as well as how many samples are used for MSAA.

JoglApplicationConfiguration, LwjglApplicationConfiguration, AndroidApplicationConfiguration
Now, how can you set the buffer format? With the new configuration classes for all three backends! We already had the AndroidApplicationConfiguration, see this blog post. That one got extended a bit. Let’s go over them one by one.

Fancy, right? You can specify whether you want to use GLES 2.0, how many bits per color channel to use, how many bits to use for the depth and stencil buffer and so on. You can also specify if you want to immediately start off as a fullscreen application instead of toggling that in ApplicationListener.create(). To facilitate this there are two static methods called getDesktopDisplayMode() and getDisplayModes(). Guess what they return 🙂 Use the setFromDisplayMode() method to set the configuration from a specific fullscreen mode. You use this class like this:

Easy, right? The LwjglApplicationConfiguration looks exactly the same:

As you can see it is nearly 100% identical. You can use it in the exact same way as you use the JoglApplicationConfiguration, just pass it to the constructor of your LwjglApplication after you defined it. Note the additional flag called useCPUSynch. If that is set to true the vsynch is simulated via frame rate capping to 60fps. If it is set to false and vsynch is enabled (Graphics.setVSync(true)) then Lwjgl will try to use the real display vsync.

Finally we have new additions to the AndroidApplicationConfiguration:

As expected, you can now also specify the buffer format on android. The default values will work on all Android devices.

A Word on Stencil Buffer Support
By default all the backends do not create a stencil buffer. If you want a stencil buffer you have to set teh config.stencil flag to a value. On Android you should set this value to 1, EGL will then chose the nearest supported stencil format. On the desktop (Lwjgl and Jogl) you should set it to 8.

That is all, enjoy.

7 thoughts on “Tons of new Stuff in Libgdx!

  1. All cool, but I still miss one important thing on desktops: mouse catching. For windowed modes you’ll want to grab the mouse most of the time, so it can’t leave the window until a specific key is pressed. When grabbed, system mouse cursor isn’t shown. See Minecraft as an example: http://www.minecraft.net/play.jsp

  2. Hey Mario,

    Nice to see the inclusion of fullscreen but when I tried to use it all I get is a grayish area the size of my DisplayMode. The game seems to work fine (when I run it I can hear the guns fire and the enemies die until they get to the player and then I hear the player die) but instead of seeing any of the graphics I see a grayish area. Any idea why this is happening?

    Thanks,
    Jari

    P.S. Yes … I would like the applications to be able to grab the mouse (and also change the mouse’s location on screen) as well.

  3. What operating system are you running this on? What backend are you using (Jogl, Lwjgl)? What graphics card do you run this on?

    Also, grabbing the mouse is implemented as well now, see the other post.

  4. Mario: You’re awesome. I’ll go check the other post after this reply 🙂
    The information you wanted is below:

    Backend: Jogl
    OS: Windows 7 Home Premium (32 Bit)
    Graphics Card: nVidia 8400M GS (it’s a mobile card)

    I can send you my eclipse project as well if that would help (just don’t make fun of it, it’s a complete mess right now :D)

  5. Could you please try the lwjgl backend? And could we move this dicsusion over to the forums, it’s easier to keep track of for me there.

  6. Hey Mario,
    I have been facing a problem in rendering of game on the android devices. The game is running fine on my HDPI android phone(with good processor) but it is much slower on the MDPI android phones(with medium processor).You said “vSync” has no effect on android phones.So, how I will optimize my game so that it would render same on every device.I have this ques. on the forum but got no reply.

    Thanks
    JaGdeeP

Leave a Reply

Your email address will not be published.