Desktop/Android/HTML5/iOS Java game development framework

LWJGL 3 backend

I just committed the first iteration of the new LWJGL 3 backend. Going forward, i hope this can largely replace the old LWJGL 2 backend, especially on Mac OS X where we have a lot of problems with LWJGL 2. The new backend is also prepared for multi-window environments, altough respective methods in Lwjgl3Application haven't been exposed yet.

The LWJGL 3 backend is structure the same way as the LWJGL 2 backend, including the main module in backends/gdx-backend-lwjgl3 and a test module in tests/gdx-tests-lwjgl3. Everything is wired up with Maven and Eclipse projects so you can test things. I also wired it up with our Ant build, haven't tested that one at all.

It would be amazing if you guys could help test this. I already build snapshots for the new backend, and all the code is merged with master. You can easily switch out the LWJGL 2 backend for the LWJGL 3 backend in Gradle. In your core projects dependencies, change:

compile "com.badlogicgames.gdx:gdx-backend-lwjgl:$gdxVersion"

to

compile "com.badlogicgames.gdx:gdx-backend-lwjgl3:$gdxVersion"

Make sure gdxVersion is set to the latest snapshot version 1.7.3-SNAPSHOT. In your desktop launcher, simply replace LwjglApplicationConfiguration and LwjglApplication with Lwjgl3ApplicationConfiguration and Lwjgl3Application. That's it.

Not implemented yet

