Наиболее эффективная «архитектура» для многоуровневого 2D-приложения, использующего OpenGL на iPhone?

Question

Я работаю над приложением для iPhone OS, основным видом которого является 2-D представление OpenGL (это подкласс класса Apple EAGLView, в основном устанавливающий ортопроецированную 2D-среду), с которым пользователь взаимодействует напрямую.

Иногда (не всегда) я хотел бы визуализировать некоторые элементы управления поверх этого базового вида GL - думать как дисплей Heads-Up. Обратите внимание, что базовый вид внизу может прокручиваться / анимироваться, в то время как элементы управления должны быть зафиксированы на экране выше.

Я в общем хорош с представлениями Какао, и я довольно хорошо с CoreGraphics, но у меня хорошо работает с Open GL, и операции EAGLView (и его отношение к CALayers) довольно непрозрачны для меня. Я не уверен, как наиболее эффективно смешивать другие элементы (читай: лучшая производительность, меньше хлопот и т. Д.). Я знаю, что в крайнем случае я могу создавать и сохранять геометрию для всех других элементов управления и отображать их поверх моей базовой геометрии каждый раз, когда я рисую / меняю местами, и, таким образом, просто сохраняю все, что видит пользователь, в одном отдельном представлении. Но я менее уверен в других методах, таких как создание другого вида сверху (UIKit / CG или GL?) Или создание других слоев в моем отдельном представлении и т. Д.

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

Спасибо.

Answer 1

Создайте свой анимированный вид как обычно. Визуализируйте это к цели визуализации. Что это значит? Ну, обычно, когда вы «рисуете» многоугольники на экране, вы фактически делаете это на нормальной поверхности (первичной поверхности), которая в итоге оказывается той, которая в конечном итоге попадает на экран. Вместо рендеринга на поверхность экрана вы можете рендерить на любую старую поверхность.

Теперь ваш HUD. Будет ли это все время оставаться одним и тем же или изменится? Изменится только часть этого?

Если все это изменится, вам нужно будет сохранить всю геометрию и текстуры HUD в памяти, и вы должны будете визуализировать их на вашей «прокручиваемой» поверхности как обычно. Вы можете применить этот финальный композитный рендер к экрану. Я бы не стал сильно беспокоиться о проблемах и производительности - HUD вряд ли может быть таким же сложным, как фон. У вас будет максимум четыре квадрата текстур?

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

Если у вас была половина изменений, а половина нет, то технически вы можете предварительно визуализировать статические части, а затем визуализировать другие части по мере продвижения, но это более хлопотно, чем два других варианта.

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

Как я уже сказал, все зависит от того, какие ресурсы будет у вашего приложения.