Дороги, которые выбираем не мы

edc343232955cd588fc80f2be6992491

Direct3D, DirectSound3D, Glide, A3D, PVRSG, EAX, OpenGL. Вы знакомы с этой терминологией? Наши постоянные читатели, вероятно, без труда смогут продолжить этот список. Сегодня я хотел бы поговорить об интерфейсах. Точнее, об интерфейсах прикладных программ, или API (Application Progam Interface). Программисты пользуются этим термином испокон веку, а вот геймерам пришлось столкнуться с ним сравнительно недавно. Многолетней борьбе несовместимости с пользователями посвящается… Строгое определение API: совокупность средств и правил (процедур и их параметров), обеспечивающих взаимодействие прикладных программ с аппаратурой или ОС. Именно посредством API операционная система скрывает от приложений подробности работы конкретной железяки. В результате программист при разработке ПО освобождается от размышлений о специфике функционирования аппаратуры. Пользователи, в свою очередь, получают надежду на то, что совместимая с данной ОС железка будет жить в мире со всеми программами для этой операционной системы.

Дела давно минувших ОС

Первым подобием ОС для PC была MS-DOS. Многие эксперты вообще не признают за ней права называться операционной системой. Дело в том, что одна из важнейших функций ОС — скрытие от прикладных программ подробностей взаимодействия с аппаратурой. Операционная система должна предоставлять программам функции (API) для работы со всем необходимым железом. Например, текстовый редактор, запущенный в полноценной ОС, не обязан знать тип подключенного к компьютеру принтера. Ему достаточно сказать «Напечатай мне этот форматированный текст на том устройстве». Все заботы по переводу текста и шрифтов в понятный принтеру язык лежат на ОС, а не на ПО. Аналогично программы работают и с остальными устройствами (к примеру, с видеоадаптером, диском или джойстиком). Важно отметить, что работа с аппаратурой напрямую (то есть без использования функций ОС) не поощряется, а чаще всего просто запрещена. Старушка DOS, увы, ни в коей мере не соответствовала изложенным выше требованиям. Фактически это была библиотека функций для работы с файловой системой. Общаться с видеоадаптером, принтером, мышью и другими «нестандартными» устройствами программам приходилось самостоятельно. Отголоски тех времен слышны до сих пор: кому была бы нужна аппаратная совместимость с Sound Blaster Pro, если б DOS имела стандартный звуковой API? Развивая Windows, корпорация Microsoft постепенно дополняла ее новыми API, латая дыры старушки DOS. Появился, например, стандарт Windows Sound Systems, позволявший Windows — приложениям работать со звуком. Однако реальную привлекательность для разработчиков игр Windows приобрела только после появления DirectX. Этот комплект API предоставлял доступ ко всему необходимому игрушкам железу. Разработчики софта могли более не интересоваться типом подключенного к компьютеру джойстика и стандартами звуковых плат. Всей этой конкретикой занимался DirectX. Девелоперам нужно было лишь знать форматы вызовов нужного им компонента DirectX.

Догнать 3D

Все было бы прекрасно, не появись новый, непредвиденный Microsoft тип игрового железа. Речь, как вы уже догадались, об акселераторах 3D — графики. Гигант отреагировал логично, добавив в DirectX новый компонент, отвечающий за ускорение 3D — графики (Direct3D или, сокращенно, D3D). С многообразием поддерживаемых 3D — ускорителями функций поступили просто: функции поделили на «нужные» и «классово чуждые». Первые реализовали, вторые игнорировали. Причем 3D — ускоритель вовсе не обязан был поддерживать все известные Direct3D — функции. Любая D3D — игра могла получить от акселератора список знакомых ему 3D — функций и на основе этих данных решать, стоит ли связываться с аппаратурой либо считать все программно. Проблема такого подхода в том, что все непредусмотренные Microsoft функции через D3D попросту недоступны. Для того чтобы окончательно не отстать от бурно развивающейся отрасли, корпорации приходится ежегодно переписывать D3D, реализуя поддержку новых возможностей ускорителей. Но даже такая частота обновления API не успевает за прогрессом. Разработчики 3D — чипов для демонстрации всех возможностей своих детищ начали выпускать собственные интерфейсы и закрывать их, дабы врагам не досталось, зонтиком патентов. В результате мы получили кучу разношерстных API 3D — графики, несовместимых друг с другом и работающих только со строго определенными чипами.

