Разброд и шатание наблюдается в стане геймеров в связи с 3D-ускорителями. А точнее, в связи с тем, что различные игры поддерживают различные типы акселераторов. Конечно, существует Voodoo, совместимый абсолютно со всеми играми, но от этого никому не легче. Voodoo уже давно не представляется столь идеальным, как в те времена, когда он только появился. По правде сказать, по сравнению с RIVA 128 и i740, этот чипсет давно уже выглядит полным отстоем как по быстродействию, так и по качеству рендеринга. Voodoo 2 же еще только предстоит сражение за свой сектор на рынке с такими серьезными соперниками, как, например, TNT.

Однако Voodoo покупают. Причина состоит в том, что это единственный чипсет, поддерживающий все три наиболее распространенные на сегодняшний день API для описания трехмерных сцен - D3D (Microsoft), Glide (3dFx) и OpenGL (SGI). Остальные приличные чипсеты поддерживают только последние два. Это потому, что API Glide разработан специально для Voodoo и является чем-то сравнимым по уровню с ассемблером для этого чипсета, а, следовательно, на других чипсетах реализован быть не может. Программировать же под Glide создателей игр заставляляло до недавнего времени то обстоятельство, что D3D просто не предоставлял нужных им возможностей, усложнял разработку и снижал производительность.

Первым человеком, решившим изменить такое положение вещей, стал небезызвестный господин Кармак. Замыкаться на Voodoo ему не хотелось, а попытка переписать Quake под D3D повергла его в уныние. Тогда он взялся за OpenGL, и дело пошло!

Почему никто не пробовал воспользоваться OpenGL раньше? Когда первые 3D-ускорители только появились, профессиональный стандарт OpenGL казался слишком крутым для PC. А потом не было прецедента. На сегодняшний же день уже есть карты, способные реализовать многие возможности OpenGL (например, на чипсете RIVA 128), да и прецедент создан. Сие обстоятельство заставило многих разработчиков пересмотреть свои позиции по поводу выбора API для своих будущих проектов. Скорее всего, все 3D-action, которые должны выйти в ближайшее время, будут использовать именно OpenGL.

На эту мысль наводит письмо, текст которого можно прочесть на врезке. Как видим, это обращение к Microsoft практически всех известных людей, связанных с разработкой 3D-action. И что уж совсем неожиданно, в данном случае корпорация отступила от своего железного принципа продвижения только своих продуктов и заявила о том, что готова поддержать OpenGL в рамках Windows! Уже сейчас корпорация ведет совместно с SGI разработку так называемого проекта "Фаренгейт", призванного совместить под одной крышей OpenGL и D3D.

Честно говоря, я, как обладатель карты на RIVA 128, очень надеюсь, что этот проект положит конец беспределу Glide и сделает OpenGL стандартом и для PC. Тем более, что это очень хороший и проверенный API.

Откуда пошел OpenGL? Когда-то давным-давно (точную дату, к сожалению, назвать не могу) комапания Silicon Graphics, известная своими наработками в области профессиональной компьютерной анимации, поняла, что для представления и обработки трехмерных сцен необходим стандарт. До этого момента каждая компания, выпускающая ПО для трехмерной анимации или САПР, использовала свой собственный API (впрочем, отчасти такая ситуация сохраняется и по сей день). И проект был создан. А в 1992 году SGI начала формирование группы компаний (Architecture Review Board - ARB), которые поддерживают OpenGL в качестве стандарта. В настоящее время членами ARB являются Digital Equipment, Evans & Sutherland, Hewlett-Packard, IBM, Intel, Intergraph, Silicon Graphics, Sun Microsystems и, конечно, Microsoft.

По сути своей OpenGL является API (программным интерфейсом), определяющим несколько десятков процедур. Часть из них предназначена для описания трехмерных объектов и манипулирования ими, другая часть - для управления тем, как эти объекты выглядят (визуализации). Практически все процедуры OpenGL работают с кадровым буфером. Определение объекта в OpenGL обозначает обычно немедленное его отображение. В принципе, OpenGL не требует обязательного применения аппаратных ускорителей, главное - чтобы все процедуры, определенные стандартом, были реализованы. Все, что не может быть реализовано аппаратно, реализуется за счет центрального процессора. Но поскольку процедуры OpenGL достаточно ресурсоемки, на практике всегда используется аппаратное ускорение. Различные системы могут аппаратно реализовать различные функции OpenGL, остальные реализуются за счет CPU.

