FrameBuffers с шаблоном GLSurfaceView в OpenGLES 1.1 на Android ndk

в Android NDK можно ли заставить OpenGL ES 1.1 работать с типичным шаблоном GLSurfaceView на стороне java (переопределение методов из GLSurfaceView.Renderer onDrawFrame, onSurfaceCreated и т. д.) при использовании на стороне C++ буферов кадра, цвета и глубины и ВБО?

Я пытаюсь создать их, используя это:

void ES1Renderer::on_surface_created() {
    // Create default framebuffer object. The backing will be allocated for the current layer in -resizeFromLayer
    glGenFramebuffersOES(1, &defaultFramebuffer);
    glBindFramebufferOES(GL_FRAMEBUFFER_OES, defaultFramebuffer);

    // Create color renderbuffer object.
    glGenRenderbuffersOES(1, &colorRenderbuffer); 
    glBindRenderbufferOES(GL_RENDERBUFFER_OES, colorRenderbuffer);
    glFramebufferRenderbufferOES(GL_FRAMEBUFFER_OES, GL_COLOR_ATTACHMENT0_OES, GL_RENDERBUFFER_OES, colorRenderbuffer);

    // create depth renderbuffer object.
    glGenRenderbuffersOES(1, &depthRenderbuffer);
    glBindRenderbufferOES(GL_RENDERBUFFER_OES, depthRenderbuffer);
    glFramebufferRenderbufferOES(GL_FRAMEBUFFER_OES, GL_DEPTH_ATTACHMENT_OES, GL_RENDERBUFFER_OES, depthRenderbuffer);
}

Однако кажется, что это не соответствует контексту, который, я думаю, создается при инициализации GLSurfaceView и рендерера (сторона Java).

Я не эксперт ни в NDK, ни в OpenGLES, но мне нужно портировать iOS-приложение, использующее OpenGL ES 1.1, и я стремлюсь повторно использовать как можно больше кода. Поскольку приложение также использует компоненты пользовательского интерфейса для конкретной платформы (кнопки, списки и т. д.), при рисовании GL-графики я подумал, что это будет лучший способ. Однако сейчас я рассматриваю возможность использования нативной активности, хотя я не уверен, каковы будут отношения с другими компонентами Java.


c++ android-ndk opengl-es glsurfaceview native-activity
person Jserra    schedule 26.06.2014    source источник

Ответы (1)


arrow_upward
6
arrow_downward

Абсолютно да. Стандартный подход заключается в том, что вы создаете GLSurfaceView, как при использовании OpenGL из Java, создаете и подключаете свою реализацию GLSurfaceView.Renderer и позволяете запуститься потоку рендеринга.

Из ваших методов Renderer, таких как onSurfaceCreated() и onDrawFrame(), теперь вы можете вызывать функции JNI, которые вызывают функции в вашем собственном коде. В этих нативных функциях вы можете делать любые вызовы OpenGL API, какие душе угодно. Например, в функции, которую вы вызываете из onSurfaceCreated(), вы можете создать несколько объектов и установить некоторое начальное состояние. В функции, которую вы вызываете из onSurfaceChanged(), вы можете настроить область просмотра и проекцию. В функции, которую вы вызываете из onDrawFrame(), вы выполняете рендеринг.

Вы даже можете выполнять вызовы OpenGL как из Java, так и из собственного кода. Java OpenGL API — это всего лишь очень тонкий слой вокруг нативных функций. Не имеет значения, вызываются ли функции из собственного кода или через Java API.

Единственное, на что вам нужно обратить внимание, это то, что вы вызываете весь собственный код, который вызывает вызовы API OpenGL из GLSurfaceView.Renderer реализаций onSurfaceCreated(), onSurfaceChanged() и onDrawFrame(). Когда эти методы вызываются, вы находитесь в потоке рендеринга и имеете текущий контекст OpenGL. Если собственный код OpenGL вызывается откуда-то еще, есть вероятность, что вы находитесь в неправильном потоке и/или у вас нет текущего контекста OpenGL.

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

person Reto Koradi    schedule 27.06.2014