Гра LibGDX проти ApplicationAdapter

12

Коли я створюю новий проект LibGDX, основний клас проекту Core розширює ApplicationAdapter . Ось як це виглядає.

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

    }
}

Тому я повинен змінити ApplicationAdapter на Game, якщо хочу зателефонувати на метод setScreen, щоб переключитися між екранами. Тож у чому полягає застосування ApplicationAdapter ? Коли я буду його використовувати?

java libgdx

— Вахе Мурадян
джерело

7

Як сказав @ user3068350, і Game, і ApplicationAdapter реалізують ApplicationListener. Гра корисно розширити, якщо ви плануєте використовувати екранний інтерфейс у своїй грі, проте деякі розробники можуть скористатися іншим підходом і керувати керуванням екраном по-своєму. Якщо це так, вони поширять ApplicationAdapter.

Особисто мені подобається, що мої класи реалізують користувальницький інтерфейс для оновлення та / або Dravable, оскільки я відокремлюю метод візуалізації на оновлення та малювання. У цьому випадку використання Screen переможе мету, оскільки інтерфейс містить метод візуалізації.

— дрима
джерело

1

Ігровий клас реалізує інтерфейс ApplicationListener і є лише класом, який спрощений для легкого перемикання між різними екранами. Коли виклик методу в ApplicationListener, клас ігор піклується про делегацію його на встановлений на даний момент екран.

— user3068350
джерело

1

але коли я повинен використовувати ApplicationAdapter? І як тут використовувати екрани

— Вахе Мурадян

2

Вам не потрібно використовувати ApplicationAdapter. І ApplicationAdapter, і гра реалізують інтерфейс ApplicationListener. Клас адаптерів - це просто клас, який забезпечує реалізацію скелета для інтерфейсу, тому вам не доведеться захаращувати свій код порожніми методами методу. Для використання екранів у грі ви викликаєте setScreen та передаєте клас, який реалізує інтерфейс екрана. Ви можете змусити заняття екрану брати об’єкт Ігри в конструкторі, щоб ви могли змінювати екрани в межах екрана.

— user3068350

1

так чому вони створили ApplicationAdapter, якщо він не має ніякого використання?

— Вахе Мурадян

2

@VaheMuradyan, користувач вже відповів, що вам не потрібно захаращувати код порожніми методами методів. При ApplicationListenerбезпосередній реалізації ви повинні надати всі необхідні методи, включаючи ті, які вам не потрібні (наприклад, pause()або resume()які не завжди використовуються). ApplicationAdapterтам для вашої зручності, тому вам не доведеться тримати порожні методи навколо. Це простий клас корисності, він не додає нових функціональних можливостей - він просто підтримує чистіший код (або коротший ).

— JustACluelessNewbie

1

Оскільки ApplicationAdapter та клас гри реалізують інтерфейс ApplicationListener, вони можуть бути використані майже взаємозамінно під час створення вашої гри. Якщо ви налаштовані на використання екрана, ніщо не заважає вам реалізувати їх з обома параметрами.

Ігровий клас має трохи більше накладні витрати з ним з допомогою екранів. Однак цей накладний розробка призначений для полегшення реалізації різних етапів / рівнів у грі. Важливо зазначити, що цей накладний мінімум.

ApplicationAdapter не має яких - небудь додаткових накладних витрат (тобто пряма реалізація ApplicationListener). Це дає вам більше контролю, оскільки вам доведеться робити все самостійно. Особисто я вважаю за краще використовувати ApplicationAdapters.

TL; DR: Ніякої реальної різниці між ними немає. ApplicationAdapter дає трохи більше контролю, а гра - трохи менше роботи.

— Бландерчіпс
джерело