Как известно, существует большое количество графических 3D двигателей.
В состав Windows входит программный пакет openGL.
openGL по своим возможностям может быть использован в графическом движке.
Но вот непонятны некоторые вещи.
Движков под Виндоус существует "чертова гора", openGL - один. 
Какая доля движков использует openGL ?
Есть ли такие двигатели, которые именют собственный машинный код для нахождения проекций текстур, то есть имеют подобные openGL функции ?

Вообще, стоит ли сочинять собствееный машинный код для получения проэкций видимых камерой текстур не используя openGL. Я могу это сделать, например. Используя только доступ к графической памяти видеокарты с помощью Direct Draw я могу сам написать что-то вроде своего графического 3D движка. У меня есть уже наметки как решить задачу отображения видимого камерой множества текстур с помощью вспомогательного множества секторов (выпуклых многогранников задающих пустоту). Но вот я узнал про openGL такое, что это средство умеет тоже отображать проекции текстур на камеру. Дело в том, что используя уже готовый программный продукт, неинтересно создавать движок, ведь нет возможности воплотить свои фантазии о том, как бы ты решил эту проблему.
А я знаю как её решить без OpenGL используя аналитическую геометрию, операции над матрицами, векторами, инструкции SSE2 расширения АЛУ процессора. И вот на ум приходит вопрос. Ну допустим я реализую отображение виртуального мира без openGL, а какая выгода от самостоятельного кода ? Если выгоды нет никакой, то смысл остается только тот, что интересно это реализовать самому.

А потом я вспомнил, что движков существует немеряно. И даже однажды я читал в интернете про один из них, я не помню как он называется, да и это неважно, и было написано что тот движок быстро рендерит даже сложную графику - сложную комбинацию всяких поверхностей, а может и спецэффектов. Но ведь если бы тот движок для отображения проекций текстур использовал бы openGL, то его производительность зависела бы в основном от производительности openGL. Но если предположить, что и другие движки используют OpenGL, а их производительность меньше, то получается недоразумение.
Следовательно тот движок имеет собственный машинный код для нахождения проекций текстур и использует свой код вместо кода OpenGL.

И вообще, возможно ли создать код, который бы при выполнении давал бы бОльшую производительность (FPS) при рендеривании сложной графики. Ну, например, представим себе некую сложную конструкцию или сложную совокупность зданий, или в игре сложный зАмок. О возможно ли с помощью собственного кода добится большей производительности в таком случае ?
Я спрашиваю этот вопрос имея в виду опыт многих программистов, написавших разные движки.

А что там под ЛИНУКС существует подобное ?
И что под UNIX ?

Прошу удалить одну из этих черырех одинаковых тем - глючил акселератор.

Ну что ж, поехали по порядку:
 1. Движков под Виндоус существует "чертова гора", openGL - один - ты ж сам ответил на вопрос - openGL по своим возможностям может быть использован 
в графическом движке. В принципе, очччень много народу думают точно так же и, кроме того, еще и так же поступают...  

 2. Какая доля движков использует openGL - не могу, конечно же, утвеждать, но приблизительно процент использования огл'а - 65-70% из 100.

 3. Есть ли такие двигатели, которые именют собственный машинный код для нахождения проекций текстур, то есть имеют подобные openGL функции? Видишь ли... Такие двиги, безусловно есть, но... Их делают либо чрезвычайно зажравшиеся компании, либо самородки-программеры, который занимаются этим только для СОБСТВЕННОГО удовольствия. Я видел несколько примеров таких двигов - невообразомо большой и сложный код, который, по сути, выполняет одну-двн команды гл. Дело в том, что гл - это результат работы мозгов множества программеров наивысоченного класса, которые стояли у истоков зарождения 3д-ускроителей, и знают внутреннюю, эээ... кухню, что ли этих железок. К тому же, имхо, если ты не профи, бесполезно даже начинать писать свой низкоуровневый API. Ведь сейчас игры идут не на техничность исполнения (я имею в виду, конечно же, используемые программные технологии при их написании), а на объем программных эффектов, масштабность и т.д. Поверь, в известных играх написано кода и так достаточно, чтобы позволить себе использовать готовый API...

 4. Ну допустим я реализую отображение виртуального мира без openGL, а какая выгода от самостоятельного кода ? Нет, я не спорю, что ты сделаешь это...
Может быть... Когда-нибудь...    Другое дело, действительно, в окупаемости. Ведь ты учти, что мало написать свой инструментарий, надо с его помощью еще и что-то сделать...

 5. ...а их производительность меньше... - здесь позвольте несогласиться. OGL API предоставляет почти максимальную скорость доступа к твоей видеосистеме. А вот "производительность меньше" - это уже зависит от конкретной реализации структур приложения. Оптимизация-с - вещь, необходимая в каждом доме!   

 6. И вообще, возможно ли создать код, который бы при выполнении давал бы бОльшую производительность (FPS) при рендеривании сложной графики. Ну, например, представим себе некую сложную конструкцию или сложную совокупность зданий, или в игре сложный зАмок. О возможно ли с помощью собственного кода добится большей производительности в таком случае ?
Понимаш, если твой двиг (код, апи...) будет нацелен ИМЕННО на качественный (быстрый?) рендеринг "сложной совокупности зданий", то, в принципе, может. Одако, при том, что сейчас не делаются настолько узкоспециализированные двиги (поправьте меня, если что...), то , имхо, лучше использовать готовый апи и выложиться на все сто в проработке графической части, звука, сюжета, играблельности в общем.

 7. А что там под ЛИНУКС существует подобное? Что ты называешь подобным. Если имеешь в виду собственный апи, то, как раз в том двиге, о котором я говорил в пункте первом, была реализована кроссплатформенность. Иначе, я не понял вопроса...  

 8. Да почти то же, что и под лин.


Внимание! Это исключительно МОЯ точка зрения. Каждый человек имеет право соглашаться с ней или нет (в случае нет, просьба, не кидать в меня кирпичами       ).

OpenGL - э то не программный пакет. OpenGL - Open Graphics Library. Как ясно из названия это
библиотека - набор функций, для работы с графикой/изображением.

Большенство. OpenGL - является кроссплатформенной библиотекой, а следовательно подходит под любые
консоли/ОСи, которые его поддерживают впринципе.
Почти все игровые движки имеют частью своего исходного кода - переписанную работу с видео картой.
Ошибочно было утверждение chozen'а о том, что якобы API функции OGL'а максимально оптимизированны.
Это не так. Взять даже тот момент, вывода буффера кадра на экран: есть лишнии условия, если рассматирвать
asm код библиотеки.

Если ты делаешь это "для себя", то займись, если интересует, узнаешь очень многое и со многим разберёшься
А если ты пишешь какой-то комерческий проект - времени не хватит.

В конечном итоге всё зависит от производительности видео-карты. Но если ты имеешь ввиду, что, если
человек использует OGL, то оптимизированость алгоритмов вывода изображения и работы с ним зависит
напрямую от OGL, то ты прав.

Да, возможно, ибо, как я уже писал - OGL не оптимизированн максимально.

Вот именно: наполнения много, а играбельность - 0. Игры по-немногу прверащаются в американские "одноразовые"
блокбастеры и дешёвые боевички. А по поводу того, что профи используют готовый API - это ты круто ошибаешься.
Ты ведь даже не рассматривал исходного кода того же Quake 2 или 3? Люди пишут всё своё: свою библиотеку
по работе с zip архивами, своё отображение, много своего! Но не всё, конечно.

Откуда тебе это известно? ИЛи ты только предпологаешь?

Очень интересно вы разделили на несколько рендерингов. А разве OGL или DX не писались для достижения наибыстрейшего редндеринга? Не имеет значения что ты будешь рендерить, важно "чем
ты будешь рендерить и как ты будешь рендерить".
Если ты возьмёшь здание в 80000 трианглов и OGL - я тебе гарантирую, что смогу отрендерить это так,
что оно не будет "лагать" на Pentium 2 400 MHZ(Xeon). При этом я могу вывести модель так, что она
машина будет тормозить.

Я имел в виду и "собственные АПИ" и системные АПИ ЛИНУКС.


Типа отобразить как горит огонь... Как течет вода... Да, видел я горящие огни - пылают не так как в реальности, и воды - то же... текут "не так". Так что есть повод для собственных кодов. Не так ли ?

Это сообщение отредактировал(а) sgi1981 - 25.8.2006, 03:52

С точки зрения физической, применительно к современной игровой индустрии, просчёт движения жидкости и тех же потоков воздуха при повышенных температурах, есть задача сверх трудоёмкая. Можно конечно написать полноценную жидкость и её взаимодействие, но в таком случае нагрузка будет просто сверхгалактической и на рендеринг одного кадра будет уходить неприемлимо много времени, что затруднит процесс игры. Лучшей реализацией воды считаю воду в Half - Life 2. Реализации огня хорошей вообще не встречал.

Это сообщение отредактировал(а) Rickert - 25.8.2006, 03:59

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

Не надо путать движок игры и графический движок призванный только рисовать. Редкий дизайнер захочет работать с полигонами, натягивать текстуры, карты и прочее. Движок должен предоставлять разработчику удобный "высокоуровневый" инструментарий, что бы работать в материалах, сложных, возможно на NURBS моделях и прочее, а движок уже оптимизирует это под "минимальные системные требования" (импорт из макса/maya/etc). Массу спецэффектов созданных ранее можно выбросить, всё выглядит лучше если реализовать на шейдерах, другое дело что это потребует кореного изменения мышления программиста 

