Флейм
GameDev.ru / Флейм / Форум / Quake (3 стр)

Quake (3 стр)

Поделиться
Страницы: 1 2 3 4 560 Следующая »
SkATПостоялецwww9 дек. 20134:49#30
TarasB
> TarasB
Дык, а ты на чем играешь на Celeron 600Mhz? =)

Запускал на днях Quake2 на Flybook с сенсорным экраном 1024x600, надо наверное установить на нормальную машинку и в новогодние праздники поразвлечься! ^_^

1 frag / 2 deathsУчастникwww9 дек. 201310:24#31
SkAT
> Дык, а ты на чем играешь на Celeron 600Mhz? =)
Да, а что, не должно идти?
1 frag / 2 deathsУчастникwww9 дек. 201312:27#32
Давайте поговорим про светокарты в кваке.
Вот есть стенка.
На ней есть текстура материи и текстура света.
Правильно ли я понимаю, что смешивать их на ходу, выполняя при этом размытие текстуры света - это слишком дорого?

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

Ещё остаётся вопрос про монстров. Для них уже кешировать не получится, потому что они движутся. То есть для них уже цвет затеняется на ходу? И вычислять тень по карте уже не получается, то есть весь монстр затеняется одинаково. А как считается, насколько именно надо затенить этого монстра?

Правка: 9 дек. 2013 12:27

Panzerschrek[CN]Участникwww9 дек. 201312:33#33
TarasB
Текстуры на стены накладываются без фильтрации, но лайтмапы фильтруюца, иначе картинка была бы УГ. Смешивать там ничего не надо, лайтма задаёт, насколько нужно сдвинуть индекс цвета в этой палитре в сторону тёмных оттенков:
Qpalette | Quake
Кеширование - не слышал про такое, да и маловероятно это. Не кадры же кешировать?
Освещение монстра берётся из лайтмапы ближайшей поверхности ( наиболее часто, на той, на которой он стоит ).
Тётя ЗюзяУдалёнwww9 дек. 201312:38#34
TarasB
> там заранее вычисляется внешний вид текстур, попавших в кадр
Да, в мультиплеере это происходит за время до первого спавна.
1 frag / 2 deathsУчастникwww9 дек. 201312:40#35
Panzerschrek[CN]
> но лайтмапы фильтруюца

Ну я и спрашиваю - неужели это делается каждый кадр? Это же пипец производительности.

Panzerschrek[CN]
> лайтма задаёт, насколько нужно сдвинуть индекс цвета в этой палитре в сторону
> тёмных оттенков:

А вправо сдвигать или влево? Видно же, что так тупо не проканает.

Кстати надо бы попробовать посмотреть, как удет выглядеть Бульба в кваковской палитре.

Не, там явно по таблице берётся. Часто видно, как белая стена становится тёмно-красной вдалеке от лампы, например.

Panzerschrek[CN]
> Кеширование - не слышал про такое, да и маловероятно это. Не кадры же
> кешировать?

Кешировать текстуру стены с наложенной светокартой. Чтобы не накладывать и не фильтровать каждый кадр.

Panzerschrek[CN]
> Освещение монстра берётся из лайтмапы ближайшей поверхности ( наиболее часто,
> на той, на которой он стоит ).

Похоже на то.

Panzerschrek[CN]Участникwww9 дек. 201312:44#36
TarasB
Стен в кадре может быть много. Ещё, чтобы выглядело нормально, нужно кэшировать в высоком разрешении. Так что это слишком сложно и тяжело, уж проще проинтерполировать значения лайтмапы.
А вообще, поищи обзоры движка\почитай исходники, сразу стане понятно.
SpartanМодераторwww9 дек. 201312:53#37
TarasB
> Давайте поговорим про светокарты в кваке.
http://www.bluesnews.com/abrash/
1 frag / 2 deathsУчастникwww9 дек. 201312:53#38
Panzerschrek[CN]
> Ещё, чтобы выглядело нормально, нужно кэшировать в высоком разрешении.