В OpenGL используется модель "клиент-сервер". Приложение передает команды GL-серверу, который управляет кадровым буфером. В самом простом случае сервер - это определенное программное обеспечение на той машине, где выполняется приложение. Однако это может быть и удаленная машина (таким образом, в самую основу стандарта заложена возможность сетевого рендеринга). Один сервер может управлять несолькими кадровыми буферами и, таким образом, поддерживать несколько клиентов.

Описание объектов в OpenGL происходит на основе примитивов. В OpenGL не существует способа задать сложный объект при помощи одной операции - вместо этого его надо описать как совокупность простых. Такими объектами в OpenGL являются точка, отрезок линии, треугольник и прямоугольник.

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

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

В связи с этим связывание данных в OpenGL происходит на момент вызова. То есть даже если в операции используются данные, выбираемые при помощи указателя, их вычисление происходит на момент вызова команды клиентом и больше не модифицируется (за исключением случаев, когда данные модифицируют предшествующие GL-команды).

Рассмотрим логическую архитектуру GL-системы (она изображена на диаграмме).

Команды поступают в систему слева. Некоторые из них специфицируют примитивы, другие - способ их отображения. Большинство команд аккумулируются в списке (display list) для дальнейшего выполнения (см. выше). Однако если система свободна, команды могут следовать непосредственно на исполняющее устройство.

На первом этапе команды поступают на вычисляющее устройство (evaluator), где находятся координаты кривых и поверхностей путем полиномиальной аппроксимации входных значений. На следующем этапе проделываются операции над геометрическими примитивами (вершинами, полигонами и т.д.). Здесь рассчитывается освещенность примитивов и объемные координаты приводятся к виду, пригодному для проведения следующего этапа - растеризации. На этом этапе вырабатываются серии адресов экранного буфера и их значений, связанных с отражением примитивов. Каждая серия затем передается на этап пофрагментной обработки, где они проходят завершающую обработку (например, согласование присвоенных значений цветов с цветами текущей палитры), после чего происходит отображение.

Кроме того, можно обойти все эти сложные процедуры и "рисовать" непосредственно в фреймбуфере или получать информацию о цвете пикселов непосредственно.

Денис МАРГОЛИН,
pb8266@belsonet.net

Открытое письмо профессиональных разработчиков игр к компании Microsoft.

Мы, нижеподписавшиеся профессиональные разработчики игровых программ, обращаемся в Microsoft с предложением активизировать поддержку OpenGL: осуществить связку DirectDraw с OpenGL и реализовать MCD-драйверы для Windows 95 под OpenGL, а также продолжить работы по совершенствованию этого API путем поддержки как существующих расширений OpenGL, так и будущих расширений в рамках стандартов ARB. Как разработчики, мы уверены в том, что выбор 3D API для разработки игр должен определяться нами.

Нам необходим стандартный 3D API для уверенности в открытости техники программирования, и мы, люди, которые реально разрабатывают игры, лучше понимаем, какой API использовать и какой не использовать. Открытость техники программирования имеет решающее значение для индустрии разработки игр, где успехом является выпуск лучшей игры с 3D-технологией как можно быстрее. Мы осознаем, что Microsoft должен принять участие в разработке технически полного окружения для разработчиков игр, так как Microsoft контролирует рынок операционных систем для PC, и мы уверены в возможности осуществить это. Результатом будет оживление рынка игр для среды Windows.

Подписи:

Kill Baldwin, Вrian Hook, William Scarboro, Sean Barrett, Andrew Howe, Jason Shankel, Ken Birdwell, Brent Iverson, Zachary Simpson, Seamus Blackley, Rick Johnson, David Stafford , Stefan Boberg, Dave Kaemmer, Tim Sweeney, John Carmack , Donavon Keithley , Chris Taylor , Glenn Corpes, Jason Leighton, Dave Taylor, Steve Crane, John Lemberger, Trey Taylor , Mark Dochterman, Peter Lincroft , Cameron Tofer, Jim Dose, Mike Linkovich, Matt Toschlog, James Fleming, Jonathan Mavor, Neall Verheyde, Rick Genter, Stan Melax, Charlie Wallace, Ed Goldman, John Miles, Kevin Wasserman, Chris Green, Doug Muir, Patrick Wilkinson, Robin Green, Casey Muratori, David Wu, Mike Harrington, John Nagle, Pat Wyatt, Ryan Haveson, Mike Newhall, Billy Zelsnack, Chris Hecker, Jay Patel, Greg Zeschuk, Lawrence Holland, John Romero