LibGDX Game vs ApplicationAdapter

12

Kiedy tworzę nowy projekt LibGDX, główna klasa projektu Core rozszerza ApplicationAdapter . Oto jak to wygląda.

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);

    }
}

Więc muszę zmienić ApplicationAdapter na Game, jeśli chcę wywołać metodę setScreen, aby przełączać się między ekranami. Jakie jest więc zastosowanie ApplicationAdapter ? Kiedy powinienem go użyć?

java libgdx Vahe Muradyan
źródło

Odpowiedzi:

7

Jak powiedział @ user3068350, zarówno Game, jak i ApplicationAdapter implementują ApplicationListener. Przedłużenie gry jest przydatne, jeśli planujesz używać interfejsu ekranu w grze, jednak niektórzy programiści mogą chcieć zastosować inne podejście i zarządzać ekranem na swój własny sposób. W takim przypadku przedłużą one ApplicationAdapter.

Osobiście lubię, gdy moje klasy wdrażają niestandardowy interfejs, który można aktualizować i / lub rysować, ponieważ moją metodę renderowania dzielę na aktualizację i rysowanie. W takim przypadku użycie Screena zniszczyłoby cel, ponieważ interfejs zawiera metodę renderowania.

driima
źródło
1

Klasa Game implementuje interfejs ApplicationListener i jest tylko klasą zaprojektowaną, aby ułatwić przełączanie między różnymi ekranami. Po wywołaniu metody z ApplicationListener klasa Game zajmuje się delegowaniem jej na aktualnie ustawiony ekran.

użytkownik3068350
źródło
1
ale kiedy powinienem użyć ApplicationAdapter? I jak mam tutaj używać ekranów.
Vahe Muradyan
2
Nie musisz używać ApplicationAdapter. Zarówno ApplicationAdapter, jak i Game implementują interfejs ApplicationListener. Klasa adaptera to tylko klasa, która zapewnia szkieletowe implementacje interfejsu, więc nie musisz zaśmiecać kodu pustymi treściami metod. Aby używać ekranów z Grą, wywołujesz setScreen i przekazujesz klasę, która implementuje interfejs Screen. Możesz sprawić, by twoje klasy ekranów zajęły obiekt Konstruktora, abyś mógł zmieniać ekrany na ekranie.
user3068350,
1
więc dlaczego utworzyli ApplicationAdapter, jeśli nie ma on żadnego zastosowania?
Vahe Muradyan
2
@VaheMuradyan, użytkownik już odpowiedział, że: nie musisz zaśmiecać kodu pustymi treściami metod. Kiedy wdrażasz ApplicationListenerbezpośrednio, musisz podać wszystkie wymagane metody, w tym te, których nie potrzebujesz (np. pause()Lub resume(), które nie zawsze są używane). ApplicationAdapterjest dostępny dla Twojej wygody, więc nie musisz trzymać pustych metod w pobliżu. Jest to prosta klasa narzędziowa, nie dodaje żadnych nowych funkcjonalności - po prostu utrzymuje twój kod w czystości (lub krócej ).
JustACluelessNewbie
1

Ponieważ ApplicationAdapter i klasa Game implementują interfejs ApplicationListener, można z nich korzystać niemal zamiennie podczas tworzenia gry. Jeśli korzystasz z ekranu, nic nie stoi na przeszkodzie, aby zastosować je w obu opcjach.

Gra klasa ma trochę bardziej z głową to za pomocą ekranów. Jednak narzut ten został zaprojektowany, aby ułatwić wdrażanie różnych etapów / poziomów w grze. Należy zauważyć, że ten narzut jest minimalny.

ApplicationAdapter ma dodatkowy narzut (jest to prosta implementacja ApplicationListener). Daje to większą kontrolę, ponieważ musisz zrobić wszystko sam. Osobiście wolę używać ApplicationAdapters.

TL; DR: Brak rzeczywistej różnicy między nimi. ApplicationAdapter daje ci trochę więcej kontroli, a gra to trochę mniej pracy.

Blunderchips
źródło