- CStalker
- Постоялец
Много делал разного в дюке, blood и тд и хорошо помню все изыскания с этажностью.
Вся этажнасть там фейковая. В дюке все винтовые лестницы - это телепорт в такую же комнату. По аналогии с водой. Но можно было делать отдельные блоки из спрайтов. То есть там для спрайта было несколько режимов. Обычный, когда он смотрит на вас, и плоский режим, типа как полигон односторонний с текстурой.
В blood пошли не много дальше. Там прикрутили по сути рендер в текстуру или типа того. То есть делалось две отдельных комнаты. Нижний этаж и верхний, а посередине дыра через, которую видно соседний этаж.
lol
> Вся этажнасть там фейковая. В дюке все винтовые лестницы - это телепорт в такую же комнату.
недавно переигрывал в duke3d (megatron edition) на карте E2M1, и попал в ловушку в лифтовой шахте - падаешь вниз по этой шахте (причем внизу виден выход), и тебя телепортирует в локацию, где лифт внизу (и блокирует соответственно проход). Взлетаешь на джетпаке наверх - и телепортирует туда, где лифт наверху, и снова блокирует проход...
Думаю тут, как сделано цветное "освещение" в Build Engine. Неужели, как и всё остальное, через таблицы?
не разбирался что там за таблицы, но помню что коэф освещения задавался посекторно, то бишь поверхность горизонтальной зоны и всё что в неё попадало, красилось в цвет.
Давно разбирался с палитрой в дюке. Там несколько таблиц под разные условия, например, при нахождении под водой. В таблице цвета расположены по градациям яркости - если таблицу представить как 16*16, то по горизонтали яркость, по вертикали - тон (это я в интернете поискал картинки). Это удобно для реализации освещения - номер исходного цвета уменьшается на соответствующее число. Отдельно группа цветов не меняющая яркость - для светящихся объектов вроде кнопок.
lookup.dat - из него палитры и грузятся.
Исходники дюка нужны? ftp://ftp.3drealms.com/source/duke3dsource.zip
Shurik7777
Понятно как делалось обычное освещение, в Doom\Quake\Quake II\Descent и ещё много где освещение обычным белым светом делалось по таблицам. Меня же интересует, как делалось окрашивание в красный и сниний цвета, там, где расставлен такой цвет.
> Исходники дюка нужны? ftp://ftp.3drealms.com/source/duke3dsource.zip
Чё-то там не видно исходников самого движка. Он кажется отдельно шёл, сейчас погуглю его.
Добавлено: а, нет, движок там же был, в отдельном архиве. Кен конечно наркоман, у него весь движок в одном файле, теперь ищи что там и где.
Panzerschrek[CN]
> Меня же интересует, как делалось окрашивание в красный и сниний цвета, там, где
> расставлен такой цвет.
Может, там число цветов света ограничено и просто несколько таблиц?
TarasB
Я не замечал даже вореций вариаций цветного освещения, сколько не играл в Duke\Blood\Shadow Warrior. Тупо замечал покраснение, позеленение, посинение.
Вот палитра дюка(вроде):
Если это действительно так, как я думаю, тут даже таблиц не надо. Надо просто взять яркость цвета ( первые 4 бит ), и прибавить к смещению строки нужного цвета (синего\зелёного\красного).
К сожалению, я уже позабыл как там все устроено с палитрами. Надо опять копать информацию.
Для пола, потолка и стен в каждом секторе можно задать индивидуально палитру и освещенность.
Причем в руководстве по редактору карт пишется о четырех доступных палитрах/цветах - синий, красный, желтый, зеленый.
Нашел разбор движка: http://fabiensanglard.net/duke3d/index.php, но про палитру ничего.
И еще с сайта Кена Сильвермана про то как таблицы для освещенности используются:
Играю сейчас в Shadow Warrior. Заметил такой игровой элемент - местами есть подвижная группа секторов внутри большого сектора. Так реализован транспорт, некоторые элементы уровня и т. д.
Вопрос - а как такое может быть реализовано? Как работает сортировка для этого дела?
Panzerschrek[CN]
Делал когда-то карты под Shadow Warrior на их редакторе.
Там вроде есть ограничение - подвижная группа всегда внутри большого общего многоугольника.
Обработка мыши в играх на Build движке:
// original MACT386.LIB code (disassembled) void CONTROL_GetMouseDelta(int32 *x, int32 *y) { MOUSE_GetDelta( x, y); // artificial priority for bigger delta axis if ( abs( *x) <= abs( *y)) { *x /= 3; } else { *y /= 3; } *x = ( *x * 32 * CONTROL_MouseSensitivity) >> 15; *y = *y * 96; }
http://ctpax-cheater.losthost.org/htmldocs/trouble.htm#buildmfx
entryway
> Обработка мыши в играх на Build движке:
Для нас это конечно какая-то наркомания, но вот для 2.5-мерного движка это наверное имело смысл.
К тому же мышки тогда были с шаром внутри, может таким образом исправлялись какие-то их глюки?
Panzerschrek[CN]
> Вопрос - а как такое может быть реализовано? Как работает сортировка для этого
> дела?
Так и работает. Сортируется на лету.
Там "портальный" движок когда уровень не запекается в какую то удобную для рендера структуру типа BSP, а вот тупо так и рисуется с помощью порталов.
При этом геометрия становится штукой относительной - имеет значение только что два сектора соприкасаются гранями (портал), через порталы в текущем секторе можно увидеть смежные с ними гранями. И так рекурсивно с отсечением уже посещённых.
Так вот сектора геометрически даже могут пересекаться своими площадями, это не играет роли, т.к. в них не "тыкают" в глобальном пространстве, а только посещают из портала через портал.
С BSP такое просто не сработало бы.
Есть аналогичный движок из 90-х - Marathon: https://gamedev.ru/flame/forum/?id=250262 тут прям хорошо на карте видно такое
Zegalur
> Там вроде есть ограничение - подвижная группа всегда внутри большого общего
> многоугольника.
Да, это важно, т.к. при пересечении стен сортировка будет лажать. Тем не менее сильно выручает то, что этот родительский многоугольник может быть невыпуклым.