В итоге: графика есть малая часть движка. написав своё, твой графический движок будет стоять на месте, в то время как у других без лишних телодвижений с выходом новых дров будут новые фичи. Сэкономив время на графическом движке, да ещё больше на сети/вводе (джойстик и т.д.)/зуке и т.д. юзая DirectX, народ вкладывает время в качественный инструментарий.Это и определит выбор конкретной игровой студии в пользу определённого движка.

Я ещё больше опишу задачи.
Я несколько отвлекусь от самого C++, поскольку это необходимо для объяснения дел.
Значит. Дело вот в чем. Есть такая игра, может кто знает, называется 
Blade of Darkness
Производитель Rebel Act Studios

По типу это бродилка. Количество стандартных карт около 17. Ходилка интересная. Под движок этой игры составлено много самодельных карт, трехмерных моделей предметов и персонажей.
Программное исполнение сценария игры и создание предметов на картах обеспечивают скрипты на Python 1.5.
Об этой игре и о картах и о моделях для нее можно почитать на форумах:
русский форум http://forum.ogl.ru/forum/413
зарубежный форум http://www.arokhslair.net/forum/forum.asp?FORUM_ID=11

Дело первое.
Естественно, для того, чтобы отображались карты во время игры, работают некоторые функции, совокупность которых и именуется  Графическим 3D двигателем.
Возникает, конечно вопрос о том в каких DLL расположены эти функции. То есть конкретнее если поставить вопрос, используется ли библиотека WINDOWS/System32/opengl32.dll в этой игре ?
Это доказать я пока не могу.

Дело второе.
Игра на довольно сложных картах во время отображения значительной части карты начинает "тормозить". "Тормозит" тот самый 3D-двигатель. Подробнее о "тормозах" я опишу ниже.
А сейчас только хочу сказать, что "Просперовские карты тормозят". 
Кто такой Просперо (Prospero) ?
Просперо (Prospero) - это ник человека по имени Piter Robinson, который составил уже несколько интересных но и сложных карт(со сриптами) для этой игры - Fugitive I, Fugitive II, Fugitive III и др.
Так вот, если взять, к примеру карту Fugitive III и поиграться, то есть такие места на карте, при нахождении камеры в которых, FPS падает буквально и натурально до 2 кадров в секунду. И не потому, что Просперо неумело составил карту, а просто сам движок "не тянет...".

Дело третье.
Файл карты имеет расширение ".bw", что в переводе означает "Blade World".
Для составления карт Ребелакт Студиос составила программу редактор карт, под названием LED (Level Editor). 
Формат карты в LED называется MP и карты в формате редактирования сохраняются в файлы "*.mp".
Но вот этот LED довольно неудобный на мой взгляд редактор карт для этой игры. Чтобы это понять, могу объяснить особенность метода редактирования (составления) карты. 
Вся карта состоит из секторов и источников света.
Сектор - выпуклый многогранник с текстурами на гранях, который описывает некоторую часть пустого пространства карты.
А в совокупности все эти сектора описывают всю пустоту карты - пустую часть пространства карты.
Остальная часть пространства - не пустая часть. Туда, например, не может нормально проникнуть персонаж, за исключением глюков.
Сектора стыкуются между собой. 
Те области граней, которые принадлежат двум секторам называются порталами.
Таким образом порталы - это ворота между секторами карты.
Но дело заключается в том, что в редакторе LED сектора задаются их горизонтальными проекциями. Т.е. при построении сектора строится его проекция так, как будто бы мы смотрим на этот сектор сверху.
Проекция сектора задается выпуклым многоугольником. Линии этого многоугольника задают стены сектора, а высота его задается отдельно. Существует возможность также изменять наклоны пола и потолка сектора. Текстуры наклядываются путем выбора отрезков и выбора команды по присваиванию текстуры.
И таким образом любой сектор в этом LED предстваляет собой "комнатку".
А если точнее сказать - призму.
Хотя по определению сектора он может представлять из себя не только призму, но и любой выпуклый многогранник. Например, футбольный мяч.
Так вот сам этот LED довольно неудобный для составления карт редактор. Нужно все время представлять карту по проекциям секторов.
Чтобы понять насколько жутко в нем составлять карты, могу привести пример.
Просперовская карта Fugitive III состоит примерно из 4190 секторов. Точное количество не помню. Это количество я узнал не от Просперо, а из файла BW этой карты. Файл BW имеет не читабельный формат.
Подробнее об этом напишу ниже.
Так вот я просто в ауте от мысли что нужно в этом доробле составлять все эти 4100 секторов и для каждой грани, пола и потолка ещё нужно присваивать текстуру, не видя этой текстуры на этой грани во время её присваивания.