• [ ] Window refresh callback for nicer resize
• [x] HDPI support. Works out of the box on mac os x, but need to scale mouse coords accordingly. They are reported in logical coords, whereas Graphics reports framebuffer size now.
• [x] Screen mode change related functions in Lwjgl3Graphics. Just haven't gotten around implementing those. Note that when changing the screen mode (e.g. window -> fullscreen), GLFW returns a new window handle. Lwjgl3Input and Lwjgl3Graphics need to re-register all the GLFW callbacks in that case with the new window handle.
• [x] Clipboard support without AWT on Mac OS X
• [x] Fix fullscreen toggling. On Mac OS X, the first windowed -> fullscreen switch fails in weird ways, e.g. clearColor has an effect, but rendering doesn't. Subsequent fullscreen -> fullscreen switches work as intended (but those use glfwSetWindowSize instead of creating a new window). On Window (10) fullscreen switching doesn't work at all on HDPI monitors, need to test on normal monitors. Bug for Windows, Bug for Mac OS X. Should be resolved in GLFW, libGDX side does the proper thing.
• [x] Custom cursors in Lwjgl3Graphics. Haven't checked how to do that yet.
• [x] Application icon support. This needs to be covered via tools like PackR
• [x] Platform-specific multi-window API (Lwjgl3Application#newWindow(ApplicationListener, int width, int height)/newWindow(ApplicationListener, DisplayMode)).
• [x] Controller support. GLFW comes with its own controller API, should be simply to add that to the controllers extension. There's a bug on Windows in GLFW, where all gamepads are reported by the same name. This makes mapping controller types impossible.
• [x] OpenGL 3.0 support. We should only need to add that to Lwjgl3Application#createGlfwWindow. The Lwjgl3GL30 implementation is prepared, except for Lwjgl3GL30#glGetBufferPointerv
• [ ] Mac OS X (potentially Windows and Linux too): glfwSwapBuffers doesn't block in windowed mode if app window is fully behind other window or minimized. Bug with GLFW. Could "fix" it in our own code.
• [ ] Lwjgl3Input#getTextInput(), can't call into Swing/AWT
• [x] Non-continuous rendering in Lwjgl3Graphics. It's a bit of a bitch. Lwjgl3Input will already call Graphics#requestRendering() in case new input events arrive
• [ ] Make OpenALAudio thread-safe, put the update on a separate thread

Known Issues

• LWJGL 3 is based on GLFW. GLFW and AWT don't play nice with each other. Calling Swing/AWT stuff is thus not possible at the moment.
• On Mac OS X, you need to pass the JVM argument -XstartOnFirstThread when starting your app. We may be able to fix both things to some extend.
• If you use the multi-window API, understand that any Runnable you post via Gdx.app.postRunnable() may be executed in such a way that the statics in Gdx, like Gdx.graphics may point to a window other than the one for which the runnable was posted.

Why As said here this PR is heavily inspired to ResourceBundle + Control class from java.util. The main advantage, compared to java ResourceBundle, is that Android 2.2 is fully supported (Control class has been introduced in Android 2.3). Also, under certain circumstances looks like Android API uses an inconsistent encoding for property files loaded through a ResourceBundle. This issue is fixed.

What's changed The default behavior has changed. Bundles are loaded from file system (actually from FileType.Internal) instead of classpath. This change implies that the bundle name is now expressed as a relative path rather than as a fully qualified class name. Also, due to the use of relative paths, bundle names are no more unique. For example, the bundle name "foo/bar/Message" on FileType.Interal and the same bundle name on FileType.Local represent different bundles (it might depend on the specific backend though).

What's less The only missing features are ListResourceBundle and multiple class loaders support. However both features are pretty much useless for our purposes, so it's not really a big loss.

What's more

• Property files with an encoding other than the usual ISO-8859-1 are supported. This feature might be helpful for property files compatible with the 2nd approach below of GWT implementation (GWT I18N expects UTF8 files).
• Properties in the form of a XML document are supported. To load xml properties files from the FileType.Internal file system just pass one of the following Control instances to getBundle method:
  • PropertyFileControl.INTERNAL_XML_ONLY to access xml files only
  • PropertyFileControl.INTERNAL_XML_AND_PROPERTIES to access xml and key/value pairs files (xml has higher priority)
  • PropertyFileControl.INTERNAL_PROPERTIES_AND_XML to access xml and key/value pairs files (xml has lower priority)

To load xml files from any file system other than FileType.Internal you have to extend PropertyFileControl and override its getFormats method accordingly.

And GWT? The GWT implementation is not part of this PR. In fact, it's not yet clear what's the best way to implement this feature. From a first analysis there seem to be two viable approaches:

• emulating all the java classes used by this PR: Locale, Properties, CuncurrentHashMap, and many others.
• wrapping GWT's localization system, which supports both compile-time conversion of java property files and the search strategy implemented by java ResourceBundle. Especially, looks like the i18nCreator script and the ConstantsWithLookup interface might be helpful. See the following links:
  • http://www.gwtproject.org/doc/latest/DevGuideClientBundle.html
  • http://www.gwtproject.org/doc/latest/DevGuideI18n.html#DevGuidePropertiesFiles
  • http://www.gwtproject.org/doc/latest/DevGuideI18n.html#DevGuideStaticStringInternationalization
  • http://www.gwtproject.org/doc/latest/DevGuideI18nConstants.html

The second approach seems to be more promising.

I'll be on vacation the next days, also I'm not a GWT expert so don't expect a GWT version soon, at least not by me. Anyone who wants to contribute with ideas or code is welcome, of course.

EDIT:

• steering behaviors wiki page
• TODO list.

This PR adds steering behaviors for 2D and 2.5D, suitable for most games. Most steering behaviors work for full 3D too, excluded those behaviors that explicitly have an angular component, such as ReachOrientation, Face, LookWhereYouAreGoing and Wander (this is because we would need to change the representation of orientation and angular velocity from float values to Vector3 and Quaternion). The other behaviors only work linearly, so none of them requires any modification for full 3D because the equations work unaltered. Notice that the entire steering framework assumes that the direction a character is facing does not have to be its direction of motion, thus supporting independent facing that, among other things, allows you to smooth rotation over many frames when the direction abruptly changes.

Mainly the developer will have to implement the Steerable interface for the specific "engine" he's using: scene2d, box2d, bullet, his own engine or anything else. Test classes use scene2d for the sake of simplicity.

@NathanSweet and @Xoppa In the test classes I'm using com.badlogic.gdx.tests.g3d.BaseG3dHudTest.CollapsableWindow. Looks like I have to use a ScrollPane to make it work properly. Without the scrollpane when you double-click the title bar to expand the collapsed window one of the sliders may riceive both click events depending on the specific layout. Using stage.setDebugAll(true) you can clearly see that when the window is collapsed the title bar is vertically centered to the layout and the underlying non-visible components will receive click events. To replicate the issue replace

        ScrollPane pane = new ScrollPane(table, container.skin);
        pane.setFadeScrollBars(false);
        window.add(pane);

with

        window.add(table);

inside the createDetailWindow method of the class com.badlogic.gdx.tests.ai.steer.SteeringTest. Then run the Face behavior of the SteeringBehaviorTest. The "Deceleration Radius" slider will change when the Face window is collapsed and you click on the title bar. Any idea how to fix this?

OpenGLES was officially deprecated by Apple a few years ago. The succesor should be Metal. But for the cross platform design of libGDX it is hard to switch to another rendering backend only on one platform. And here comes ANGLE into play. ANGLE is a project by google that aims to translate platform independent OpenGL spec conform calls to platform specific graphic api calls. One library to rule them all, Metal, Vulkan, DirectX etc. with just OpenGL (quote was stolen). And this is what this backend does, implementing ANGLE with a Metal backend. To not have the burden to maintain two mobivm backends, @PokeMMO had the great idea and implemented a code generator that takes the "normal" backend and constructs the MetalANGLE backend from this. This works, because the difference is mainly only in a few binding classes. The backend also directly ships the MetalANGLE binarys, so you need a mac to build the backend. Or make sure to run "fetchNatives" beforehand. To use this backend just replace the standard robovm backend with this one. To update the backend run the gradle tasks "generate" and "spottlessApply". The backend also autoupdates itself on every push.

This pr implements @kakashidinho really great work "MetalANGLE" (https://github.com/kakashidinho/metalangle) into libGDX to as a seperate robovm backend. It also adds MetalANGLE bindings. Much of the discussion/tests about MetalANGLE was in this pr https://github.com/libgdx/libgdx/pull/6593.

Thinks that still need to be discussed/implemented

• ~How to fulfill ANGLE license conditions. ANGLE runs under BSD-3 license and libGDX under Apache 2 and iirc they are compatible so it should be fairly easy to do. Maybe it is already done because there are other pr's also related to ANGLE~ (THIRDPARTY file need to be further extended and integrated into build processes)
• ~To have a singe MetalANGLE static lib I remove from the ios sim lib the arm64 slice. This shouldn't have any downsides because the simulator always uses x86_64 arch, right?~
• ~How to effectively set the "ANGLE_DEFAULT_PLATFORM=gl" env variable in the simulator for MacOS in vm's. I exported it in the Terminal and then run xcrun from there, but maybe this is a bit annoying for regular use.~ (Will be implemented in newer version of MetalANGLE)
• ~gha currently needs to run "mvn validate" to fetch the MetalANGLE libs. Maybe this should be better done in gradle.~
• It needs to be validated whether the gha correctly picks up the MetalANGLE framework into the natives.zip. (The logs at https://github.com/Berstanio/libgdx/runs/3920755152 are clearly hinting that it happens correctly)
• ~Gradle build should be supported~
• ~Fix issue with MetalANGLE framework on real devices~
• Use MetalANGLE dynamic framework or static framework?
  • pro static:
    • fails on linking when Metal is not specified as framework see, see
    • produces smaller app size (5mb lesser increase)
  • contra static:
    • the libs are enormous ~2GB (is tracked in a MetalANGLE issue, but its unclear when and how much the lib size can get reduced)
    • console is spammed with symbol warnings (maybe fixable and maybe related to the point above)
  • pro/contra dynamic (just the pros/cons of static inverted)
• The "BitmapFontAtlasRegionTest" fails on simulator (https://github.com/kakashidinho/metalangle/issues/68)

For now the pr will got with the MetalANGLE framework, but this can easily be switched later

This fixes https://github.com/libgdx/libgdx/issues/5251, I think.

A lot of times I see newbies implementing custom Actors and making mistakes like not setting any size, or setting a position but rendering a (for example) button texture to some different coordinates.

I found myself in need for something like this as well when I was implementing an "overlay input layer" for box2d bodies for example. This "layer" was completely invisible, but it would be nice to be able to easily enable some kind of outlines for the actors to see where the touch areas would be.

Do you think it is useful? Any suggestions for additional features/changes?

I managed to get a first draft for the gdx-pay extension (cross-platform InApp payments for libGDX) ready for review. This is less of a pull request but more of a request for feedback. Please comment - Thanks :-D

What's currently implemented (extension projects):

• gdx-pay: the cross-platform code (complete)
• gdx-pay-android-openiab: gdx-pay implementation for Android supporting Google Play, Amazon, Samsung and a few other stores. I used the open source OpenIAB library. (complete)
• gdx-pay-iosrobovm-apple: stub for the iOS store (needs implementation)
• gdx-pay-desktop-apple: stub for the Apple Mac store (needs implementation)
• gdx-pay-gwt-googlewallet: stub for the GWT backend/GoogleWallet (needs implementation)

This test demonstrates how the payment system is used in your platform-independent code:

• PayTest.java

To integrate into Android, you will need to add corresponding hooks to your activity (look for the 3x "// InApp:"):

• Integration Android

Screenshot running PayTest.java on an Android device:

It's kind of sad that gdx-setup is still using Gradle 2.10 by default. Espeically the libGDX itself is built with Gradle 3.1, which means one has to use two different major versions of Gradle if he works from source. Shouldn't the generated project use the same version as libGDX does?

Gradle 3.5 just released with some good features. I'll suggest upgrading both libGDX and gdx-setup project to 3.5. I actually upgraded the Gradle wrapper of my project to Gradle 3.5 and it worked on desktop, but I haven't tested it on android/ios/gwt.

Issue details

On Samsung's keyboard, there is a glitch where it does not process the command InputType.NULL sent by the Android App and therefore shows predictive text above the keyboard, which breaks LibGDX's keyboard input.

I think this may be temporarily fixed if we can modify the InputType of the on screen keyboard. This would allow us to set the keyboard's input type as a visible password, which would prevent predictive text appearing.

I know this is not necessarily an issue with LibGDX, it is more Samsung's issue. It was reported to Samsung a while agobut I don't think they will be fixing it anytime soon.

Reproduction steps/code

Create a game that uses an InputProcessor to receive keyboard input.

Load the game on a Samsung Galaxy S5, S6, S6 Edge or Note 5 that uses the Samsung Keyboard app. Make sure predictive text is enabled on the keyboard settings.

Try to type something and no input will be registered.

Version of LibGDX and/or relevant dependencies

Please provide the version(s) affected. I have only tested with 1.6 and 1.9.3

Please select the affected platforms

• [x] Android
• [ ] iOS
• [ ] HTML/GWT
• [ ] Windows
• [ ] Linux
• [ ] MacOS

The current rendering styles of gdx-freetype are somewhat limited, requiring you to revert to external tools if you want any more fancy effects, such as outlines or shadows. Without shadow, text is really hard to read in any normal game.

To address this issue, this request adds a couple of new font parameters (documented in code):

• color: Foreground color; required as multi-colored fonts cannot be colored on rendering by GL. Defaults to white like before
• borderWidth / borderColor: Outline, defaults to off. Note: large border widths may lead to overlap, but this should be way beyond the "looks good" zone
• borderStraight: Line ending style for outline (curved or straight)
• shadowOffset / shadowColor: Shadow, defaults to off

Example rendering:

While implementing, I found that the current freetype JNI interface was a little weird, so I did some refactoring (first commit).

Only tested on Win64.

Problem I wanted to make a class, that will render a custom shaped polygon that is filled with repeating TextureRegion. This was possible to do with PolygonSprite class if "Texture" is used. But most use case require using TextureRegion instead. As a temporary solution, previously I was using PolygonSprite and a custom shader to which I was passing u/v data in order to render this. But this was bad too because it causes additional render call for each polygon, which sucks.

Solution I propose using this class instead. In short it triangulates a polygon to a "grid" so that we can easily specify all u/v coordinates and pass this directly to PolygonSpriteBatch.

In order to avoid being murdered by @xoppa , a density variable is passed to specify the "grid" density, thus eliminating any connection to actual pixel size of texture region.

I did some testing and it seems to work fine, but at this stage it is not yet ready to merge, I would be happy if you guys can: a) decide if you need this at all in libgdx - maybe many reasons why you do not b) see if initial idea looks well implemented, test and so on

I will do some additional fixes/additions/pushes during the weekend.

I'm not sure whether I'm doing those PRs correctly or not, because somehow it seems like I'm always replacing whole files, but well, I'm new to git still...

I have written a little wiki page about the Viewports I've implemented. https://github.com/libgdx/libgdx/wiki/Viewports

There are also some tests. Every viewport now manages a camera. Mostly this was done to keep backwards compatibility and not break any API. I only had to add one more method to Stage which just sets the viewport parameters.

I like how it works now, the only thing I don't like is the automatic position change of the camera when Viewport.update() is called. This might be removed and be done manually instead, keeping it more clean in total (Viewport wouldn't do anything but implement a scaling strategy in this case), but it also means it's less comfortable to use.

Having that said, all changes are completely additionally. This doesn't "cleanup" the API, like I planned it initially, but it also doesn't break any core stuff...

Issue details

gdx-setup generates the libGDX project which uses Gradle's Groovy DSL.

It's also possible to write Gradle buildscripts in Kotlin DSL, which:

provides an alternative syntax to the traditional Groovy DSL with an enhanced editing experience in supported IDEs, with superior content assist, refactoring, documentation, and more.

I'd like to be able to which Gradle DSL to use when creating a new libGDX project: Groovy or Kotlin.

See also:

• Gradle Kotlin DSL Primer

If not in the official gdx-setup app, this could be added to an alternative, less conservative project generator such as gdx-liftoff.

Please select the affected platforms

All or none - depends on how you look at it :)

