Имеется почти готовый движок на Open GL. Нужен человек, знающий ассемблер и хорошо ориентирующийся в закрытой части кода Doom\Quake4 (win) - есть несколько вопросов, касающихся реализации сжатия исходного текста деклараций (idDecl* и производные).
На сколько я знаю, вроде Ксер и Дядя Миша известные квако копатели, поэтому решил немного помочь нашему кодеру, который столкнулся с проблемой сжатия - если у кого есть возможность и время поделиться опытом, будем очень признательны и благодарны
__________________
...Из советов молодому пловцу:
"Не плыви по течению. Не плыви против течения. Плыви туда, куда тебе надо."
Козьма Прутков.
МиГ-29 писал: есть несколько вопросов, касающихся реализации сжатия исходного текста деклараций (idDecl* и производные).
Впервые слышу этот термин
Цитата:
МиГ-29 писал: Нужен человек, знающий ассемблер и хорошо ориентирующийся в закрытой части кода Doom\Quake4 (win)
Бгг, думаю, что такого человека любая контора с руками оторвет
Как устроен рендеринг в дуум3/ку4, я примерно представляю, там ничего сложного нет, тем более все технологии - устаревшие, максимум за 2004 год. Но "сжатие исходного текста деклараций" мне, увы, не pozubam
XaeroX писал: Шаблоны - чушь. Использование ООП в игровых движках - маразм. Так и передай
гляжу ты понятия не имеешь о чем говоришь, а уже оперируешь длинными и смелыми фразами а-ля "Как устроен рендеринг в дуум3/ку4, я примерно представляю, там ничего сложного нет, тем более все технологии - устаревшие...". наверняка ты знаешь, что Doom3/+ построен на ООП, и Tech5 построен на ООП и последующие СОВРЕМЕННЫЕ... думаю дальше могу не продолжать - моя мысль ясна.
Цитата:
XaeroX писал: "Мгновенный просчет" - это сильно сказано. Надо запомнить
Запомни (С)
Цитата:
XaeroX писал: тоже понятия не имею, что имеется в виду
но упорно продолжаешь гнуть свою линию и настаивать на своей правоте... сам прикинь в уме, что произойдет если не выбирать поверхности для вывода, при отрисовке каждого из множества ист.дин.света !??
п.с. офтопим
*ушел, закрыв за собой дверь*
Добавлено 12-08-2008 в 09:25:
От меня:
ладно ребята, давайте не будем спорить и уходить в оффтоп... Спор кто круче смысла не имеет - все равно круче всех только яйца Предлагаю вам перенести спор в аську
__________________
...Из советов молодому пловцу:
"Не плыви по течению. Не плыви против течения. Плыви туда, куда тебе надо."
Козьма Прутков.
МиГ-29 писал: наверняка ты знаешь, что Doom3/+ построен на ООП, и Tech5 построен на ООП и последующие СОВРЕМЕННЫЕ... думаю дальше могу не продолжать - моя мысль ясна.
МиГ-29 писал: сам прикинь в уме, что произойдет если не выбирать поверхности для вывода, при отрисовке каждого из множества ист.дин.света
У меня сложилось впечатление, что товарищ сам смутно понимает, о чем говорит Что значит "выбирать поверхности для вывода"? Причем тут динамические источники света? При чем тут вообще OpenGL?
Цитата:
МиГ-29 писал: Предлагаю вам перенести спор в аську
Да как можно с товарищем спорить, если он говорит на другом языке, и я не понимаю почти не единого слова? Сначала хоть бы о терминах договорился, прежде чем тему поднимать. Пока что я не вижу ни одной вразумительной фразы от него (кроме фраз флеймового характера, разумеется - они бесспорно составлены грамотно и четко )
Добавлено 12-08-2008 в 16:09:
Цитата:
МиГ-29 писал: сам прикинь в уме, что произойдет если не выбирать поверхности для вывода, при отрисовке каждого из множества ист.дин.света !??
А, у меня есть предположение, что имеется в виду составление списка поверхностей для отрисовки света для каждого источника. Ну есть разные методы, хотя бы те же порталы. Все зависит от типа движка - открытые или закрытые пространства, способ определения видимости и т.д. Опять же, причем тут эти таинственные interaction surfaces, "сжатие исходного текста деклараций" и другие простые вещи?
сам прикинь в уме, что произойдет если не выбирать поверхности для вывода, при отрисовке каждого из множества ист.дин.света !??
Тов. Миг-29 ты будешь смеяться, но именно так и работала q3 - там не было возможности мгновенно получить нужный surface от конкретной ноды, поскольку разработчики BSP 46 за каким-то чертом выбросили эти переменные (firstface и numfaces) из описания ноды.
Поэтому перебор осуществлялся исключительно "втупую". Конечно скорость его была в любом случае выше, нежли у линейного, но ниже, чем у тех же BSP 29, BSP 38.
И динамический свет не "рисуется" в том понимании, как ты себе это представляешь.
Цитата:
Да как можно с товарищем спорить, если он говорит на другом языке, и я не понимаю почти не единого слова?
Дядя Миша писал: но именно так и работала q3 - там не было возможности мгновенно получить нужный surface от конкретной ноды, поскольку разработчики BSP 46 за каким-то чертом выбросили эти переменные (firstface и numfaces) из описания ноды.
C++ Source Code:
1
typedefstruct mnode_s {
2
// common with leaf and node
3
int contents; // -1 for nodes, to differentiate from leafs
4
int visframe; // node needs to be traversed if current
А не надо мне про R_RecursiveLightNode - нет такой функции в ку3.
Ты давай отвечай на поставленный выше вопрос: "А это чо?"
Добавлено 08-12-2008 в 18:35:
Просьба не наезжать на движок ку3. Он работает оптимизированнее ку1 и ку2. А выкинули оттуда только legacy stuff, использовавшийся в софтварных версиях рендера.
| IP: 
10-08-2008 15:34