Я хочу составить собственный редактор карт для этой игры.
Форматы MP и BW карт я расшифровал.
Расшифровывал путем изменения простых карт и последующего сравнения содержимого файлов в шестнадцатеричном представлении файлов бывшей карты и измененной. 
Расшифровывал так сначала формат MP несколько дней по несколько часо в день и расшифровал его полностью. 
Затем расшифровывал формат BW каты и тоже несколько дней на расшифровку потратил. Почти полностью расшифровал его. О том как я это делал и другие мои сообщения можно почитать на форуме OGL.RU в топике
http://forum.ogl.ru/read/1049326364/0
называется 
Играем в переделанный ZARANDAUR ("светлый" ZARANDAUR).

Мой редактор карт для Blade должен отображать карту в реальном виде (в таком как она будет выглядеть в игре) во время редактирования (изменения) карты. Когда происходит наложение текстур - человек должен видеть как на стену накладывается текстура. Кроме того, текстура имеет масштаб. Масштаб в LED изменяется путем ввода значения масштаба в один из строковых редакторов. В моем же редакторе масштаб можно будет изменять мышью. Сначала выбираем начальную точку на текстуре, выбираем конечную точку и перемещаем эту конечную точку, начальная не перемещается. И так будет изменяться вид текстуры во время перемещения конечной её точки. Конечная точка может также вращаться относительно начальной и текстура вслед за ней должна тоже вращаться. Так пользователь-картодел видит что он делает. Как только ему понравится положение и масштаб текстуры - он завершает перемещение конечной точки.
Карта на этапе редактирования должна будет состоять из одного (классический случай) или нескольких (персонаж попадет в этом случае из одной части карты в другую только уже с помощью заранее составленных скриптов) многогранников и источников света.
Изменение самой карты заключается в преобразовании одного основного или нескольких основных многогранников, грани которых задают границы между пустой и непустой частью пространства. Преобразование основного многогранника заключается в выполнении операций над многогранниками: объединение, вычитание и возможно др. операции. Для выполнения этих операций нужно использовать многогранник-шаблон. Например у нас иммется многогранник, задающий ландшафт. Чтобы создать стену мы берём выбираем многогранник-шаблон для стены и мышью наводим его в нужное место. Когда наводим шаблон - некоторые грани шаблона пересекаются с гранями изменяемого многогранника. После того как установнена позиция шаблона - совершается операция объединения. Отрезки пересечения граней шаблона с гранями основного многогранника определяют новые рёбра основного многогранника, эти же новые ребра делят грани шаблона и осн. многогранника, некоторые грани осн. многогр. и шаблона преобразуются (изменяются), некоторые грани вообще удаляются, к осн. многогр. добавляются несколько граней, полученных от шаблона, среди которых и преобразованные грани. После такой операции объединения осн. многогранник будет несколько изменён. Шаблон остается неизменным.
Операция вычитания (вырезания) от основного многогранника многогранника-шаблона будет использована, например, для создания дверей и окон. Отличие заключается в том, что к осн. многограннику добавляются другие грани от шаблона, и он становится по объему меньше.
Я подумаю ещё как удобнее было бы сделать изменение осн. многогранника без шаблонов.
Но в использовании шаблонов есть важная возможность.
Шаблоны создаются тоже... подобно основному многограннику.
То есть перед тем как использовать шаблон - его, конечно, необходимо создать.
Шаблон должен играть роль инструмента.
Затем шаблон можно изменять
Но, опять таки, это делается с помощью других шаблонов-многогранников !
Так можно создать многогранник-шаблон в виде башни с круговой лестницей. А потом расставлять эти башни в нужных местах.

Дело четвертое.
Четвертое дело в непонятном термине "TRIS MAPA".
Где я его видел ? Сейчас объясню.
Редактор LED позволяет просматривать карты с помощью средства OpenGL.
В составе редактора есть DLL-библиотека rOpenGL3_d.dll. В свойствах этого файла указано, что её производитель - Rebel Act Studios.
Версия файла - 0.8.0.4.
Название продукта - OpenGL Raster.
Я её ещё дизассемблирую. Посмотрю есть ли там инструкции SSE - расширений ALU.
Но а пока мне известно следующее.
Если с помощью редактора LED открыть какую-нибудь карту Blade - будут отображаться те же проэкции текстур с учетом освещенности и камеру можно перемещать и вращать.
Но есть дополнительные данные:


Tris mapa
Tris objs
Particles
Texture Swaps


