OpenGL ES

glEnableClientState - это же ffp. А у вас es 2.0, там нет ничего, связанного с fixed-function pipeline.

Неплохой старт можно получить тут - http://www.open.gl

Но ведь в спецификации OpenGL ES 1.1 такая функция есть https://www.khronos.org/opengles/sdk/1.1/docs/man/

А в ES 2.0 https://www.khronos.org/opengles/sdk/docs/man/ и правда не вижу. Но разве вторая версия - не надстройка над первой? Или это отдельные, по-разному работающие системы?

Тем более в Android.mk присутствует такая строчка: LOCAL_LDLIBS := -lGLESv1_CM -lGLESv2 -llog.То есть подключаются библиотеки и 1 и 2 версий, разве не должно тогда работать?Я явно что-то не понимаю...

используя CrystaxNDK и библиотеку SDL2

Я правильно понял что в данном случае получается кроссплатформенная (в плане Android + linux) реализация?

А, имеется в виду, что нужно использовать Shading language?

Агась. Просто готовлю себе базу из SDL и OpenGL, от которой смогу отталкиваться на Windows/Linux/Android. На десктопах запустил, а тут фигушки(

Но ведь в спецификации OpenGL ES 1.1 такая функция есть

А в 2.0 нет.

Но разве вторая версия - не надстройка над первой? Или это отдельные, по-разному работающие системы?

Нет. Но железо, умеющее ES 2.0, умеет и 1.х. Но тогда вам и нужно его использовать как 1.х.

Тем более в Android.mk присутствует такая строчка: LOCAL_LDLIBS := -lGLESv1_CM -lGLESv2 -llog.То есть подключаются библиотеки и 1 и 2 версий, разве не должно тогда работать?Я явно что-то не понимаю...

Это не имеет никакого отношения к инициализируемой версии.

А, имеется в виду, что нужно использовать Shading language?

Имеется ввиду, что в GL ES 2.0 и выше не является ffp. Все через шейдеры.

Я дал ссылку, почитайте пару параграфов - их достаточно для понимания что и как делать. Там подробно и с пояснениями все.

Все через шейдеры

Ох уж эти извращенцы! Лишь бы GLU/GLUT не использовать! А между тем, даже для жабоскриптика есть GLU!

Ок, всем спасибо.

GLU

устаревшее Г, которое годится только для студентов

GLUT

малоюзебальная херня для демок

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

«Обертки», которые ты хочешь - для даунов-ретроградов.

Для OpenGL существуют нормальные платформеные привязки разного уровня абстракции - egl, sfml, glfw, sdl2.

идиотизмом под названием «шейдеры»

Идиотизм - это отрицать шейдеры. Примерно такого же уровня как отрицание НТР. Хочешь песочницу - добро пожаловать в darkbasic.

Если тебе просто данные визуализировать, то есть специальные либы и софт.

2015
неиронично отвечать Eddy_Em

Ох уж эти извращенцы! Лишь бы GLU/GLUT не использовать!

И какая связь между шейдерами и мертвым хелпером а-ля glut? Очередное сравнение теплого с мягким.

малоюзебальная херня для демок

Эта херня еще и deprecated начиная с os x 10.9.

Которыми можно пользоваться точно так же просто, а не извращаться с идиотизмом под названием «шейдеры»?

Неужели есть апельсины вкуснее яблок?

Мне тупо отображать картинку, чтобы ее можно было тудым-сюдым двигать и увеличивать/уменьшать. Ну и иногда еще всякие графики рисовать.

есть специальные либы и софт

Нету. Либо я про такую прелесть не знаю. Но что-то готового не встречал.

http://mathgl.sourceforge.net/doc_en/2D-samples.html#g_t2D-samples

Знаю про mathGL, но в моем случае оно не подходит никак.

Вот, скажем, надо мне с веб-камеры показывать видео с какими-то дополнительными данными и иметь возможность увеличить картинку и подвигать туда-сюда. MathGL мне вряд ли в этом поможет. Вот — простой велосипед, который делает то, что мне нужно: кажет картинку. Еще добавлю движение (забыл про это) и буду использовать в следующем велосипеде (надо по-быстрому навелосипедить расширение к моему велосипеду, который фитсы с USB-ПЗСки забирает: хочется иметь возможность в непрерывном режиме щелкать кадры и не сохранять их, а отображать на экране, чтобы можно было приборы фокусировать и юстировать).

Ох уж эти извращенцы! Лишь бы GLU/GLUT не использовать! А между тем, даже для жабоскриптика есть GLU!

Ну, увы - не увы, а ffp официально считается устаревшим и менее эффективнымhttps://www.opengl.org/wiki/Fixed_Function_Pipeline

Это не имеет никакого отношения к инициализируемой версии

Ммм, а есть предположения, как принудительно инициализировать конкретную версию....или для ответа надо NDK перелопачивать?

Нужно быть полным кретином, чтобы вместо божественной сишечки писать гуевый софт на ассемблере. Ну, ты понял. Рисовать для каждой задачи рейтрейсинг в шрейдерах вместо того, чтобы GLU/GLUT использовать — это идиотизм чистой воды! Ты вместо 1-2 страниц кода напишешь 20, да еще и убьешь кучу времени!!!

Я не понимаю разработчиков опенгля: они упоролись вообще в крайняк!

Боюсь я пока толком не знаю GLSL чтобы заявлять четкое мнение, может потом.

Нужно быть полным кретином,
Рисовать для каждой задачи рейтрейсинг в шрейдерах вместо того, чтобы GLU/GLUT использовать

Нужно быть полным кретином, что бы сравнивать теплое с мягким.

Ммм, а есть предположения, как принудительно инициализировать конкретную версию....или для ответа надо NDK перелопачивать?

В android-ndk есть пример инициализации.

Погуглил про GLSL, ужас. Это как раз то, что я терпеть ненавижу и избегаю!

С трудом верится, что разрабы стандарта OpenGL разрабатывали - разрабатывали, разрабатывали-разрабатывали и внезапно упоролись и придумали GLSL.Ну едва ли. Посмотри, кто в Khronos group входит. Да и в ссылке, что я привел, черным по белому написано, что с развитием вычислительных возможностей, применять ffp - вчерашний день. То что это не так очевидно, и где-то нужно перепрограммировать свой мозг для нового подхода - ну и что теперь?Сам С++ каким-то людям покажется муторным и сложным.Однако это не изменяет его преимуществ.

P.S. А современный DirectX какой подход использует?

Сам С++ каким-то людям покажется муторным и сложным

Я считаю это совершенно ненужной дрянью.

P.S. А современный DirectX какой подход использует?

Спроси на винфаке.

Я считаю это совершенно ненужной дрянью

Ты только про GLSL или про C++ тоже 0_0?

Рисовать для каждой задачи рейтрейсинг в шрейдерах вместо того, чтобы GLU/GLUT использовать — это идиотизм чистой воды!

Ты бы поближе ознакомился с GLSL прежде чем критиковать.Трассировка лучей тут ни при чем.Даже современный OpenGL использует подход «растеризация», а не «трассировка лучей».Банальный перевод «shader» как «затенитель» вводит тебя в заблуждение. Конкретно в современном OpenGL шейдер - это программа-настройка узла конвеера рендеринга (того самого pipeline), а вовсе не пресловутая трассировка лучей.Так что современный opengl это тот же ffp - только гибкий и настраиваемый. И никаких 20 страниц кода на простейшие задачи не нужно.Это можно понять, прочитав меньше тех же 20 страниц этой книги

http://rutracker.org/forum/viewtopic.php?t=4418099

Загружаются простейшие шейдеры и простейший рисунок быстро пишется.

Про С++ тоже.

Я с шейдерами намучился, когда webGLU писал. Для того, чтобы можно было просто по-человечески, как в настоящем GLU, рисовать объемные объекты и подсвечивать их всяко-разно, пришлось забульбенить рейтрейсинг в шейдере, т.к. в оригинале webgl свой рейтрейсинг не умеет.

А ведь рейтрейсинг — такая часто используемая вещь, что могли бы и стандартизировать, как в настоящем OpenGL, когда ты рисуешь себе поверхности, задаешь их характеристики (отражение/рассеяние/поглощение), располагаешь в пространстве N источников освещения (и каждому тоже свою характеристику задаешь), ставишь "камеру" в нужную тебе точку и — вуаля! Опенгль тебе все кошерненько нарисовал без необходимости ломать в течение месяца голову, отражая все тонкости трассировки лучей в шейдере.

Да, я, конечно, понимаю, что на самом нижнем уровне именно шейдеры используются: CUDA получает код шейдера и в дофига потоков обрабатывает его, в результате чего быстренько картинка и рисуется (ну или если нет видеокарты, то ЦП в несколько потоков тупит). Но вот самому писать то, что уже 100500 раз описано и расписано — ну уж, увольте!

Попробуй вот это посмотреть: https://www.opengl.org/registry/specs/ARB/debug_output.txt может что скажет.

про gstreamer не слышал? зачем тебе дергать opengl чтобы отобразить картинку?

Затем, что это самый простой и шустрый вариант. А всякое дерьмище вроде gstreamer'а я в свою систему ставить не собираюсь!

такая часто используемая вещь, что могли бы и стандартизировать, как в настоящем OpenGL, когда ты рисуешь себе поверхности, задаешь их характеристики

Ты сам-то рейтрейсинг хоть раз реализовывал умник? Подходы к реализации рейтрейсинга такие все одинаковые, что там уже можно что-то стандартизировать?

Рисовать для каждой задачи рейтрейсинг в шрейдерах вместо того, чтобы GLU/GLUT использовать — это идиотизм чистой воды!

универсального подхода к реализации рилтаймового рейтресинга не существует и тем более не существовало ранее, когда стандартизировался opengl.

вообще прекрати нести эту ахинею тут, смущаешь только своим невежством новичков.

Говорю же: в webGLU реализовывал простую трассировку. Знаю, что подходов много, но есть базовый (даем свойства материала, свойства и положение источника света и камеры — вуаля!).

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

Поясни,пожалуйста, что по твоему мнению шейдер в современном OpenGL (дай определение, а не свое отношение к нему), а то у меня ощущение, что говорим о разных вещах.

Есть слои совместимости (glshim, regal).

Спасибо)

Гляну)

Инициализировать в яве

А ещё eglBindAPI

Вот такое говно

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

Потом приведу старый и новый код.

Подскажите, пожалуйста, чем в GLSL отличаются типы mat2 и mat2x2, mat3 и mat3x3, mat4 и mat4x4?У меня сложилось впечатление, что абсолютно ничем...

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