Issue details

Hi! In Android 11 a new system zoom animation was added for static and live wallpapers, so when the user pulls down the quick settings panel or swipe up to the launcher's app drawer, the wallpaper will be zoomed in/out.

For live wallpapers there is a callback for this, very similar to the onOffsetsChanged() callback in AndroidLiveWallpaperService.java, but in libGDX the implementation of the callback is currently missing.

To implement the zoom callback,

• the overridden method from Android's WallpaperService would have to be implemented into the AndroidWallpaperEngine in AndroidLiveWallpaperService.java
• an new method notifyZoomChanged() would have to be implemented into the AndroidWallpaperEngine to call the new method zoomChange(float) of the interface AndroidWallpaperListener.java

I would like to implement the wallpaper zoom animation into my 3D Van Gogh live wallpaper Lamartine :) I tried to extend AndroidLiveWallpaperService but because the global variables of AndroidLiveWallpaper are protected, a custom implementation of the zoom callback is impossible. Thank you and a Happy New Year!

Version of libGDX

1.11.0

Please select the affected platforms

• [x] Android
• [ ] iOS
• [ ] HTML/GWT
• [ ] Windows
• [ ] Linux
• [ ] macOS

Issue details

class attributes of objects in tiled export tmx files from1.9.2 cannot be read in libgdx 1.11