Все эти величины - целочисленные.
И среди них важная величина Tris Mapa.
Я пока не знаю точно что она означает, но знаю несколько свойств её.
1) Чем сложнее картина проекции части карты - тем больше значение Tris Mapa.
2) Чем больше значение Tris Mapa - тем меньше FPS. Например на одной из стандартных Блейловских карт я отодвинул камеру в такое место и на такое положение, что картина оказалась сложноватой, показывалась чуть ли не треть части карты. Tris Mapa равнялось 3970 и FPS упал до 15 кадров в секунду. Еще перед этим несколько месяцев назад я убедился что при больших значениях Tris Mapa 
FPS обратно пропорционален Tris Mapa.
Я пытался перевести на русский язык словосочетание Tris Mapa, но машинный транслятор мне выдал перевод 
"Карта триса".
И опять же непонятно, что оно означает.
Может это вообще испанское словосочетание. Ведь компания Rebel Act Studios испанская. И вообще в Хелпах её программ все то на испанском, то на английском.
И в поисковой системе Google нет понятных ссылок.

Дело пятое.
Я делаю в уме наброски будущего алгоритма для нахождения цвета каждого пиксела общей проекции текстур. Я моделирую так.
Зададим глобальную систему координат.
Камера состоит из фокальной точки и проецирующей плоскости.
Относительно камеры задается локальная Декартова система координат с центром в фокальной точке, одна из осей перпендикулярна проецирующей плоскости.
Через фокальную точку проходят столько лучей камеры, сколько пикселов на экране. 
Каждый луч пересекает проецир. плоскость и одну или несколько текстур. Для каждого луча камеры необходимо найти найближайшую к фокальной точке камеры точку пересечения с текстурой. Чтобы не перебирать все текстуры - я нашел метод как наиболее быстро найти все части текстур, проекции которых(частей) нужно отобразить.
Нахождение координат точек пересечения лучей камеры с текстурами строится на основе перехода от базиса локальной системы координат камеры к базису системы координат текстуры. Прямая луча задается векторным уравнением. Переход от одного базиса к другому заключается в умножении матрицы перехода на вектор в первом базисе, и так получается тот же вектор только во втором базисе. Согласно выше сказанному: 
сначала необходимо определить уравнение прямой луча камеры по фокальной точке и точке пиксела,
затем путем перехода от одного базиса к другому определить уравнение этой же прямой луча относительно системы координат текстуры, затем определяется коодинаты точки пересечения этого луча с текстурой(одной из основных плоскостей системы координат текстуры).
Я делал в уме наброски построения алгоритма(MMX-расширение учитывается).
Действительно во время преобразования алгоритма я почувствовал что количество инструкций довольно сокращается, и при этом даже львиная доля инструкций умножения отпадает, за счет использования промежуточных данных. 
Но, в конце, когда я нашел уже часть алгоритма по нахождению вектороного уравнения прямой луча, я столкнулся с трудностью. Никак не могу избавиться от единственной операции деления. При построении алгоритма я надеялся и надеюсь полностью избавится от операций деления, которые будут часто выполняться в циклах. Единственная операция деления стоит на пути избавления от неё.

Я не буду в этом сообщении подробно описывать как я думал, может в следующий раз...

Игруха высший класс, хоть про неё и не особо народ знае. Одна из тех, что радует знатоков в тени славы
"тупых блокбастеров по фильмам".

Неправильно. Движок - это не набор графических функций, а сложная система вывода вывода звука, изображения, физических просчётов и ещё много чего.

А зачем тебе знать в каких дллках они расположены? Для разработчика - вообще фиолетово, хоть в kernel32.dll
Доказать можно просто: есть мноо программ, которые отслеживают то, к каким фйалам обращается то или иное приложение. Устанавливаешь - отлавливаешь - знаешь.

Дело - дрянь. Просперо не виноват, а виноват ты и твой компьютер. Просперо делает карты, а не привозит железо на дом, чтобы мы его ставили. Движок игры тоже не виноват - можно пытаться и Quake4 запустить на первом пентиуме: у каждой игры есть свои мимнимальные системные требования. Скрипты карты тоже не имеют значения. Ибо, как ты говоришь, если посмотреть под каким-либо углом в какое-нибудь место - то начинает тормозить. Тормозить она может начать только по одной причине - процессор твоей видеокарты не справляется с нагрузкой. Меняй карты. Ставь дуальный GeForce и будь счастлив.

Этот редактор карт неудобен для тебя. Я слышал много высказываний о том, как люди, которые делали классные кампании в Героях 4, не могут теперь их делать в пятой части, потому что по их мнению редактор неудобный. Это как бы не проблемы разработчиков. Они делаеют редактор для себя, а не для нас. А в состав игр пихают, чтобы народ, если хочет(им нравиться интерфейс и удобность редактора) мог делать свои карты.

Друг мой, ты как с Луны, извини конечно. Чтобы сделать нормальную карту, нужно минимум одна - две недели кропотливейшего труда ума и дизайнерской жилки, дабы карты была удостоена хотябы статуса "неФУФЛО-нормалёк". На каждую карты из Doom 3 у дизайнера уходило по месяцу - полтора. Это например.

В следующий раз, перед тем, как самому "расшифровывать", посмотри по инету - как правило форматы файлов находятся с лёгкостью.

Я думаю, что ты всё-таки не разорался до конца с редактором. С вероятностью в 99.99% там есть возможность просматривать наложенные текстуры.
Это простейшая операция в разработке и то, что люди не смогли её реализовать - очень сомнительно.

Как человек, работавший над движками могу констатировать с вероятностью в 90.05%: Tris Mapa - кол-во ветвей дерева отображаемых геметрических(поверхности) объектов.
Tris Objects - кол-во объектов.
Particles - без комментариев, и так понятно, что это кол-во частиц аля огонь, кровь.
Texture swaps - возможно, что это кол-во текстур отображаемых.
Таким образом, как ты можешь видеть - становиться ясно, почему при большом значении Tris Mapa у тебя начинались лаги - много отображаемой геометрии - много нагрузки на процессор.

Не здравый подход... По виду обычный простой рей-трейсинг, дающий обычно не реальные цвета. А всё потому что не один луч от камеры куда попадёт вычисляеться, но учитываються и рассеивание и "физические характеристики материала", и масса дургого. Посмотри рендеры к 3D редакторам, это совсем отдельный софт, т.к. родной рендер редактора расчитать свет правильно обычно не может. То же самое в звуке (ключевые EAX)

НО! это всё жутко медленно. Да, пользуя SSE/MMX/etc расширения проца ты сможешь выполнить многие вещи быстро на основном проце, при этом карту ты будешь использовать как простейший фреймбуффер. Современная карта поддерживает железную акселерацию, что это? А это возможность выполнять "высокоуровневые инструкции" на GPU разгружая основной проц. При этом весь мир (модели, текстуры и т.д.) помещаються в память карты, где она GDDR3 размером так с 256МБ. Изменяем форму модели, GPU сам просчитает всё необходимое и выдаст картинку. Современные карты могут не просто на экран, а в другую текстуру рендерить, чем XGL под линухом например и пользуеться, что бы стол в кубе отрисовать.

А теперь обращаем внимание на шейдеры, например на пиксельный, что натягивает анимированную текстуры на форму. Такой шейдер это стримовая прога, обрабатывает пиксель за пикселем и не зависит ни от чего, кроме входных данных. Отсюда шейдер может испольняться параллельно, современный GPU может одновременно выполнять один и тот же шейдер в более десятка тредах, каждый свой кусочек работы. Просто увеличив количество конвееров в GPU получаем сразу прирост в производительности, решение маштабируемо. Потому шейдеры и затмят всё, года так через 3, когда тормозить перестанут 

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

Софтверные рендеры нужны только для высококачественных картинок, где кадр может отрисовываться до нескольких часов (brazil, vray etc). Ты же как я понял ориентируешся именно на отрисовку в реальном врмени для игр.

Ничего себе развили тему называется...     


Охотно верю. Ассемблерный код не рассматривал!!! Мне это просто не надо.
Ну а насчет дополнительных проверок, так, имхо, они не сильно тормозят выполнение кода. Лучше подстраховаться, чем потом разбираться в нескольких мегабайтах кода: и что это у меня general protection fault вызывает!   


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


Ошибаешься! Ведь я не привел Квейки в качестве примера только потому, что над этим работали реальные профи, и, кроме того, идеальная команда, каждому отдельному участнику которой можно сказать: "Слушай Джек, тут тебе надо за Пита переписать кусок его кода, потому что Пит заболел на два дня. И побыстрей!". И самое интересное, что Джек быстро разберется в коде коллеги и перепишет его как надо. И, ксатати, кто сказал, что ZLib - это "свою библиотеку
по работе с zip архивами". У меня эти сырцы ВСЕГДА были. Я по ним учился! К тому же Quake 3 - это классный "экземпляр" того, как правильно wrap'пить объявления функций. Чего только стоят хрен знает зачем нужные врапперы огл функций Qgl.h и Qgl_win.cpp на сто килов...  



А у тебя есть факты, опровергающее это??? Я, разумеется, предполагаю, но не без определенных оснований...  


