LibGDX is a great cross-platform game development framework, but it is not well known in China.

The characteristics of

For features, please refer to Baidu (deleted) :

Strong compatibility

Libgdx is compatible with multiple platforms (Windows, Linux, Max OS X…) , including mobile system Android (version 1.5 +), in addition, based on RoboVM can achieve iOS compatibility

At the same time, strong compatibility provides convenience for debugging and development. You can write, test, and debug your apps on a desktop PC using the same code as Android (that is, you can debug games written using Libgdx without opening the Android emulator).

High efficiency

Libgdx is written primarily in Java, with some C/C++ code mixed in to handle performance-critical operations such as physics engines or audio processing. As a user, all you need to worry about is Java encapsulation, which already encapsulates all your native code. Libgdx has a significant efficiency advantage over other Android game engines.

Architecture is clear

The main components of libgdx are shown below

Libgdx consists of several modules, including Audio, files, graphics, Math, physics, scenes, utils, etc. These modules are used for audio manipulation, file reading, 2D/3D rendering, Libgdx drawing related operations, Box2D packaging, etc. 2D/3D game components, and Libgdx built-in utility classes.

It also provides a clear framework for designing games

encapsulation

It’s crazy enough to use jni to wrap a c++ version of box2d, making it run much faster than other physics engines like jbox2d. The few popular Android game engines that include physics engines (Andengine, Rokon, etc.) almost all use Libgdx.

tool

Libgdx also has a number of development tools. Examples include Particle Editor, Hiero Bitmap Font Generator, Texture Packer, TWL Layout editor, Gdx Setup UI, etc.

network

Libgdx was originally mostly used for single-player or weakly connected games, but has been refined to include a dedicated networking module.

Program structure

Of course, like the column title, there is no tutorial on libGDX related environment configuration

LibGDX application lifecycle

The application Lifecycle interface ApplicationListener class

LibGDX through com. Badlogic. Etf has the ApplicationListener interface provides the application lifecycle, developers by implementing these interfaces in order to realize the basic logic and the game cycle:

• Create () : Called once when the application starts
• Resize (width,height) : called when the application changes the screen size and is not paused. It is also called once after create() and resume()
• Render () : call continuously after application initialization
• Pasue () : App loses focus/pauses (Android switches to another app or presses the home button… ,desktop minimize…) Dispose () will also be called once before dispose()
• Resume () : called when the application resumes focus
• Dispose () : Called when the application is destroyed

The libGDX application is also described as following: Tips:Implements classes are generally the main application class.

ApplicationListener Empty implementation class ApplicationAdapter

In actual development, generally do not need to use all the way to the ApplicationListener interface, so you can use com. Badlogic. Etf has. ApplicationAdapter class, it implements the empty ApplicationListener all the methods, Methods can be implemented selectively, which is convenient. 😀

LibGDX application interactive interface

In libGDX, the core com.badlogic.gdx package (gdx.jar) has six basic interfaces for applications to interact with the system:

• Application: an instance of an Application, usually when the initiator class is initialized and the Application main class is started. Also provides the application, system information query, notification, log output and so on
• Files: Exposes underlying Files and provides methods for reading and modifying Files
• Input: Reads the Input from the user
• Net: provides access to resources from HTTP/HTPPS, creates TCP services and client scokets
• Audio: You can also access Audio devices directly by creating music and sound instances and by playing Audio
• Graphics: Exposes the OpenGL ES 2.0 interface to get render time, world width and height, frame rate and other methods

Each of these classes has a static member in the com.badLogic.gdx.gdx class:

Gdx.app

Gdx.files

Gdx.input

Gdx.net

Gdx.audio

Gdx.graphics

LibGDX program launcher

LibGDX applications don’t start out executing the main class. You need an initiator class to start the window and start executing the main class. Each application has an initiator class:

package com.libGDX.test;

import com.badlogic.gdx.backends.lwjgl.LwjglApplication;
import com.badlogic.gdx.backends.lwjgl.LwjglApplicationConfiguration;
// Initiators
public class DesktopLauncher {
    // The program starts here
    public static void main(String[] args) {
        // Initialize the window configuration
        LwjglApplicationConfiguration config=new LwjglApplicationConfiguration();
	// Set the window name to "hello", 200 x 200 width and height, and cannot change the size
        config.width=200;
        config.height=200;
        config.title="hello";
        config.resizable=false;
	// Create a window, Demo main class name, must implements ApplicationListener or extends ApplicationAdapter
	new LwjglApplication(newDemo(),config); }}Copy the code

LibGDX log output

As mentioned earlier, the Application class provides logging functionality as follows:

// Outputs info logs
Gdx.app.log("my log"."info");
// Outputs debug logs
Gdx.app.debug("my log"."debug");
// Outputs an error log with an Explosion object
Gdx.app.error("my log"."error");
Gdx.app.error("my log"."error",explosion);
Copy the code

The output level can also be qualified by setLogLevel()

• Application.LOG_NONE: No log is generated
• Application.LOG_DEBUG: Outputs all logs
• Application.LOG_INFO: Outputs INFO and error logs
• Application.LOF_ERROR: Only error logs are generated

LibGDX DE try

Ok, now that you have the basics, let’s test it by making a small program that outputs different logs based on events:

// omit the initiator class...
package com.libGDX.test;

import com.badlogic.gdx.ApplicationListener;
import com.badlogic.gdx.Gdx;

public class Test implements ApplicationListener {
	@Override
	public void create(a) {
            // Outputs all logs
            Gdx.app.setLogLevel(Gdx.app.LOG_DEBUG);
            // Different logs are used here to determine the severity of logs
            Gdx.app.error("sysout"."create");
	}

	@Override
	public void dispose(a) {
            Gdx.app.error("sysout"."dispose");
	}

	@Override
	public void pause(a) {
            Gdx.app.log("sysout"."pause");
	}

	@Override
	public void render(a) {
            Gdx.app.debug("log"."render");
	}

	@Override
	public void resize(int arg0, int arg1) {
            Gdx.app.log("sysout"."resize");
	}

	@Override
	public void resume(a) {
            Gdx.app.log("sysout"."resume"); }}Copy the code

So let’s go ahead and run this

Graph TD minimize --> Restore --> Exit

The results are as follows:

We can see that render() is running, which means we did it! But don’t worry, let’s change logLevel to LOG_INFO and try again:

Render () output is blocked, but what about LOG_ERROR? Needless to say: