The Linux Gamers' HOWTO Версия 0.0.0 Последняя модификация: 28 апреля 2001 г. 8:00am Copyright 2001 Peter Jay Salzman p(at)dirac(dot)org http://www.dirac.org/p Перевод -- Дмитрий Самойлов (c) 2001 dsamoyloff(at)mail(dot)ru В почтовых рассылках и группах новостей, касающихся Linux, непрерывно появляются одинаковые вопросы. Многие из них возникают потому, что люди не знают как все работает в Linux, по крайней мере в том, что касается игр. Я рассматриваю этот документ как средство для решения наиболее общих проблем и для предоставления людям знаний, позволяющих начать говорить и думать осмысленно о том, что же происходит с их играми. Как и во всем другом в Linux, вам нужно знать немного больше о том, что происходит с вашей системой, чтобы сохранять ваши игры в рабочем состоянии или диагностировать и исправлять их, если они не работают. Надеюсь, этот документ уменьшит траффик и просветит людей. Я не эксперт в этой области, поэтому я надеюсь, что гуру подскажут мне что здесь не так и поправят меня. 0.0. Введение 0.1. Авторство, Copyright 0.2. Благодарности 0.3. Последняя версия и контактная информация 1.0. Прелюдия 1.1. Что такое Glide? 1.2. Что такое OpenGL? 1.3. Что такое Mesa? 1.4. Что такое DRI? 1.5. Что такое GLX? 1.6. Что такое Utah GLX? 1.7. Что такое SDL? 1.8. Что такое GGI? 1.9. Что такое SVGAlib? Фрэймбуфер? Консоль? 2.0. XFree86 и Вы 2.1. Получение информации о вашем X 2.2. Получение информации о вашей 3D системе 3.0. Различные темы 3.1. Memory Type Register Ranges 3.2. Выжимание производительности из вашей системы любой ценой 3.3. О библиотеках в Linux 4.0. Когда плохие вещи происходят с хорошими людьми 4.1. ЧГИ! 4.2. Поиск обновлений и патчей 4.3. Группы новостей 4.4. Google 4.5. Отладка: стек и файлы core 4.6. Отложенные игры 4.7. Что делать, если не найден файл или библиотека (лучшая жизнь через strace) 7.0. Железо 7.1. Какая видеокарта самая лучшая? 8.0. Разное 8.1. Почему у меня не работает 3D ускорение? Почему Quake3 работает так медленно? 9.0. Вэб-сайты 9.1. Сайты, посвященные играм 9.2. Сайты коммерческих игр 9.3. Сайты об играх, достойные внимания 9.4. Другие сайты 0.0. Введение 0.1. Авторство, Copyright Автор этого HOWTO и владелец авторских прав на него -- Peter Jay Salzman. Как ни странно, документ публикуется под лицензией GNU GPL. 0.2. Благодарности Спасибо Mike Phillips за пространные комментарии по этому HOWTO, даже если это в его интересах. :) Спасибо тебе, Mike. 0.3. Последняя версия и контактная информация Последнюю версию документа можно найти по адресу http://www.dirac.org/linux/LG-HOWTO.txt. Буду рад вашим дополнениям, исправлениям и улучшениям. Также я ищу людей, у которых все еще есть вопросы после прочтения этого документа, или даже тех, кто думает, что некоторые моменты могли бы быть описаны или оформлены лучше. Присылайте всю корреспонденцию мне, Питеру, по адресу p(at)dirac(dot)org. Вы можете посетить мою вэб-страницу по адресу www.dirac.org/p, или мою Linux-страницу на www.dirac.org/linux. 1.0. Прелюдия За мои 2 года использования Linux, я обнаружил, что счастье приходит от самодостаточности. А самодостаточность приходит от личных знаний. Это то, для чего написан этот документ. Увеличение ваших знаний в вопросах, которые относятся к играм для Linux. Половина просьб о помощи, которые я видел в usenet, исходили от людей, которые не имели достаточных знаний даже для того, чтобы правильно сформулировать ворос. Поэтому, первая часть этого документа посвящена различным компонентам, которые составляют вашу графическую систему. 1.1. Что такое Glide? Позвольте мне ответить постепенно, поскольку вопрос немного запутанный. Glide2 -- это API плюс драйвер, который обращается к аппаратно ускоренным 3D функциям видеокарт Voodoo I, II и III, основанным на чипсетах производства ныне не существующего 3Dfx. Glide2 работает на очень низком уровне: он поддерживает определение view point, отображение текстур, отправку треугольников и т. п.. Некоторые возможности Glide2 напоминают OpenGL, а некоторые -- не имеют аналогов. Программа имеет доступ к специальным возможностям этих карт ТОЛЬКО посредством библиотеки Glide2 одним из двух способов: * непосредственно: программа написана для использования Glide2 * косвенно: программа использует Mesa+Glide2 (Mesa реализует OpenGL через Glide2) Примерами программ, написанных специально для использования Glide2, могут служить Myth 2, Descent 3, Unreal Tournament, Rune и Deus Ex от компании Loki Software. Подавляющее же большинство игр использует Glide2 косвенно, при помощи Mesa с включенным Glide2. Glide2 больше не является закрытым. Компания 3dfx открыла спецификации и исходный код для open source community. Это обеспечивает заметную долю рынка для Linux. В Linux Glide2 портировал Daryll Strauss. К несчастью, Glide2 почти "мертв". Он реализован только в X 3.3 (большинство людей использует сейчас 4.0) и используется только картами Voodoo I, II и III. Можно с уверенностью утверждать, что под Glide2 игры больше писаться не будут. Что же насчет Glide3? Прежде всего, Glide3 -- не "прямой" API. Он существует только для поддержки DRI картами Voodoo III, IV и V под XFree86 4.0. Ни одна игра, используюшая для рендеринга Glide2, не будет работать под Glide3. Как правило, система, поддерживаюшая рендеринг с использованием Glide2, имеет лучшую производительность. Однако, такая конфигурация становится сегодня все менее распространенной. Glide Версия X Поддерживаемые карты Замечания 2 3.3.* Voodoo I, II, III Использует устройство 3dfx для доступа не из-под root. 3 4.*.* Voodoo III, IV, V Использует DRI. Существуют игры, непосредственно использующие Glide2 (в отличие от использования Glide2 через Mesa). Думаю, Quake III и Myth II от Loki являются примерами таких игр. Еще одна разница состоит в том, что Glide2 использует специальный 3dfx-модуль для ядра, чтобы разрешить доступ к 3D-ускорению для обычных пользователей. Другими словами, без него только пользователь root имеет доступ к 3D возможностям карты. 1.2. Что такое OpenGL? OpenGL -- это графический API высокого уровня, в оригинале разработанный SGI на основе их предыдущего закрытого API Iris GL, и ставший несколько лет назад индустриальным стандартом. Он определяется и утверждается организацией Architectural Revision Board (ARB), которая включает в себя членов SGI, IBM, DEC и Microsoft. OpenGL обеспечивает мощный, полный и обобщенный набор возможностей для графических опреаций в 2D и 3D. Существует 4 части OpenGL и его канонических расширений: GL: Основные вызовы OpenGL GLU: Дополнительные полезные вызовы GLUI: Интерфейс с кнопками, checkbox'ами и т. п. GLUT: Средства для системно-независимого управления событиями оконной системы (фиксирование движений/щелчков мыши, нажатий на клавиши, управление сигналом выхода из программы и т. п.). Также включает в себя некоторые элементы UI, которые должны были войти в GLUI. OpenGL -- это не только API, но и его реализация, написанная SGI. Она пытается использовать аппаратное ускорение для различных графических операций, там где это возможно; это зависит от видеокарты, которая установлена в вашем компьютере. Если для некоторой задачи ускорение не доступно, OpenGL осуществляет программный рендеринг. Это значит, что если вы берете OpenGL у SGI и при этом хотитие получить хоть какое-нибудь аппаратное ускорение, то это должна быть реализация, которая написана и откомпилирована специально для вашей видеокарты. Иначе, все что вы получите -- software rendering. То же самое верно и для OpenGL-клонов, таких как Mesa. 1.3. Что такое Mesa? Mesa -- это свободная реализация OpenGL API, которую придумал и написал Brian Paul. Несмотря на отсутствие официального сертификата, это практически полностью совместимая с оригиалом OpenGL-реализация, соответствующая спецификациям ARB. Сообщается, что Mesa даже быстрее реализации OpenGL от SGI. Как и OpenGL, Mesa использует аппаратное ускорение, там где это возможно. Это означает, что существуют разные "версии" или "сборки" Mesa, в зависимости от видеокарты, которая у вас установлена. Если у вас Voodoo I, II или III, то предполагается использование "mesa+glide2" (автор David Bucciarelli), которая является реализацией OpenGL, использующей glide в качестве средства для рендеринга определенных графических операций. 1.4. Что такое DRI? В рендеринге графики участвуют 3 игрока: приложение-клиент (такое как Quake 3), X-сервер и железо (видеокарта). Раньше клиентам строго запрещалась запись непосредственно в аппаратную часть, и для этого была хорошая причина. Программа, которой позволено напрямую обращаться к железу, различными путями может привести систему к зависанию. Вместо того, чтобы довериться программистам, Linux просто запрещает это делать. Однако, это изменилось с появлением X 4.0 и Direct Rendering Infrastructure (DRI). DRI свободно разрешает X-клиентам коллективную запись информации 3D рендеринга непосредственно в видеокарту безопасным путем. DRI "убирает с дороги" X-сервер, и 3D драйвер (Mesa или OpenGL) может использовать железо напрямую. Это делает процесс быстрее. Информация 3D рендеринга может быть либо ускорена железом, либо нет. ---- Glide или другая ----- 3D драйвер | библиотека | приложение ----> Mesa или OpenGL --+ +----| | | | | | -- Программный рендеринг -- | | | рендеринг | напрямую (без DRI) | | -- X-сервер--- | V | | | видеокарта <--------------------------+ +------------- | | | | --- с DRI ---- V монитор С технической точки зрения, это имеет несколько достоинств. * Не надо кодировать/декодировать вершины через GLX. * Не надо пересылать графику X-серверу через сокет. * На машинах с одним процессором, ЦПУ не приходится менять контекст между X и клиентом при рендеринге графики. 1.5.0. Что такое GLX? GLX -- это расширение X, используемое OpenGL-программами, "клей" между не зависящим от платформы OpenGL и привязанным к платформе X. 1.6.0. Что такое Utah GLX? Проект Utah GLX является предшественником DRI. Он основывается на несколько других дизайнерских решениях в отношении разделения данных и методов доступа к видеокарте. (К примеру, он рассчитывает на привелегии root, вместо создания инфраструктуры ядра, необходимой для безопасного доступа). Он обеспечивает поддержку (на данный момент) нескольких карт, которые не очень хорошо поддерживаются в DRI. В частности, семейство ATI Rage Pro, S3 Virge (хотя тот, кто использует это для игр -- просто чудак) и opensource драйвер для TNT/TNT2 (очень недоделанный). Кстати, пока поддержка G400 не будет *действительно* исправлена в DRI, для нее Utah GLX тоже будет лучшим решением; однако, ко времени опубликования этого HOWTO, это, вероятно, не будет проблемой ;-) 1.7. Что такое SDL? 1.8. Что такое GGI? 1.9. Что такое SVGAlib? Фрэймбуфер? Консоль? Если вам еще никто этого не объяснил, консоль -- это темный текстовый экран, который вы видите после включения вашего компьютера (при условии, что у вас не происходит запуск xdm или gdm). Ее можно противопоставить среде X, в которой имеются всевозможные GUI-приложения, такие как xterm. Распространенным заблуждением является мнение, что X обозначает графику, а консоль -- отсутствие таковой. В консоли, несомненно, графика есть -- она полноэкранна, крайне быстра и крайне убедительна. SVGAlib -- это графическая библиотека, позволяющая вам отображать графику в консоли. Существует много игр, использующих SVGAlib и я являюсь большим поклонником этой библиотеки и вообще графических консольных игрушек. SVGAlib вызывает небольшой хруст в суставах, потому что исполняемый файл должен запускаться из-под root или быть setuid, но библиотека должна запускаться под root только при первом старте приложения. Она сразу же освобождается от root'ового статуса. Фрэймбуферы подобны консоли, но они работают в графическом, а не текстовом режиме. Почему может понадобится симулировать текстовый режим из графического? Это позволяет нам запускать графические приложения, такие как просмотрщики postscript, прямо из консоли. Это также позволяет выбрать не только размер консольного шрифта, но и вообще другой шрифт! Представляете себе в консоли шрифт Comic Sans MS? В LDP есть хороший HOWTO о фрэймбуферах. 2.0. XFree86 и Вы Если вы собираетесь играть под X, немного знаний о нем вам не повредит. Я считаю, что "X Window User HOWTO" и особенно "man XF86Config" должны быть прочитаны *обязательно*. Не ленитесь, прочитайте их. Они имеют крайне высокое соотношение информация/объем. Многие проблемы могут быть легко исправлены, если вы ориентируетесь в файле XF86Config (или XF86Config-4). 2.1. Получение информации о вашем X 2.1.1. Probeonly Существует много путей получения информации о вашем X. Популярным методом является использование probeonly. В консоли (без запущенного X) введите: X -probeonly 2> X.out Да, одно тире; довольно о стандартах. Вывод X идет в stderr, поэтому надо его перенаправить в файл X.out при помощи "2>". Этот файл, главным образом, содержит все, что нужно знать о X. Давайте же, посмотрите на него. Он до отказа набит полезной информацией. Важно знать разницу между маркерами: (--) автоопределение (**) из конфигурационного файла (==) по умолчанию (++) из командной строки (!!) замечание (II) информация (WW) предупреждение (EE) ошибка (??) неизвестно Вот пример того, как я могу получить полезную информацию из этого вывода: я работаю с глубиной цвета 16 bpp: (**) TDFX(0): Depth 16, (--) framebuffer bpp 16 X определил чипсет моей видеокарты и объем ее памяти: (--) Chipset 3dfx Voodoo5 found (--) TDFX(0): VideoRAM: 32768 kByte Mapping 65536 kByte Как я уже сказал, здесь есть все. Иногда трудно найти то, что ищешь. К тому же, если X уже запущен, вы должны сначала убить его, а иногда вы не хотите этого делать. Есть и другие способы получить информацию о X, но я не думаю, что какой-нибудь из них может дать такое изобилие знаний как этот. Рассмотрим их вкратце. В Debian (и, возможно, в других дистрибутивах?) вывод startx идет в файл /var/log/Xfree86.0.log, таким образом вам не придется прибегать к "-probeonly". 2.1.2. xvidtune xvidtune придет на помощь когда ваш экран в X слишком сдвинут вправо, или если вертикальный размер изображения слишком мал для вашего монитора. Однако, это еще и хороший инструмент для диагностики. Он сообщит вам: * Диапазоны вертикальной и горизонтальной разверток, заданные в вашем файле XF86Config * 4 числа для горизонтали и 4 числа для вертикали, которые определяют ваш видеорежим (первое для горизонтали и первое для вертикали дают разрешение экрана) * "dot clock" при котором работает ваша видеокарта 2.1.3. xwininfo xwininfo дает вам все виды информации об окнах X. В действительности, "фоновое" или "корневое" окно рассматривается как обычное. Поэтому, когда xwininfo попросит вас кликнуть мышью на окне, о котором вы хотите получить информацию, кликните на фоне. Вам выведут такую информацию, как: * Разрешение экрана "Width" и "Height" * Глубина цвета "Depth" и некоторые другие параметры, которые хотя и представляют интерес, но не относятся непосредственно к теме нашего разговора; такие как "Window Gravity State", который показывает где имеют тенденцию размещаться новые окна. 2.1.4. Другие источники информации xdpyinfo показывает такую полезную информацию, как версию X и загруженные расширения (бесценно, если вам надо посмотреть что отсутствует в вашей системе, скажем GLX, DRI, XFree86-VidMode и. т. п.). 2.2. Получение информация о вашей 3D системе glxinfo расскажет много полезного об OpenGL (используется-ли direct rendering, версии установленных glx и mesa, строки vendor/renderer, используемые библиотеки GL и еще много чего). 3.0. Различные темы 3.1. Memory Type Register Ranges 3.2. Выжимание производительности из вашей системы любой ценой 3.3. О библиотеках в Linux 4.0. Когда плохие вещи происходят с хорошими людьми Конечно, мы не можем рассмотреть каждую неприятность, которая может произойти, но я выделю некоторые общие моменты. Есть два типа Плохих Вещей: случайные и повторяющиеся. Крайне сложно выявить или исправить случайные проблемы, над которыми вы не имеете никакого контроля, и не знаете когда они происходят, а когда нет. Однако, когда проблема повторяется "когда я на третьем уровне и нажимаю два раза стрелку влево", то можно что-нибудь сделать. 4.1. ЧГИ! Читайте гр*баную инструкцию. Инструкция может принимать одну из нескольких форм. С open source играми поставляются файлы readme. К коммерческим играм прилагается книжка с инструкцией и, может быть, какие-нибудь файлы readme на CD. Не забудьте о вэб-сайте игры. Возможно, автор много раз сталкивался с людьми, у которых возникла такая же проблема, и выложил на сайте соответствующую информацию. Хорошим примером может служить Loki Software с их online FAQs. Если вы ненавидите ЧГИ, по крайней мере заимейте привычку пользоваться grep, вместо того, чтобы не заниматься ЧГИ вообще. Так, если ваша игра некорректно работает с сетью, вы всегда можете сделать "grep network *". Это лучше, чем вообще не смотреть на ГИ. Но все же надо попытаться прочитать инструкцию; люди, которые хотят все получать на блюдечке с голубой каемочкой, должны использовать продукты Microsoft, а не Linux. 4.2. Ищите обновления и патчи Если это open source игра, которую вы сами откомпилировали, сходите на сайт игры и убедитесь, что у вас самая свежая версия. Если игра входит в дистрибутив, проверьте, не выпустил-ли его разработчик обновленный пакет rpm или deb для этой игры. Разработчики коммерческих игр, такие как Loki, выпускают для своих игр патчи. Зачастую, игра имеет МНОГО патчей (Myth2), а некоторые без патчей доставляют определенные проблемы (Heretic2). Вы должны проверять сайт на наличие патчей вне зависимости от того, имеются у вас сейчас проблемы с игрой, или нет! Кстати, у Loki теперь есть специальная утилита, которая ищет на вашем винчестере игры их производства и автоматически их обновляет. Спасибо им большое, это была отличная идея! Посмотрите на http://updates.lokigames.com. 4.3. Группы новостей Если вы не знаете что такое netnews/newsgroups/nntp/usenet, то вам определенно стоит потратить 30 минут времени, чтобы узнать об этом. Установите программу для чтения новостей. Я предпочитаю консольные инструменты, поэтому использую tin, однако slrn тоже популярен. В Netscape также есть отличная графическая программа для этого. К примеру, так можно подключиться к серверу новостей Loki: * tin -g news.lokigames.com * Большинство программ для чтения новостей будут соединяться с сервером, адрес которого содержится в переменной окружения NNTPSERVER. Вы можете установить ее командой: NNTPSERVER=news.lokigames.com tin -r * Большинство программ также заглядывает в файл /etc/nntpserver в поисках адреса сервера новостей. 4.4. Google Все, что отправляется в usenet, архивируется на этом сайте. Раньше архив назывался deja (www.deja.com), но потом он был куплен google. Большинство людей все еще знают его как deja, поэтому я буду использовать это название. Вы не являетесь настоящим пользователем Linux, пока вы не используете deja для решения своих проблем. В подавляющем большинстве случаев, вопрос о вашей проблеме (относящейся к играм или нет) уже появлялся на deja. Более того, наверняка уже был дан ответ на него. И не однажды, не дважды, а много раз. Если вам не понятен первый из ответов на ваш ворос (или он не помог), скорее всего вы получите и другие. Deja должен стать одним из ваших рефлексов на любую проблему. Отправляйтесь на http://groups.google.com/advanced_group_search Все очень просто. К примеру, если моя проблема в том, что Quake III падает всякий раз когда Lucy прыгает, я бы ввел в строке "Find messages with all of the words" следующее: linux quake3 crash lucy jumps или если вы не можете заставить работать звук в Unreal Tournament: linux UT sound problem Вы можете включить в поиск название своей звуковой карты. Есть поля, позволяющие ограничить поиск определенными группами новостей. Выделите время, прочитайте и разберитесь, что обозначает каждое из них. Обещаю, этот сервис вас не разочарует. Используйте его и вы станете гораздо счастливее. 4.5. Отладка: стек и файлы core Это отличается от того, что вы делали бы с коммерческой игрой. В случае игр с открытыми исходниками вы можете помочь автору, предоставив ему файл core или stack trace. В двух словах, core (он же core dump) -- это файл, содержащий "состояние" программы на момент сбоя. Он содержит полезную для программиста информацию о природе сбоя -- что стало причиной и что делала программа, когда это произошло. Если вы хотите побольше узнать о файлах core, у меня есть отличный gdb tutorial по адресу http://www.dirac.org/linux. В *крайнем* случае автор заинтересуется содержимым стека на момент крушения. Вот как вы можете получить его. Иногда дистрибутивы настроены так, чтобы файлы core (которые предназначены только для программистов) не создавались. Либо создавались, но только определенной длины. Первый шаг -- сделать так, чтобы система разрешила создание файлов core любой длины. ulimit -c unlimited Теперь вы должны перекомпилировать программу и передать gcc опцию -g (объяснение этого лежит за рамками данного документа). Теперь запустите игру и сделайте то, что приводит программу к сбою и очередной генерации core. Запуститие отладчик с файлом core в качестве второго аргумента: gdb CoolGameExecutable core А после приглашения (gdb) введите "backtrace". Вы увидите что-то типа: #0 printf (format=0x80484a4 "z is %d.\n") at printf.c:30 #1 0x8048431 in display (z=5) at try1.c:11 #2 0x8048406 in main () at try1.c:6 Это может быть долго, но все же, при помощи мыши скопируйте эту информацию в файл. Напишите автору письмо, в котором сообщите: 1. Название игры 2. Любые сообщения об ошибках, которые появляются на экране при сбое игры 3. Что приводит к сбою и является-ли он повторяющимся 4. Стек программы Если у вас широкий канал в Интернет, спросите автора не хочет-ли он получить файл core, созданный программой. Если он захочет, отправьте. Не забудьте сначала спросить, так как файлы core могут быть очень, очень большими. 4.6. Отложенные игры Если в игре есть сохранение текущего состояния, то отправка автору отложенной игры очень важна, так как это позволит ему воспроизвести у себя проблему. Для коммерческих игр это более полезно, чем отправка файла core или стека, потому что они не могут быть перекомпилированы для включения отладочной информации. Опять же, стоит сначала спросить нужно-ли это, а уже потом отправлять, так как эти файлы обычно велики; но такая компания как Loki имеет достаточно широкий канал. Mike Phillips из Loki Software напоминает, что отправка отложенных игр -- это хорошая идея. Стоит-ли добавлять, что все это имеет смысл проделывать лишь в том случае, если игра постоянно падает в определенной месте. Если же игра сбоит каждый раз, когда вы ее запускаете, или работает крайне медленно, файл с отложенной игрой ничем особенно помочь не поможет. 4.7. Что делать, если не найден файл или библиотека (лучшая жизнь через strace) Иногда вы можете видеть сообщение об ошибке, указывающее на то, что не был найден файл. Файл может быть библиотекой: % ./exult ./exult: error while loading shared libraries: libSDL-1.2.so.0: cannot load shared object file: No such file or directory или разновидностью файла с данными, таким как wad или map: % qf-client-sdl IP address 192.168.0.2:27001 UDP Initialized Error: W_LoadWadFile: couldn't load gfx.wad Предположим, что gfx.wad уже есть в системе, но не может быть найден, потому что находится не в том каталоге, в котором должен находиться. Тогда ГДЕ же он должен лежать? Не будет-ли полезно узнать где именно программа его ищет? Это то, в чем блистает strace. strace говорит вам какие системные вызовы были сделаны, с какими аргументами и каковы были возвращенные значения. В моей книге `Kernel Module Programming Guide' (скоро выйдет в рамках LDP) я выделил все, что вы хотели бы знать о starce. Но вот краткая выдержка с использованием канонического примера того, что же из себя представляет strace. Введите команду: strace -o ./LS_LOG /bin/ls Опция -o направляет вывод strace в файл; здесь -- в LS_LOG. Последний аргумент -- проверяемая программа, здесь -- "ls". Посмотрите на содержимое LS_LOG. Весьма впечатляет, да? Вот типичная строка: open(".", O_RDONLY|O_NONBLOCK|0x18000) = 4 Мы использовали системный вызов open(), чтобы открыть "." с различными аргументами и было возвращено значение "4". Что он будет делать с файлами, которые не может найти? Предположим, я хочу посмотреть демо StateOfMind, потому что оно мне никогда не надоедает. Я пытаюсь его запустить и происходит что-то нехорошее: % ./mind.i86_linux.glibc2.1 Loading & massaging... Error:Can't open data file 'mind.dat'. Давайте используем strace, чтобы выяснить где именно программа искала этот файл. strace ./mind.i86_linux.glibc2.1 2> ./StateOfMind_LOG Запустив vim (потому что он крут) и включив поиск всех вхождений "mind.dat", я обнаружил следующие строки: open("/usr/share/mind.dat",O_RDONLY) = -1 ENOENT (No such file or directory) write(2, "Error:", 6Error:) = 6 write(2, "Can\'t open data file \'mind.dat\'."..., ) = 33 Мы видим, что он искал mind.dat только в одном каталоге. Ясно, что mind.dat не в /usr/share. Теперь мы можем найти mind.dat (locate maind.dat) и переместить его в /usr/share. Этот метод работает также и для библиотек. Предположим, библиотека libmp3.so.2 находится в /usr/local/include, но ваша новая игра "Kill-Metallica" не может ее найти. Вы можете использовать strace, чтобы определить где же Kill-Metallica искала библиотеку и создать в этом каталоге символическую ссылку на /usr/local/include/libmp3.so.2. strace -- очень мощная утилита. Когда разбираешься почему что-то не было найдено, это ваш лучший союзник, это даже быстрее, чем поиск в исходниках. Последнее замечание: вы не можете искать информацию в исходниках коммерческих игр от Lokisoft или Tribsoft. Однако, вы все же можете использовать с ними strace! 7.0 Железо 7.1 Какая видеокарта самая лучшая? Если вы используете Linux, вы должны быть достаточно умны, чтобы знать, что не существует простого ответа на этот вопрос. Пожалуй, сегодня можно выбрать из трех вариантов аппаратного 3D ускорения 1. 3dfx карты Voodoo 2. Nvidia GeForce 3. ATI Radeon Королем горы выглядит GeForce, но только при низкой глубине цвета и невысоком разрешении. При более глубоком цвете, более высоком разрешении, королем является Radeon. Другой фактор -- принципы. По разным причинам, OpenGL-драйверы от Nvidia являются проприетарными и их исходники закрыты -- вы можете получить их только в бинарном виде. Драйверы от ATI и 3dfx (до его "кончины") полностью открыты. Лично я думаю, что об этом многое можно сказать. 8.0 Почему игра работает так медленно? Если вы получаете около 1 fps, то ваша система не использует аппаратное ускорение 3D графики. Происходит одно из двух: а) Ваша 3D система не настроена б) Игра не настроена Первый шаг -- выяснение того, что же конкретно происходит. 1. Если у вас X 4.0 (пользователи X 3.* переходят прямо к пункту 2), посмотрите на вывод "X -probeonly". Вы увидите: (II) XXXXXX: direct rendering enabled либо (II) XXXXXX: direct rendering disabled где XXXXXXX -- некоторая строка, которая зависит от вашей видеокарты. Если это direct rendering disabled, ваша настройка X явно неправильна. Игра тут ни при чем. Вам нужно разобраться почему DRI не включается. Заметьте, что если вы прошли этот тест, ваша система СПОСОБНА производить direct rendering. Однако, ваши библиотеки все еще могут быть не в порядке. Поэтому, перейдем к пункту 2. 2. Есть программа под названием gears, которая входит в пакет "mesademos". Вы можете получить mesademos при помощи debian (apt-get install mesademos), либо поискать rpm на rpmfind.net. Вы также можете скачать исходники с сайта mesa и откомпилировать их самостоятельно. Запустив gear, вы увидите вращающиеся шестерни. В xterm, в котором вы запустили gears, будет выводиться "X frames in Y seconds = X/Y FPS". Вы можете сравнить ваши показания с таблицей, приведенной ниже. Лучший вариант -- убить перед этим все некритичные процессы. Не имея миллион запущенных демонов, вы не будете волноваться, что ваш FPS не так хорош, как на похожей машине в таблице. Нет нужды запускать gears под root. CPU TYPE VIDEO CARD X VERSION AVERAGE FPS Самостоятельная компиляция модулей Mesa и DRI может увеличить FPS на целых 20 кадров в секунду; реальное увеличение производительности! Так вот, если ваш FPS где-то на 30 меньше, чем на сравнимой с вашей машине, то скорее всего gears работает в software режиме. Другими словами, ваша видеокарта не ускоряет аппаратно 3D графику. Так же важно различие в FPS при разных размерах окна. Измените размер окна gears. Сделайте его большим, маленьким и на весь экран. Если аппаратное 3D ускорение работает, то FPS должен оставаться постоянным. В противном случае, 3D рендеринг, вероятно, производится программно, а не аппаратно. 8.1. Проблемы, характерные для Voodoo В X 3.3 Voodoo производит аппаратное ускорение только при глубине цвета 16bpp и молча отказывается от него, если вы попробуете запустить X при цвете 32bpp. В X 4.0 ускорение работает при 16bpp и 24bpp, но X не сможет стартовать, если вы используете глубину цвета, которая не поддерживается Voodoo. 9.0 Вэб-сайты 9.1 Сайты, посвященные играм www.happypenguin.org The Linux Game Tome: о самих играх. www.linuxgames.com новости игр для Linux. 9.2 Сайты коммерческих игр Loki Software: www.lokigames.com Как компания, создавшая quake3 для Linux, Loki является отцом игростроения в этой системе. Они были первыми и, кроме того, имеют на своем счету наибольшее число игр. Loki портирует игры в Linux. Tribsoft: wwww.tribsoft.com У них виднеется на горизонте несколько отлично выглядящих rpg и симуляторов! На данный момент у них есть только Jagged Alliance 2, но скоро появятся Europai Universalis, Majesty и Unfinished Business. Hopkins FBI: www.hopkinsfbi.com Это моя самая любимая игра навеки. Более жестокая чем Quake. Более пошлая чем Hustler. Более убойная чем Liberacce. Это комиксы на экране вашего монитора. Если кто-нибудь знает почему автор не хочет сделать Hopkins II -- скажите мне, пожалуйста! Terminus: www.vvisions.com/terminus/index2.html Я купил ее, но пока не играл. Все еще обрабатываю Soldier Of Fortune. ;) Phantom EFX: www.phantomefx.com Они предлагают вам Reel Deal Slots. Я поиграл в демо и оно очень неплохо сделано! Потом они выпустят Reel Deal Casino (первый квартал 2001) и Casino Tycon (доступно TBA). Theocracy: www.theocracy.com Стратегия реального времени, где вы являетесь лидером Ацтеков от Ubisoft. Вы могли бы и не узнать никогда, что есть порт этой игры в Linux. За 10 минут серфинга я еле-еле нашел какие-то упоминания, что она доступна в Linux. Очевидно, доход от продажи Linux-версий здесь погоды не делает. Даже нет никакого упоминания на happypenguin.org! 9.3 Сайты об играх, достойные внимания www.linuxquake.com Linux мета-сайт о шутерах от первого лица planetquake.com/linux Linux мета-сайт о шутерах от первого лица www.quakeforge.net Достижения в Quake I для Linux lhl.linuxgames.com Half-life в Linux Три главные проекта Doom: prboom.sourceforge.net Кросс-платформенный порт движка Doom/Doom II под GPL www.doomlegacy.com Кросс-платформенный порт движка Doom/Doom II под GPL zdoom.notgod.com Кросс-платформенный порт движка Doom/Doom II НЕ под GPL (исходники доступны) tuxaqfh.sourceforge.net Tux: A Quest For Herring 9.4 Другие сайты www.mesa3d.org Сайт Mesa www.xfree86.org Сайт XFree86.org www.libsdl.org Сайт SDL Гораздо проще заставить работать "родной" код, но для программ, которые никогда не будут портированы в Linux, всегда есть эмуляция. www.dosemu.org Сайт DOSEMU - эмуляция DOS и немного win32 www.winehq.org Сайт WINE - эмуляция Win32 www.transgaming.com Нацелены на улучшение поддержки DirectX в проекте WINE. ========================================================================== data -- these are packages from working systems. integrate into howto. Card: Voodoo III, Voodoo IV, Voodoo V Distro: Debian Woody mesademos 3.2-3 Example programs for Mesa. xlibmesa-dev 4.0.2-7 XFree86 version of Mesa 3D graphics library xlibmesa3 4.0.2-7 XFree86 version of Mesa 3D graphics library xlibosmesa-dev 4.0.2-7 XFree86 version of Mesa off-screen rendering xlibosmesa3 4.0.2-7 XFree86 version of Mesa off-screen rendering libglide3 2001.01.26-1 Graphics library for 3Dfx Voodoo based cards Card: 3Dfx Voodoo 3500/tv Distro: Mandrake 7.2 (Mark) Distro: Redhat 7.0 (Gabe) Glide_V3-2.60.15-3mdk Glide3-devel-20000823-1 XFree86-glide-module-4.0-6mdk Mesa-devel-3.3-5 Mesa-3.0-4 Glide3-20000823-1 Mesa-3.1-14mdk Mesa-3.3-5 Mesa-common-3.1-14mdk Mesa-demos-3.1-14mdk Mesa-common-devel-3.1-14mdk Mesa-devel-3.1-14mdk vim:set si: