Проекты
GameDev.ru / Проекты / Форум / В коридорах бесконечных. В чёрном зале, где колонны. (22 стр)

В коридорах бесконечных. В чёрном зале, где колонны. (22 стр)

Advanced: Тема повышенной сложности или важная.
Страницы: 121 22 23 24 25 Следующая »
Panzerschrek[CN]Участникwww9 июля 201815:42#315
122
Можно таблицы всякие во время компиляции считать на шаблонах/макросах. Ничего лишнего не понадобится.
MikleМодераторwww9 июля 201816:31#316
Great V.
> А вот это не догнал. Ему же, в принципе, надо работать с нормализированными
> значениями, а не с абсолютными. Т.е. 0х00 = 0.0, а 0хFF = 1.0.
> Таким образом получается, что и туда и обратно надо по таблице из 256
> элементов.
Раз:
122
> плавающая запятая не подходит. Просто не подходит.
Два:
Представь таблицу, которая по индексу вернёт элемент. Сразу, без поиска. Пусть даже в твоём варианте 0.0..1.0.

122
Просто мысль: можно же найти фейковую функцию, график которой похож на нужную, я часто пользуюсь таким приёмом.

Great V.Постоялецwww9 июля 201816:44#317
Mikle
> Раз
> Два
Опять не догоняю.
В чем проблема держать в таблице uint8_t? Если надо держать цвет в float32, то можно просто конвертировать до и после выборки с таблицы.
Объясни, пожалуйста.
MikleМодераторwww9 июля 201816:56#318
Great V.
Проблема в том, что при обратном преобразовании, чтобы обеспечить получение на выходе значений 0..255, входные данные, то есть индексы таблицы, должны занимать диапазон 0..196965. Масштабированием (то есть умножением) делу не поможешь, ведь индексы, соответствующие выходным значениям 0..255, распределены НЕРАВНОМЕРНО. Просто попробуй составить исходную таблицу для обратного преобразования из 256 значений, поймёшь, в чём проблема.
122Постоялецwww10 июля 201810:04#319
Mikle
> Просто мысль: можно же найти фейковую функцию, график которой похож на нужную,
> я часто пользуюсь таким приёмом.
В итоге да. Примерно так и делаю сейчас.
Потеря цветности будет, но она будет достаточно малозаметной. Чтобы в реальной игре гамма и контраст не вызывали потерю эстетичности.

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


+++

Картинка.
Редактор, группы коридоров отмечены цветом для автоматического стыкования их на этапе компоновки игровой карты. Грубо говоря чтобы из коротких участков коридоров делать длинные кишки коридоров.

Чтобы показать что модели крутятся, текстуры мутятся.
И работа не стоит.

Изображение

Правка: 10 июля 2018 10:05

Panzerschrek[CN]Участникwww10 июля 201810:24#320
122
А чго это плоские поверхности побиты на столь частые полигоны? Это для освещения/физики?
122Постоялецwww10 июля 201813:28#321
Panzerschrek[CN]
> А чго это плоские поверхности побиты на столь частые полигоны? Это для
> освещения/физики?
А это неожиданный вопрос.
Думаю, самое время открыть рубрику ужасы нашего городка, где я буду заставлять людей плакать, смеяться и бить себя руками.

И в первом выпуске будет замечательный факт: все текстуры одинакового размера.
Этот размер устанавливается на всю сцену и может быть изменён в общем случае только полной перегрузкой сцены.
Отсюда и сетка полигонов на моделях. Каждый полигон содержит фиксированную текстуру, в данном скриншоте она 25х25 и притом всегда квадратная. Поэтому чтобы залить большие поверхности текстурой - требуется регулярная сетка.

Забавный факт номер 2: движок сильнее других проседает от количества полигонов. Это было замечено в 2016-м году, когда проходил конкурс тысячи кубов и я мог наблюдать то как пишут софтрендеры другие люди. Так вот, мой рендер сильнее проседает от количества полигонов чем аналоги. В идеале мне надо делать полигонов чем меньше тем лучше. Однако притом именно моему рендеру - требуется полигонов больше, чем другим рендерам.

Правка: 10 июля 2018 13:31

VoidSpiritПостоялецwww10 июля 201813:38#322
122
> И в первом выпуске будет замечательный факт: все текстуры одинакового размера
Я так понимаю, чтобы сократить вычисления для масштабирования текстур? А если все-таки ввести в их размер множитель - степень двойки, с битовым сдвигом вместо умножения на степень 2?
Или сделать враппинг, разрешив размеры текстур только кратные 2 и соответственно размер полигонов только кратный размеру текстур?

Правка: 10 июля 2018 13:56

SuslikМодераторwww10 июля 201814:06#323
122
> Отсюда и сетка полигонов на моделях. Каждый полигон содержит фиксированную
> текстуру, в данном скриншоте она 25х25 и притом всегда квадратная.
на самом деле я могу поверить, что это даже повышает локальность доступа к текселям текстуры, потому что все текстуры мелкие и если читать из соседних пикселей, они окажутся в одной текстуре и близко в памяти. хотя если у тебя всё равно софтрендер и ты можешь делать всё, что хочешь, то по идее ты можешь вместо 100 полигонов с uv от 0 до 1, сделать 1 полигон с uv от 0 до 10 и когда читаешь из текстуры, просто читать из случайной текстуры из некоторого множества заданных. примерно так:
int texture_index = rand(floor(uv)); // целая часть UV используется для выбора случайной текстуры
float2 local_uv = frac(uv); // дробная часть UV используется для чтения непосредственно из выборанной текстуры
char4 texel_color = textures[texture_index].texels[local_uv.x * texture_width][local_uv.y * texture_height];