Проиграли от этого все. Разработчики игр не знали, какой API выбрать для своего нового проекта. Чаще всего им приходилось идти на компромисс: разрабатывать игру для нескольких API. Однако больше всего неудобств отсутствие единого стандарта принесло нам, любителям игр. Для того чтобы определить, совместим ли наш ускоритель с данной игрой, нам пришлось разбираться в сути самого понятия API и особенностях конкретных интерфейсов. Иначе был риск купить 3D — акселератор, поддерживающий все используемые некоей игрой аппаратные функции, но не способный ускорить ее лишь из-за несовместимости с экзотическим API. То есть при выборе ускорителя приходилось учитывать не только его аппаратные достоинства (мощность, функциональную широту), но и активность его поддержки разработчиками игр (чисто маркетинговый фактор, не имеющий прямого отношения к качеству аппаратуры). Ситуация, откровенно говоря, абсурдна. Четко специфицированные API и аппаратные интерфейсы позволяют нам при покупке остального оборудования (например винчестеров, центральных процессоров, мониторов) не задумываться о популярности данной железяки у разработчиков софта. Так почему мы должны рассуждать об этом при покупке 3D — ускорителей? К сожалению, пока оптимизированные для фирменных API игры не потеряют актуальность, нам придется учитывать фактор «популярности». Новая напасть Однако вернемся к истории. Следующим барьером для Microsoft стали аппаратные акселераторы 3D — звука. История борьбы корпорации с этим наваждением весьма познавательна. Первый вариант API для 3D — аудио (DirectSound3D или, сокращенно, DS3D) появился в третьей версии DirectX. Этот интерфейс позволял играм позиционировать источники звука в 3D — пространстве и управлять их громкостью. При наличии в системе аппаратного ускорителя 3D — звука DS3D должен был использовать его. Производители звуковых плат с энтузиазмом поддержали выход универсального 3D — аудио — API и начали готовиться к разработке аппаратных DirectSound3D — акселераторов. Однако Microsoft преподнесла им неприятный сюрприз. За несколько месяцев до выпуска DirectX 3 корпорация объявила, что не позволит чужим алгоритмам заниматься аппаратной акселерацией DS3D. Microsoft разработала собственный алгоритм, который должен быть реализован в любой звуковой плате, претендующей на аппаратную акселерацию DirectSound3D. Видимо, таким образом корпорация пыталась получить полный контроль над развитием аппаратных акселераторов 3D — звука, дабы лично выбирать дорогу в светлое будущее, а не гоняться за непредсказуемым прогрессом. Сказать, что производители 3D — аудиоакселераторов были недовольны, значит, не сказать ничего. Каждый из них потратил годы на разработку собственных методов обработки 3D — звука, а Microsoft одним выпуском API предлагала отказаться от всех «нестандартных» (то есть отличных от предложенного корпорацией) алгоритмов. Вполне естественно, что ни один из производителей звуковых плат и чипов для них не поддержал почин Microsoft. Так как корпорация не планировала выпуск собственных звуковых чипов, DirectX 3 остался без аппаратных ускорителей 3D — звука. Несмотря на несколько неадекватную позицию Microsoft, разработчики звуковых чипов одобряли идею выпуска универсального API для 3D — звука. Некоторые из них начали искать обходные пути, позволяющие использовать собственные алгоритмы 3D — акселерации звука, сохраняющие совместимость с написанными для DS3D играми. Так, компании Aureal и VLSI разработали собственные API (названные A3D и Dev3D соответственно), перехватывающие часть функций DS3D и применяющие алгоритмы позиционирования фирм — разработчиков. В то же время группа IA — SIG 3DWG (Interactive Audio Special Interest Group s 3D Audio Working Group), состоящая из разработчиков 3D — аудиоалгоритмов и звуковых плат, также работала на два фронта. Во-первых, консорциум создал собственный API, полученный слиянием A3D с Dev3D и названный 3Dxp. Знакомая картина, не правда ли? На рынке опять возникло несколько несовместимых между собой API, выполняющих в сущности одни и те же функции. Хаос остановило одно важное событие. Дело в том, что IA — SIG 3DWG вел переговоры с Microsoft, убеждая корпорацию изменить свое отношение к 3D — аудиоалгоритмам сторонних фирм. К счастью, им удалось договориться. Вышедший летом 1997 года DirectX 5 включал обновленный DS3D, поддерживающий чужие алгоритмы акселерации 3D — звука. Более того, Microsoft пошла дальше, встроив в DS3D поддержку расширений. Их смысл таков: если некий акселератор 3D — звука поддерживает отсутствующую в DS3D уникальную функцию, разработчик платы может сделать ее (функцию) доступной, написав собственное расширение. Таким образом, все современные 3D — звуковые платы аппаратно ускоряют стандартные функции DirectSound3D, а некоторые из ускорителей имеют дополнительные возможности, доступные через расширения. Это существенно облегчает жизнь всем. Разработчики игр пишут для DS3D, добавляя, при желании, вызовы фирменных расширений. Даже если драйверы вашей звуковой платы не имеют требуемых игрой расширений, вы не лишитесь 3D — звука полностью, так как игрушка будет работать с DS3D. Рискну предположить, что многие фирменные API акселерации 3D — графики обязаны своим появлением именно отсутствию в Direct3D механизма расширений. Результат его реализации в DirectSound3D налицо: все современные 3D — аудио — API (EAX, A3D 2.0) не конкурируют с DS3D, а расширяют его функции. Да, это не мешает новым интерфейсам бороться друг с другом, однако минимальный набор эффектов пользователь получает при запуске на его 3D — аудиоакселераторе любой знакомой с 3D — звуком игры. Согласитесь, это уже немало.

