Android, OpenGL и расширяющий GLSurfaceView?

12

Этот вопрос является частично техническим, частично мета, частично субъективным и очень специфическим:

Я разработчик инди-игр, работаю на Android, и в течение последних 6 месяцев я боролся и, наконец, сумел создать собственное приложение для 3D-игр для Android. Так что я подумал, что я буду надеяться на SO и помогать другим, борющимся с android и openGL-ES

Однако подавляющее большинство вопросов связано с расширением GLSurfaceView. Я сделал все мое приложение без расширения GLSurfaceView(и оно работает нормально). Я не вижу никакой причины расширять GLSurfaceViewбольшинство вопросов, с которыми я сталкиваюсь.

Хуже того, документация по Android подразумевает, что вы должны это сделать, но не дает подробного объяснения того, почему или в чем плюсы / минусы, а не в том, чтобы расширять и делать все через реализацию своих собственных, GLSurfaceView.Rendererкак я сделал

Тем не менее, огромное количество вопросов, в которых проблема связана исключительно с расширением GLSurfaceView, заставляет меня задуматься, есть ли на самом деле какая-то действительно веская причина для того, чтобы делать это так, как я это делал (и предлагать в своих ответах другим сделать).

Итак, я что-то упускаю? Должен ли я прекратить отвечать на вопросы в то же время?

Android openGL документация

android opengl

— Ложка большого пальца
источник

хороший вопрос, который я заинтересован в ответе.

— Tofeeq

Одну причину, почему расширение GLSurfaceView можно найти здесь: gamedev.stackexchange.com/questions/12629/… Не осознавая этого, я фактически уже обошел проблемы, о которых говорилось в этом вопросе, в моем собственном приложении, перезагрузив текстуры и т. Д.onResume()

— Spoon Thumb

2

У меня есть очень минимальное расширение для меня GLSurfaceView, и большая часть мудрости принадлежит моей реализации GLSurfaceView.Renderer. У меня были следующие три причины использовать обертку для GLSurfaceView:

База не GLSurfaceViewдает возможности вернуть Rendererэкземпляр. У меня есть несколько поверхностей, и когда я получаю событие пользовательского интерфейса для одной из них, я хочу передать команду соответствующему средству визуализации. Итак, я перезаписываю setRendererи сохраняю ссылку в моем расширенном классе.
GLSurfaceView.Rendererне получает уведомления для onDetachedFromWindow()или surfaceDestroyed(). Это вызвало некоторые проблемы в моей реализации. Мое расширение GLSurfaceViewпереопределяет эти методы и сообщает mRenderer . Это возможно из-за §1 .
Некоторые методы добавляются только для добавления try { super.чего ; } catch() { log(угодно) } . Например, queueEvent()сгенерирует, если Renderer не установлен; но для меня нормально просто игнорировать такие несоответствия графика.

— Алекс Кон
источник

Я тоже начал это делать, хотя вопрос в большей степени нацелен на то, почему вы можете поместить действительную логику в расширенную, GLSurfaceViewа не в GLSurfaceView.Renderer. Хотя в пункте 1 я сохраняю визуализатор как переменную в моей деятельности. В теории я могу получить его из любой точки литья контекста: ((MyActivity)view.getContext()).getRenderer(). Возможно, немного более опасным, поскольку контекстный объект не обязательно может бытьMyActivity

— Spoon Thumb

Это хорошо, если у вас есть один рендер. Но, как я уже говорил, у нас много рендеров, и они подключаются к разным поверхностным панелям - беспорядок!

— Алекс Кон

0

По крайней мере, одна из веских причин для расширения GLSurfaceView - это возможность создавать его экземпляры непосредственно из XML-файла макета, как и любой другой виджет:

    <RelativeLayout ... >
      <com.example.MyGlSurfaceView
        android:id="@+id/my_view"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_centerInParent="true"
      />
     </RelativeLayout>

— Амир Увал
источник

1

Вы можете сделать это в любом случае, используя

<android.opengl.GLSurfaceView  		android:id="@+id/graphics_glsurfaceview1"  		android:layout_width="fill_parent"  		android:layout_height="fill_parent" 	/>

— Spoon Thumb

Хорошая точка зрения. Разница в том, что в моем примере платформа Android раздувает и настраивает все без дополнительных строк кода. Ваш метод - больше кода, но гибкий для замены реализации. Кроме того, оба способа кажутся похожими.

— Амир Увал

-1

Ну ... GLSurfaceView, как я уверен, вы заметили, просто оболочка для общего блага. Он включает в себя всю функциональность, необходимую для рендеринга с помощью opengl, и имеет возможность красиво интегрировать ее с иерархией представления Android.

Вы не предоставили свой вариант, поэтому его невозможно сравнить, но я надеюсь, что вы создали другой поток для рендеринга, как это делает GLSurfaceView, иначе ваш пользовательский ввод может запаздывать.

Итак, еще раз: GLSurfaceView предоставляет новый поток для рендеринга, так что вам не нужно беспокоиться о задержке пользовательского ввода

— Greg
источник

2

Да, но GLSurfaceViewделает это (запускает поток рендеринга), даже если вы не расширяете его. Я использую GLSurfaceView, но я не расширяю это. Я спрашиваю, какая польза от его расширения и переопределения различных методов в нем, в отличие от просто иметь все вRenderer

— Ложка Thumb

хорошо, я попробовал :) Я мог бы изучить это позже, теперь я также заинтересован!

— Грег