А то! Я вообще человек интересный!      Писались, конечно, кто ж будет с этим спорить.    Но, они были ориентированы НЕ ТОЛЬКО на быстрый рендинг. Вообще, я бы не стал рассматривать ОГЛ на уровне с ДЭИКС. Это разные вещи - начиная от объема функций, охвата АПИ (сеть, графика и управление) и заканчивая производителем (его статутс, положение и т.д.). Это очевидно. Но ведь эти апи существуют И для предоставления разработчику свободы творчества, отстраняя его от не нужных разбирательств в устройстве видеосистемы, таким образом предоставляя ему возможность занаяться тем, что ему необхоимо получить от этого апи.  



А ты знаешь, что есть двигатели, ориентированные на закрытые пространства, открытые, рэйтрейсинговые и еще-каких-там-только-нет. А что будет, если один очччень умный дядя Джон попытается (ну естественно прогресса ради) совместить все эти навороты в одном движке. Не, как говориться, безумству храбрых поем мы песню, но что из этого выйдет???  


Молодец!   А можешь, чтобы машина еще и деньги параллельно с этим печатала, а???  



Слуш, огл - это ведь кроссплатформенное апи, ведь так? А вообще в никсах я пока не связывался с 3D, поэтому про что-то отдельное от гл не слышал.



Но ведь для того, чтобы ты увидел ту воду, которая течет "не так"? куча народу себе столько нервных клеток спустила в унитаз. А тут "не то, не так, не верю..."     Если без шуток, то чтоб сделать даже такую воду, надо очень много сидеть за компьютером, обложившись умными книжками и скоростным доступом в глобальную помойку... И тогда, глядишь, и у тебя заработает 5-килобайтный шейдер...    


Абсолютно точно, мало того, что фиолетово - люминесцентно даже     
У тебя есть хедеры, есть доки, так чего тебе ИСЧО надо?


Знаешь, если это не версия редактора - супер- пре- внутренняя альфа... то просмотр текстур там есть обязательно. Гарантия 100 %!!!


А вообще, по ходу рассуждений, shi1981, тебе надо вплотную заняться применением рейтрейсинга в реалтаймовых играх. Уж больно все сводится к этому...

Сначала отвечу Rickert.

Я имел в виду "Графический 3D двигатель". Ещё раз внимательно посмотри...


Разработчикам фиолетово - мне нет.


Виноват машинный код. Я в этом уверен на 100%.


Несправляется с нагрузкой он именно потому что в видеоадаптере ограниченный набор функций.


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

Да... Ещё я отвлекусь.
Одно из дел в том, что изображения текстур для игры находятся в так называемых файлах "*.MMP".
Эти файлы, таким образом, представляют собой архивы изображений текстур.
Для того чтобы получить файл MMP - необходимо имет исходные изображения и программу-компилятор. 
Rebel Act Studios разработала компилятор текстур BaBx.
Картоделы пользовались им, пользовались. Нравилось, ненравилось, может быть все относительно, как говориться почувствовать счастье можно только почувствовав несчастье. Но я расшифровал формат MMP и решил, что можно создать более удобный в использовании компилятор файлов текстур MMP и составил его. Я уже составил несколько версий этого компилятора.
Для сравнения последовательности действий в работе со "старым" и с новым компилятором текстур могу привести её.
Для того чтобы компилировать MMP-файл в бывшем компиляторе нужно:
1) Открыть BaBx.
2) Открыть текстовый редактор (Блокнот).
3) Написть скрипт на Python 1.5, где последовательность операторов задает имена исходных файлов и имя файла MMP, режим компиляции и некоторые вспомогательные операторы есть.
4) Скопировать в буффер обмена скрипт
5) Вставить из буффера обмена скрипт в нужное Memo компилятора BaBx.
6) нажать Enter.
И когда грядет время компилировать MMP пользователь своим серым веществом мозга поймет что нужно "писать опять эту бадягу (скрипт)" и отвлекаться. И у него в некоторых случаях либо пропадет желание заниматься этим, либо он забудет что он должен делать дальше.
Для компиляции файла в моем "самодельном" компилаторе v.1.5 необходимо сделать следующее
1) Запустить программу.
2) Нажать на кнопку "Добавить файлы изображений" - откроется диалоговое окно выбора файлов.
3) Выбрать несколько файлов изображений (поддерживается форматы BMP, JPEG, GIF, TIFF, PNG) и подтвердить выбор.
4) При необходимости переключить переключателем режим компиляции на нужный, есть такие режимы компиляции: 8 бит, 24 бита, 32 бита(ALPHA-канал).
5) Открыть диалоговое окно сохранения файла MMP и ввести имя файла и подтвердить ввод.
6) Нажать на кнопку "Компиляция".
Проще охарактеризовать - "нажать на три кнопки и все" - может сделать любой.
Отзывы о программе на топиках форумов игры
русский топик русского форума
http://forum.ogl.ru/read/1049329820/0
иностранный топик иностранного форума 
http://www.arokhslair.net/forum/topic.asp?TOPIC_ID=2118
Всем понравилось.
А сейчас я составил ещё более "крутой" компилятор текстур MMP. Версия 2.0(beta).
Интерфей похож на интерфейс файлового менеджера.
И добавил несколько важных возможностей: 
переименовывание изображения прямо в MMP файле;
прямопотоковое копирование (direct stream copy) изображений из одного MMP-файла в другой (без распаковки-упаковки изображений) - выполняется весьма быстро;
извлечение изображений масок Alpha-канала из 32-битных изображений MMP-файла;
удаление изображений из MMP-файла.
Имеется две панели. В одной из них можно открыть MMP-файл, а в другой - файлы изображений и вперед !
О написании скриптов для компиляции можно забыть - эту теперь ненужную хлопоту.