Кэшировать надо ровно в разрешении родной текстуры стены.

Panzerschrek[CN]
> Стен в кадре может быть много.

Дело не в числе стен, а в суммарном числе текселей на стенах, попавших в кадр.
Очевидно, что оно меньше, чем число текселей на карте, а ведь для каждых 16 текселей (4х4) в файле карты хранится значение от 0 до 63.
Можно оценить размер требуемой памяти, зная размер карты.

Panzerschrek[CN]
> уж проще проинтерполировать значения лайтмапы.

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

Тётя Зюзя
> между тем, у движка сорцы открыты.
ты их читал? там главный цикл заливки в ассемблере

Правка: 9 дек. 2013 12:54

=A=L=X=Постоялецwww9 дек. 201312:55#39
Лайтмапы накладывались как мультитекстурирование. Без кеширований, да и как кешировать попиксельно, губа завернется. Все кроме стен кстати рисовалось другим алгоритмом, с плохой но быстрой перспективной коррекцией.
1 frag / 2 deathsУчастникwww9 дек. 201312:55#40
Spartan
там английский, у меня мозг сразу закипает
но слово "текстуре кешинг" я успел разглядеть раньше, чем мозг вскипел
хехе, как и предполагалось

=A=L=X=
> Все кроме стен кстати рисовалось другим алгоритмом, с плохой но быстрой
> перспективной коррекцией.
Стены тоже рисуются афинными отрезками. Только длина отрезка для стен 8 пикселей, а для монстра - вся линия.

Правка: 9 дек. 2013 12:57

NaykinУдалёнwww9 дек. 201314:56#41
Именно с этой игры я заинтересовался тем, как это сделано))
=A=L=X=Постоялецwww9 дек. 201315:28#42
TarasB
> но слово "текстуре кешинг" я успел разглядеть раньше, чем мозг вскипел
> хехе, как и предполагалось

Жесть, жесть, вот такого я не предполагал даже, а оно вот оно как.
Если вкратце.
Суть в том что рендер двухпроходный.
1. В первом проходе для каждого видимого полигона строится его активная текстура. Эта текстура характерна тем что в неё запекаются и освещение в том числе и если там идет тайлинг - то происходит "детайлизация" - столько раз сколько оригинальная текстура повторяется она действительно записывается с повторениями в то что там называется "surface".
2. На втором проходе полигоны растеризуются как просто текстурированные полигоны причём текстурами уже служат эти "surface", а не оригинальные текстуры.
Первая оптимизация: если активная текстура (sufrace) у полигона в очереди на отрисовку уже построена то её перестраивать не надо и можно сразу переходить к второму проходу быстро-поносному.
Вторая оптимизация: мипмапы - она собственно и делает это всё возможным, т.к. суммарный размер активных текстур не должен быть сильно больше чем размер фреймбуфера экрана собственно, иначе смысл затеи исчезающе мал.
Неявная, но важная оптимизация: т.к. построитель активных текстур и растеризатор разделились и стали очень простыми, они очень хорошо пролезли в регистровые оптимизации.
Подводная оптимизация: декали стало проще реализовывать как этап откинутый в построитель активных текстур и по сути декали вообще не несут пенальти растеризатору если полигон не выходит из кадра.

1 frag / 2 deathsУчастникwww9 дек. 201315:44#43
=A=L=X=
Вот!
И это намного лучше, чем в реальном времени заниматься интерполяциями.
На интерполяциях такой ФПС получить невозможно вообще в принципе.
Про то, что строится только текущий мип - это я не додумался, да.

Интересно, а какой у него аллокатор для сюрфейсов?

CDПостоялецwww9 дек. 201315:50#44
TarasB
> Ещё остаётся вопрос про монстров.
Абраш пишет про http://ru.wikipedia.org/wiki/Метод_тонирования_Гуро
Страницы: 1 2 3 4 560 Следующая »

/ Форум / Флейм / Игры

2001—2017 © GameDev.ru — Разработка игр