таким образом ты можешь сильно сэкономить на количестве полигонов, но всё равно использовать кучу мелких текстур, если тебе так нравится.

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

Правка: 10 июля 2018 14:20

122Постоялецwww10 июля 201816:40#324
VoidSpirit
> Я так понимаю, чтобы сократить вычисления
Одна из причин была да, упрощение формул обработки.
Не столько ускорение работы этих формул, а сколько упрощение мне их написать.

> А если все-таки ввести в их размер множитель - степень двойки, с битовым
> сдвигом вместо умножения на степень 2?
Всё-таки хотелось выбирать размер более произвольно.
Ну и потом, сдвиг в современных процах не сильно быстрее целочисленного умножения. Вот в старых да, умножение было долгим.

Suslik
> на самом деле я могу поверить, что это даже повышает локальность доступа к
> текселям текстуры
И такая причина также была, но не совсем как ты описываешь.
Изначально был рассчёт на агрессивный тайлинг: когда одна и та же текстура используется много раз подряд.

+++

Картинка-пример, когда разбивка помогает экономить размер текстур. В данном примере текстура досок занимает в 2 раза меньше памяти, чем если бы она была цельным куском.

+ Показать

Правка: 10 июля 2018 16:40

MikleМодераторwww10 июля 201816:44#325
122
> сдвиг в современных процах не сильно быстрее целочисленного умножения.
Я так понимаю, тут должно быть сравнение с нахождением остатка от целочисленного деления.
122Постоялецwww10 июля 201817:50#326
Mikle
> Я так понимаю, тут должно быть сравнение с нахождением остатка от
> целочисленного деления.
Хм. Не, такие формулы я не использовал. Да вообще говоря это настолько долгая операция, что странно было бы деление\остаток от деления вставлять в растеризацию.

Ну и в целом это все не про пользу.
Ужасы они потому и ужасы, что получилось как получилось. В 2016-ом я думал что у меня будут одни кубы и вопроса как мне рисовать хайполи подель - вообще не появлялось. Поэтому все решения они оттуда, из кубов. И смысла не надо в них искать. Брать попкорн и ужасаться - вот правильное направление мысли.

Правка: 10 июля 2018 17:50

VoidSpiritПостоялецwww10 июля 201821:16#327
122
> Да вообще говоря это настолько долгая операция, что странно было бы
> деление\остаток от деления вставлять в растеризацию
При использовании целочисленной арифметики и размеров, кратным степеням 2, умножение и деление в частных случаях сводится с сдвигам, а взятие остатка - к взятию младших битов через побитное "И".
MikleМодераторwww10 июля 201821:34#328
122, кроме того, при размерах, кратных степеням двойки, для нахождения текселя с координатами x,y не придётся умножать, опять поможет сдвиг. Так, по-мелочи, повысишь быстродействие.
122Постоялецwww11 июля 20180:14#329
Mr_Jack
> Сейчас даже не верится, что ты делал такие замечательные игры как
Решил ответить более развёрнуто.
Ряд моментов, несколько факторов почему так.

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

+ Далее геймплей. В том же осеннем шутере как я полагал сделал шикарный геймплей: быстрый, красивый. А по факту он был резко не принят игроками. Причины мне понять не удалось. Отсюда вторая проблема: я не могу снова делать шутер так как хер знает почему шутер не зашел.
А когда я сделаю новый шутер, он очевидно будет слабее по геймплею. Ту удачу вряд ли получится повторить.

+ Третья большая трудность в отсутствии контента. 3д контент идёт настолько тяжело что можно считать, вообще не идёт никак.
Да, он идёт медленнее того же осеннего шутера.

+ Четвёртая трудность - скорее психологическая. Все игры в стиме получили отзывы в коричневой зоне, а среди игроков появилось много озлобленных на меня людей (привет гамину). Реакция на мои программы - бесконечные срачи и попытки мне доказать что я не прав. Существует фон бесконечных споров.

+ Пятая трудность - деградация. Понятно, что любой человек постоянно деградирует а потом умирает. На примере футболистов: в 20 лет ты на пике формы, в 30 лет ты уже старый спортсмен, в 40 лет вряд ли тебя вообще возьмут в сборную а в 50 футболиста списывают даже из местечковых клубов. Так что касаемо создания программ - очевидно что ранние проекты человека будут лучше. Обычная физиология, старение организма.

---

Вот такие пироги на верёвке.
Важно понять что разработкой игр я занимаюсь в удовольствие. Многие из упомянутых факторов это удовольствие у меня отбирают. Как следствие вот такая тема.
Да, это всё похоже на жалобы и нытьё. Что разумеется стыдно для джентельмена: жаловаться последнее дело. Однако я всё таки решил написать тебе ситуацию потому что уверен, не ты один хочешь меня спросить об этом.

---

VoidSpirit
> а взятие остатка - к взятию младших битов через побитное "И".
Этого не знал.
Однако взятие остатка делаю только в одном случае и там совсем не связано с растеризацией.

VoidSpirit
> При использовании целочисленной арифметики и размеров, кратным степеням 2,
> умножение и деление в частных случаях сводится с сдвигам
Mikle
> при размерах, кратных степеням двойки, для нахождения текселя с координатами
> x,y не придётся умножать
Это я знаю, однако задержки в растеризации не связаны с такими операциями.
Там в основном задержки складываются из пропускной способности памяти, далеко позади этого задержки от условных операторов, от логических и от циклов. А задержки от целочисленного умножения - где-то около нуля. Деление я вообще не использую в критических к скорости участках.

Страницы: 121 22 23 24 25 Следующая »

/ Форум / Проекты / Оцените

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