Reproduction steps/code

public abstract class BaseTmxMapLoader{
	protected void loadObject (TiledMap map, MapObjects objects, Element element, float heightInPixels) {
		if (element.getName().equals("object")) {
			MapObject object = null;

			float scaleX = convertObjectToTileSpace ? 1.0f / mapTileWidth : 1.0f;
			float scaleY = convertObjectToTileSpace ? 1.0f / mapTileHeight : 1.0f;

			float x = element.getFloatAttribute("x", 0) * scaleX;
			float y = (flipY ? (heightInPixels - element.getFloatAttribute("y", 0)) : element.getFloatAttribute("y", 0)) * scaleY;

			float width = element.getFloatAttribute("width", 0) * scaleX;
			float height = element.getFloatAttribute("height", 0) * scaleY;

			if (element.getChildCount() > 0) {
				Element child = null;
				if ((child = element.getChildByName("polygon")) != null) {
					String[] points = child.getAttribute("points").split(" ");
					float[] vertices = new float[points.length * 2];
					for (int i = 0; i < points.length; i++) {
						String[] point = points[i].split(",");
						vertices[i * 2] = Float.parseFloat(point[0]) * scaleX;
						vertices[i * 2 + 1] = Float.parseFloat(point[1]) * scaleY * (flipY ? -1 : 1);
					}
					Polygon polygon = new Polygon(vertices);
					polygon.setPosition(x, y);
					object = new PolygonMapObject(polygon);
				} else if ((child = element.getChildByName("polyline")) != null) {
					String[] points = child.getAttribute("points").split(" ");
					float[] vertices = new float[points.length * 2];
					for (int i = 0; i < points.length; i++) {
						String[] point = points[i].split(",");
						vertices[i * 2] = Float.parseFloat(point[0]) * scaleX;
						vertices[i * 2 + 1] = Float.parseFloat(point[1]) * scaleY * (flipY ? -1 : 1);
					}
					Polyline polyline = new Polyline(vertices);
					polyline.setPosition(x, y);
					object = new PolylineMapObject(polyline);
				} else if ((child = element.getChildByName("ellipse")) != null) {
					object = new EllipseMapObject(x, flipY ? y - height : y, width, height);
				}
			}
			if (object == null) {
				String gid = null;
				if ((gid = element.getAttribute("gid", null)) != null) {
					int id = (int)Long.parseLong(gid);
					boolean flipHorizontally = ((id & FLAG_FLIP_HORIZONTALLY) != 0);
					boolean flipVertically = ((id & FLAG_FLIP_VERTICALLY) != 0);

					TiledMapTile tile = map.getTileSets().getTile(id & ~MASK_CLEAR);
					TiledMapTileMapObject tiledMapTileMapObject = new TiledMapTileMapObject(tile, flipHorizontally, flipVertically);
					TextureRegion textureRegion = tiledMapTileMapObject.getTextureRegion();
					tiledMapTileMapObject.getProperties().put("gid", id);
					tiledMapTileMapObject.setX(x);
					tiledMapTileMapObject.setY(flipY ? y : y - height);
					float objectWidth = element.getFloatAttribute("width", textureRegion.getRegionWidth());
					float objectHeight = element.getFloatAttribute("height", textureRegion.getRegionHeight());
					tiledMapTileMapObject.setScaleX(scaleX * (objectWidth / textureRegion.getRegionWidth()));
					tiledMapTileMapObject.setScaleY(scaleY * (objectHeight / textureRegion.getRegionHeight()));
					tiledMapTileMapObject.setRotation(element.getFloatAttribute("rotation", 0));
					object = tiledMapTileMapObject;
				} else {
					object = new RectangleMapObject(x, flipY ? y - height : y, width, height);
				}
			}
			object.setName(element.getAttribute("name", null));
			String rotation = element.getAttribute("rotation", null);
			if (rotation != null) {
				object.getProperties().put("rotation", Float.parseFloat(rotation));
			}
			String type = element.getAttribute("type", null);
			if (type != null) {
				object.getProperties().put("type", type);
			}


			//=====================new begin============================
			String proClass= element.getAttribute("class", null);
			if (proClass != null) {
				object.getProperties().put("class", proClass);
			}
			//=====================new end=============================



			int id = element.getIntAttribute("id", 0);
			if (id != 0) {
				object.getProperties().put("id", id);
			}
			object.getProperties().put("x", x);

			if (object instanceof TiledMapTileMapObject) {
				object.getProperties().put("y", y);
			} else {
				object.getProperties().put("y", (flipY ? y - height : y));
			}
			object.getProperties().put("width", width);
			object.getProperties().put("height", height);
			object.setVisible(element.getIntAttribute("visible", 1) == 1);
			Element properties = element.getChildByName("properties");
			if (properties != null) {
				loadProperties(object.getProperties(), properties);
			}
			objects.add(object);
		}
	}
}

