Версии OpenGL и gpus - какая совместимость там?

Исходя из моего опыта OpenGL, кажется, что «нацеливание» на данную версию - это просто доступ к различным расширениям, которые были добавлены для этой версии. Таким образом, единственная причина, по которой вы "нацеливаетесь" на OpenGL версии 3, заключается в том, что вы хотите использовать некоторые из расширений, которые являются новыми для версии 3. Если вы действительно не используете расширения версии 3 (если вы просто делаете базовые вещи OpenGL) , то вы, естественно, не ориентируетесь на версию 3.

В Visual Studio вы всегда связываете свое приложение с opengl32.lib, и opengl32.lib не изменяется в разных версиях OpenGL. OpenGL вместо этого использует wglGetProcAddress () для динамического доступа к расширениям / версиям OpenGL во время выполнения, а не во время компиляции. А именно, если данный драйвер не поддерживает расширение, тогда wglGetProcAddress () вернет NULL во время выполнения, когда будет запрошена процедура этого расширения. Поэтому в вашем коде вам нужно будет реализовать логику, которая обрабатывает случай возврата NULL. В простейшем случае вы можете просто распечатать ошибку и сказать: «Эта функция недоступна, поэтому эта программа будет вести себя ...». Или вы можете найти другие альтернативные методы, позволяющие сделать то же самое, без использования расширения. По большей части вы получите NULL-возврат от wglGetProcAddress только в том случае, если ваше приложение работает на старом оборудовании / драйверах, которые не поддерживают версию OpenGL, в которую добавлено расширение, которое вы ищете. Однако в будущем вы захотите быть в курсе тех вещей, которые в новых версиях OpenGL решили не рекомендовать. Я не слишком много читал о спецификации 3.1, но, видимо, они повторное введение модели устаревания, в которой старые технологии / расширения могут быть объявлены устаревшими, что откроет дверь для нового оборудования / драйверов, чтобы больше не поддерживать устаревшие расширения, и в этом случае wglGetProcAddress снова вернет NULL для этих расширений. Поэтому, если вы добавите логику для обработки возврата NULL в wglGetProcAddress (), вы все равно будете в порядке даже для устаревших расширений. Возможно, вам потребуется реализовать лучшие альтернативы или сделать новые расширения по умолчанию.

Что касается заголовков API с поддержкой версий, изменения в заголовках в основном представляют собой просто изменения, позволяющие получить доступ к новым функциям, возвращаемым wglGetProcAddress ( ). Поэтому, если вы включите заголовок API для версии 2, все будет в порядке, если вам нужны только расширения для OpenGL 2. Если вам нужно получить доступ к функциям / расширениям, которые были добавлены в версии 3, вы просто замените заголовок версии 2 заголовком версии 3, который просто добавляет некоторые дополнительные определения типов указателей на функции, связанные с новыми расширениями, чтобы при вызове wglGetProcAddress ( ), вы можете привести возвращаемое значение к правому указателю функции. Пример:

PFNGLGENQUERIESARBPROC glGenQueriesARB = NULL;

...

glGenQueriesARB = (PFNGLGENQUERIESARBPROC)wglGetProcAddress("glGenQueriesARB");

В приведенном выше примере определение типа для PFNGLGENQUERIESARBPROC определено в заголовках API. Я полагаю, что glGenQueriesARB был добавлен в 1.2, поэтому мне понадобятся как минимум заголовки API 1.2, чтобы получить определение PFNGLGENQUERIESARBPROC. Это действительно все, что делают заголовки.

Еще одна вещь, которую я хочу упомянуть о 3.1. По-видимому, в версии 3.1 они отказываются от многих функций OpenGL, которые моя компания использовала довольно повсеместно, включая списки отображения, механизмы glBegin / glEnd, и режим рендеринга GL_SELECT. Я не очень разбираюсь в деталях, но я не понимаю, как они могут это сделать, не создавая новый opengl32.lib для связи, потому что кажется, что большая часть этих функций встроена в opengl32.lib, и недоступен через wglGetProcAddress. Кроме того, собирается ли Microsoft включать этот новый opengl32.lib в свои версии Visual Studio? У меня нет ответа на эти вопросы, но я думаю, что, хотя 3.1 не поддерживает его, эта функциональность будет существовать еще долгое время. Если вы продолжите связываться с вашим текущим opengl32.lib, он должен продолжать работать почти бесконечно, хотя в какой-то момент вы можете потерять аппаратное ускорение. Подавляющее большинство руководств по OpenGL, доступных в Интернете, используют методы glBegin / glEnd для рисования примитивов. То же верно и для GL_SELECT, хотя многие устройства больше не ускоряют режим рендеринга GL_SELECT. Даже в учебнике opengl.org используются предположительно устаревшие методы glBegin / glEnd. И мне еще предстоит найти учебное пособие по началу работы, в котором используются только функции 3.1, избегая устаревших функций (конечно, если кто-то знает о них, свяжите меня с ним). В любом случае, хотя кажется, что в 3.1 было отброшено много старого для всего нового, я думаю, что старые вещи еще будут существовать довольно долго.

Короче говоря, вот мой совет. Если ваши потребности в OpenGL просты, просто используйте базовые функции OpenGL. Массивы вершин поддерживаются в версиях 1.1 - 3.1, поэтому, если вы ищете максимальное время жизни и начинаете все заново, вероятно, вам следует использовать именно это. Тем не мение, Я считаю, что glBegin / glEnd и списки отображения все еще будут существовать какое-то время, даже если они устарели в версии 3, поэтому, если вы хотите их использовать, я бы не сильно беспокоился. Я бы избегал режима GL_SELECT для выбора в пользу альтернативного метода. Многие производители оборудования уже много лет считают GL_SELECT устаревшим, хотя он только что стал устаревшим в версии 3. В нашем приложении мы сталкиваемся с множеством проблем, когда он не работает на картах ATI и интегрированных картах GMA. Впоследствии мы просто реализовали метод выбора с использованием запросов окклюзии, который, похоже, решает проблему. Поэтому, чтобы сделать это правильно с первого раза, избегайте GL_SELECT.

Удачи.

Я бы избегал режима GL_SELECT для выбора в пользу альтернативного метода. Многие производители оборудования уже много лет считают GL_SELECT устаревшим, хотя он только что стал устаревшим в версии 3. В нашем приложении мы сталкиваемся с множеством проблем, когда он не работает на картах ATI и интегрированных картах GMA. Впоследствии мы просто реализовали метод выбора с использованием запросов окклюзии, который, похоже, решает проблему. Поэтому, чтобы сделать это правильно с первого раза, избегайте GL_SELECT.

Удачи.

Я бы избегал режима GL_SELECT для выбора в пользу альтернативного метода. Многие производители оборудования уже много лет считают GL_SELECT устаревшим, хотя он только что стал устаревшим в версии 3. В нашем приложении мы сталкиваемся с множеством проблем, когда он не работает на картах ATI и интегрированных картах GMA. Впоследствии мы просто реализовали метод выбора с использованием запросов окклюзии, который, похоже, решает проблему. Поэтому, чтобы сделать это правильно с первого раза, избегайте GL_SELECT.

Удачи.