LibGDX Game vs ApplicationAdapter

12

Cuando creo un nuevo proyecto LibGDX, la clase principal del proyecto Core extiende ApplicationAdapter . Así es como se ve.

package com.marimba.apptest;

import com.badlogic.gdx.ApplicationAdapter;
import com.badlogic.gdx.Gdx;
import com.badlogic.gdx.graphics.GL20;

public class AppMain extends ApplicationAdapter {   
    @Override
    public void create () {

    }

    @Override
    public void render () {
        Gdx.gl.glClearColor(1, 0, 0, 1);
        Gdx.gl.glClear(GL20.GL_COLOR_BUFFER_BIT);

    }
}

Entonces, tengo que cambiar ApplicationAdapter a Game si quiero llamar al método setScreen para cambiar entre pantallas. Entonces, ¿para qué sirve ApplicationAdapter ? ¿Cuándo lo usaré?

java libgdx

— Vahe Muradyan
fuente

7

Como dijo @ user3068350, tanto Game como ApplicationAdapter implementan ApplicationListener. Es útil extender el Juego si planea usar la interfaz de Pantalla en su juego, sin embargo, algunos desarrolladores pueden desear adoptar un enfoque diferente y manejar la administración de la pantalla a su manera. Si este es el caso, se extenderá ApplicationAdapter.

Personalmente, me gusta que mis clases implementen una interfaz personalizable y / o actualizable, ya que separo mi método de renderizado en actualización y dibujo. En este caso, usar Screen anularía el propósito ya que la interfaz contiene un método de renderizado.

— driima
fuente

1

La clase Game implementa la interfaz ApplicationListener y es solo una clase diseñada para facilitar el cambio entre diferentes pantallas. Cuando se llama a un método en ApplicationListener, la clase Game se encarga de delegarlo en la pantalla configurada actualmente.

— usuario3068350
fuente

1

pero cuando debo usar ApplicationAdapter? ¿Y cómo debo usar pantallas aquí?

— Vahe Muradyan

2

No necesita usar ApplicationAdapter. Tanto ApplicationAdapter como Game implementan la interfaz ApplicationListener. Una clase de adaptador es solo una clase que proporciona implementaciones de esqueleto para una interfaz para que no tenga que saturar su código con cuerpos de método vacíos. Para usar pantallas con Game, llama a setScreen y pasa a una clase que implementa la interfaz Screen. Puede hacer que sus clases de pantalla tomen un objeto Juego en el constructor para que pueda cambiar las pantallas dentro de una pantalla.

— user3068350

1

Entonces, ¿por qué han creado ApplicationAdapter si no tiene ningún uso?

— Vahe Muradyan

2

@VaheMuradyan, el usuario ya respondió que: no tiene que saturar su código con cuerpos de método vacíos. Cuando implementa ApplicationListenerdirectamente, debe proporcionar todos los métodos requeridos, incluidos los que no necesita (como pause()o resume(), que no siempre se usan). ApplicationAdapterestá disponible para su conveniencia, por lo que no tiene que guardar métodos vacíos. Es una clase de utilidad simple, no agrega nuevas funcionalidades, solo mantiene su código más limpio (o más corto ).

— JustACluelessNewbie

1

A medida que el ApplicationAdapter y la clase Game implementan la interfaz ApplicationListener, ambos pueden usarse casi indistintamente al crear su juego. Si está configurado para usar la pantalla, no hay nada que le impida implementarlas con ambas opciones.

La clase de juego tiene un poco más de gastos generales usando pantallas. Sin embargo, esta sobrecarga está diseñada para facilitar la implementación de diferentes etapas / niveles en tu juego. Es importante tener en cuenta que esta sobrecarga es mínima.

El ApplicationAdapter no tiene ninguna sobrecarga adicional (es una aplicación recta de un ApplicationListener). Esto le da más control ya que tiene que hacer todo usted mismo. Personalmente, prefiero usar ApplicationAdapters.

TL; DR: No hay diferencia real entre ellos. ApplicationAdapter te da un poco más de control y el juego es un poco menos de trabajo.

— Fichas
fuente