Итоги

В заключение рассмотрим два возможных подхода к распространению API на примере EAX и A3D 2.0. Creative, разработавшая EAX, не стала закрывать его от конкурентов, предоставив любому разработчику 3D — аудиоакселераторов право писать EAX — драйверы для своих продуктов без каких-либо лицензионных отчислений. Aureal закрыл свой A3D 2.0 системой патентов и, более того, ввел специальный механизм идентификации, гарантирующий работоспособность этого API только со своими чипами (Vortex2). Абстрагируемся от технических достоинств EAX и A3D 2.0. Посмотрим, у какой из стратегий лицензирования больше шансов на выживание. Как вы считаете, какому API будет легче завоевать популярность у разработчиков софта: закрытому (то есть работающему с аппаратурой только одного производителя) или открытому (то есть живущему на широком спектре железяк от разных производителей)? Ответ, по-моему, очевиден. Я уверен, закрытым API не грозит продолжительная жизнь. Если владелец таких интерфейсов доминирует на рынке —у его детища есть шансы на популярность. Но как только на рынке появляется конкурент, разработчики софта переключаются на универсальные API. Поэтому я не знаю, выживет ли EAX, но уверен, что век A3D 2.0 будет недолог.

На такой оптимистической ноте мне хотелось бы завершить это «личное дело» с историческим уклоном. Интересны ли вам подобные экскурсы или тесты конкретных железок —все, что вы хотите видеть на темносиних листах любимого журнала? Пишите. Мне, признаться, хотелось бы видеть в Inbox не только жалобы на забастовки читательских PC.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

шестнадцать + 4 =