Version of libGDX and/or relevant dependencies

gdxVersion = '1.11.0'

Stacktrace

//Please provide the stacktrace if applicable 

Please select the affected platforms

• [x] Android
• [x] iOS
• [x] HTML/GWT
• [x] Windows
• [x] Linux
• [x] macOS

Issue details

Runtime exceptions originated from the post runnables' code get "muted" (printStackTrace() and ignore) on Android and RoboVM backends. Unlike on the other platforms, where those exceptions result in a hard crash or could be intercepted with the thread's default exception handler.

This is also a rather bad behavior as it tends to mask runtime issues and left developers unaware of something is broken (unless they lucky enough to spot the message in the log).

I wonder if this could be due to some technical specifics of the mobile platforms or somehow related to multithreading. But as far as I can see, there's no plain reason.

Reproduction steps/code

Run it on LWJGL3 or GWT backend and you get an obvious crash. But try it on Android or iOS and magically nothing is going wrong...

import com.badlogic.gdx.*;

public class PostRunnableCrash extends ApplicationAdapter {
    public void create () {
        Gdx.app.postRunnable(new Runnable() {
            @Override
            public void run() {
                throw new RuntimeException("You won't see me on mobile.");
            }
        });
    }
}

Version of libGDX and/or relevant dependencies

1.11.0

Please select the affected platforms

• [x] Android
• [x] iOS
• [ ] HTML/GWT
• [ ] Windows
• [ ] Linux
• [ ] macOS

Issue details

The use of EGL_COVERAGE_SAMPLES_NV attribute (https://github.com/libgdx/libgdx/search?q=EGL_COVERAGE_SAMPLES_NV) can cause errors (i.e. EGL_BAD_ATTRIBUTE) in EGL implementations that don't support it. Libgdx should check the extensions string before attempting to use this attribute.

Version of libGDX and/or relevant dependencies

All recent versions of libgdx as far as I can tell

Please select the affected platforms

• [x ] Android
• [ ] iOS
• [ ] HTML/GWT
• [ ] Windows
• [ ] Linux
• [ ] macOS