LibGDX Game против 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. Полезно расширить игру, если вы планируете использовать интерфейс Screen в своей игре, однако некоторые разработчики могут захотеть использовать другой подход и по-своему управлять управлением экраном. В этом случае они расширят ApplicationAdapter.

Лично мне нравятся мои классы для реализации пользовательского интерфейса Updatable и / или Drawable, так как я разделяю свой метод рендеринга на update и draw. В этом случае использование Screen приведет к потере цели, поскольку интерфейс содержит метод рендеринга.

— driima
источник

1

Класс Game реализует интерфейс ApplicationListener и является просто классом, разработанным для облегчения переключения между различными экранами. Когда вызывается метод в ApplicationListener, класс Game заботится о его делегировании на текущий установленный экран.

— user3068350
источник

1

но когда я должен использовать ApplicationAdapter? И как мне здесь использовать экраны.

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

2

Вам не нужно использовать ApplicationAdapter. И ApplicationAdapter, и Game реализуют интерфейс ApplicationListener. Класс адаптера - это просто класс, который предоставляет реализации скелета для интерфейса, поэтому вам не нужно загромождать свой код пустыми телами методов. Чтобы использовать экраны с Game, вы вызываете setScreen и передаете класс, который реализует интерфейс Screen. Вы можете заставить свои классы экрана брать объект Game в конструкторе, чтобы вы могли менять экраны на экране.

— user3068350

1

так почему они создали ApplicationAdapter, если он не имеет никакого смысла?

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

2

@VaheMuradyan, пользователь уже ответил, что: вам не нужно загромождать свой код пустыми телами методов. Когда вы реализуете ApplicationListenerнапрямую, вы должны предоставить все необходимые методы, включая те, которые вам не нужны (например, pause()или resume(), которые не всегда используются). ApplicationAdapterдля вашего удобства, поэтому вам не нужно хранить пустые методы. Это простой служебный класс, он не добавляет никаких новых функциональных возможностей - он просто делает ваш код чище (или короче ).

— JustACluelessNewbie

1

Поскольку ApplicationAdapter и класс Game реализуют интерфейс ApplicationListener, их можно использовать практически взаимозаменяемо при создании игры. Если вы настроены на использование Screen, ничто не помешает вам реализовать их с обоими вариантами.

Класс Game имеет немного больше накладных расходов при использовании Screens. Тем не менее, эти издержки призваны упростить реализацию различных этапов / уровней в вашей игре. Важно отметить, что эти накладные расходы минимальны.

ApplicationAdapter не имеет каких - либо дополнительных накладных расходов (то есть прямая реализация ApplicationListener). Это дает вам больше контроля, поскольку вы должны делать все самостоятельно. Лично я предпочитаю использовать ApplicationAdapters.

TL; DR: никакой разницы между ними нет. ApplicationAdapter дает вам немного больше контроля, а игра немного меньше работы.

— Blunderchips
источник