Да каких там одна-две недели. В LED месяцы уходят на создание карты, которую можно пройти за день. И все это из за того, что не совершенствуется редактор карт ! Ещё раз объясняю причину. Редактор карт "стоит на месте" !!! 


Был бы рад если бы где-то в интернете на какой-нибудь веб-странице или в каком-нибудь файле был описан формат "Blade World" файла, но пока поиски безрезультатны.


Возможность просматривать наложеныые текстуры конечно есть.
Но ведь изменять эти текстуры во время просмотра возможности нет !

Теперь отвечу Sardar.

ГА-ГА-ГА !
Луч камеры - это не световой луч, а геометрический луч.
А учет распространения и отражения света, конечно, будет. Но писать я об этом не стал, чтобы сильно не отвлекатся от специфики форума - слишком много текста в сообщении, и считал, что и так будет понятно.

А как можно это доказать ? Я же ещё его не составил до конца.
Может ты считаешь, что я не знаю как расчитать освещенность в каждой точке поверхности ?

Поддерживает. Но насколько совершенным бы ни был набор функций - набор этот всегда ограничен.

Да не останется он на месте. Потому что мощность процессоров будет расти.

Физическое отображение рёхмерности уже в дум1 было написано через двухмерное отображение, чем создавалась псевдотрёхмерность. Люди пишут своё уже очень давно.

Сравни их сорсы с сорсами Zlib'а. Они разные.

Читаем комментарий к коду в Qgl.h:

Теперь глядим Win_Qgl.c:

Теперь думаю тебе ясно?
И кстати, первая игра написанная на с++ id'вцами - Doom 3. Sow: файловые расширения c, а не cpp.

До тех пор пока нет доказательства существования факта - он не существует.

А на что ещё был ориентирован OGL? Поведай.
А под DX, я конечно имел ввиду его часть обработки графики - Direct3D.

Ну так я тебе и говорю:


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

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

А по поводу Tris mapa могу сказать, что до сих пор уверен, что возможен шейдер, который бы шейдерил ту же самую картину с бОльшим FPS.

2Rickert


Я прекрасно понимаю, ЧТО хотел ты этим сказать, только вот эти минидрайверы -я так понимаю - собственные реализации огл-функций я не нашел. Объявили, так сказать "for the further versions" (почти как GDI-система виндов - там таких "для будущих версий..." достаточно)      


Охотно верю, что их первые разработки были на с. Я тоже раньше не воспинимал классы как таковые и прописывал отдельные функции. Если честно, последнее меня прет ГОРАЗДО больше, но классы - неоспоримо удобнее и нагляднее. 


Философ, прям...     Я не буду сейчас искать эти факты - мне это не надо. У меня только один вопрос: ты либо ярый правдолюб, либо ярый дэиксовец... правда???  Без обид   


Ну вообще-то, это избавило таких людей, как, например, я от написания собственной низкоуровневой библиотеки машинной графики. Читай внимательнее, я уже об этом говорил.  


Нет, ну ты крут, парень... Ты реально думаешь, что я писал про "повторяющуюся текстуру воды с жидкой анимацией для какой-то-там-очередной-игры"??? Почему тогда, объясни мне, многие умные люди, дяденьки всякие бородатые собираются на конференции по шейдерам, устраиваемые NVidia и обсуждают что?.. Водичку!!! Шейдерную водичку! Ты невнимателен.    


Нет, что, серьезно???     А это ты к чему???


Ох, млин, делать мне вот больше нечего, как построчно сравнивать их зэдлибы и оригинальные... Я не спорю, немного переделали, но только немного. Иначе это был бы уже не зэдлиб. Я насколько понимаю, они использовали (во всяком случае, в Quake 3) метод zip без сжатия. Т.е. клали все файлы просто в один файл и не сжимали, чтоб можно было в любой момент добавить средствами архиватора (стороннего) в этот архив любой файл. Вот так. 
Я лично такой метод не приемлю... Мож потому, что в моем проекте вмешательство в ресурсы нежелательно совсем ...