forum
Добро пожаловать, Гость
Логин: Пароль: Запомнить меня

ТЕМА: Новости с фронта

Новости с фронта 13.03.2016 03:17 #7200

  • StaticZ
  • StaticZ аватар
  • Вне сайта
  • Разработчик
  • Демиург
  • Сообщений: 292
  • Спасибо получено: 143
  • Репутация: 68
sam0delk1n пишет:
А вот если он пишет на C# уже не очень понятно как виртуальная машина будет исполнять байт-код.
На самом деле не совсем, можно спокойно посмотреть выдаваемый компилятором код MSIL и при желании даже вручную писать на нем и встраивать его в свой код. Конечно это не машинный код, однако по факту это некая абстракция ассемблера. И хоть по нему нельзя с уверенностью судить о машинном коде, тем не менее можно его оптимизировать.

sam0delk1n пишет:
Так что мое мнение: С++ (и другие бинарные языки) хорош тем что даёт как высокоуровневую абстракцию, так и контроль вниз до ассемблера.
В теории да, но на практике самое смешное, что все поклонники С++ не могут жить без всяких STD, BUST, автосборщиков мусора и новомодных наворотов, вплоть до тех же лямбда выражений. А ведь весь этот тяжелый мусор ничем не лучше аналогичных высокоуровневых конструкций в том же C#, как с точки зрения скорости так и сточки зрения возможности низкоуровневой оптимизации.

sam0delk1n пишет:
Может писать на С++ и тоже убедиться что на ассемблере получилось то что требуется.
Ой ли? Вы правда можете ручаться что 1000 строк кода спустя компилятор не решит что данный код лучше скомпелить по другому? Я не говорю уже о том что смена компилятора или даже версии часто порождает кучу лулзов на эту тему, вроде различных правил при инициализации переменных (одни к примеру обнуляют значения другие нет).

sam0delk1n пишет:
В C#, Java напротив требуются дополнительные механизмы для передачи данных из одной среды в другую.
Это зависит от того как писать, у меня к примеру почти все данные (спрайты, звуки и тд и тп) храняться в неуправлямой памяти. Так что в случае чего мне достаточно лишь один раз передать указатель и все дела. А Java куда дохлее кстати, хотя и у нее есть плюс - реальная кросплатфарменность.

sam0delk1n пишет:
Я просто объяснил в чём для меня преимущество бинарных языков в вопросе контроля кода и чем контроль важен для оптимизации (и кстати безопасности в дальнейшем!).
Да я с этим не спорю, я лишь говорю о том что в наше время время и удобство не менее важны чем скорость и возможность оптимизации. Реальный случай был у меня - писал приложение несколько месяцев на С++ (вернее писал меньше большую часть времени ловил не мерзкие плавающие баги. Ситуация усугублялась еще тем что это было тяжелое приложение для расчетов от которого требовалось большая стабильность, да и результаты работы хоть как-то можно было оценивать лишь спустя пару часов работы. Вообщем потом плюнул и решил переписать на C# у меня это заняло два дня, еще неделя ушла на отладку, оптимизацию, ГУЙ и всякие приятные мелочи. Ну дальше конечно тоже возился с улучшениями и доработками но это уже было спокойная не спешная работа.

sam0delk1n пишет:
DXT и сжимает и ускоряет выборку из текстур.
DXT для пиксель арта???

sam0delk1n пишет:
Гигабайт нарисованного вручную пиксельарта?
Легко - хорошая спрайтовая анимация весит до кучи.

sam0delk1n пишет:
А кстати здесь никого потенциальных 3д-артистов нет?
Если под здесь понимается данный проект, то насколько я знаю нет, да и для данного проекта не очень хочется честно говоря, да и особого практического смысла не вижу. А вот для РПГешки какой нибудь было бы не плохо.
Game isn't a dream, it is the reality, reality which is coming while we dream...
Тема заблокирована.
Спасибо сказали: sam0delk1n

Новости с фронта 13.03.2016 15:02 #7202

  • sam0delk1n
  • sam0delk1n аватар
  • Вне сайта
  • Интересующийся
  • Сообщений: 76
  • Спасибо получено: 47
  • Репутация: 24
StaticZ пишет:
На самом деле не совсем, можно спокойно посмотреть выдаваемый компилятором код MSIL и при желании даже вручную писать на нем и встраивать его в свой код. Конечно это не машинный код, однако по факту это некая абстракция ассемблера. И хоть по нему нельзя с уверенностью судить о машинном коде, тем не менее можно его оптимизировать.
Здесь вопрос соответствия архитектуры виртуальной машины и реального железа. Например в vmware, virtualbox, hyperv виртуальная машина является подмножеством реальной (по сути даже использует аппаратную виртуализацию процессора) и практически не уступает по скорости реальным вычислениям, код фактически как есть проецируется на реальное железо. Байт-код C#/Java работает на разных железах (например arm), видимо виртуальная машина их представляет некую абстракцию. В реальном асме указано за сколько тактов выполняется та или иная инструкция. В байт-коде можно написать более оптимизированный код для виртуальной машины, но может возникнуть проблема эмуляции специфических команд и реальное выполнение окажется медленнее, чем до оптимизации. Достаточно непредсказуемый процесс чтобы его контролировать. Нужно глубоко понимать работу виртуальных машин (а они ведь закрытые?) чтобы управлять этим процессом.


StaticZ пишет:
Ой ли? Вы правда можете ручаться что 1000 строк кода спустя компилятор не решит что данный код лучше скомпелить по другому?
С отключенной оптимизацией компиляторы действуют довольно прямолинейно и одинаково. К тому же всякие GCC обычно поясняют своё решение и даже комментируют выходные листинги ассемблера. Моё мнение что нужно писать без оптимизации пока есть такая возможность. Оптимизацию включить когда всё готово и все баги ручного кода отлажены. А если ручной код достаточно быстрый, то вообще оптимизацию не включать. Она реально может порождать баги и непредсказуемые действия. Я её рассматриваю как дополнительную плюшку: если прокатит -- здорово, если нет -- нужно рассчитывать на свои силы.


StaticZ пишет:
Я не говорю уже о том что смена компилятора или даже версии часто порождает кучу лулзов на эту тему
Здесь я так делаю: выбираю компилятор сразу на весь проект. Если проект -- движок, значит это на несколько лет вперёд. Некоторые люди даже версию компилятора не меняют, но я gcc-сборку время от времени обновляю, она достаточно консервативна, или по крайне мере указаны изменения. Если целевых платформ несколько, тогда действительно возникают трудности. Например msvs 2015 до сих пор не совместима с с++11/14 и там даже синтаксис немного отличается. Можно выйти из ситуации с помощью макросов, но это ухудшает читабельность кода. Поэтому я на windows использую mingw (сборка gcc для windows). Там тоже есть различия, но небольшие. Иногда проще написать два разных кода для своих целевых платформ на своих компиляторах. Или вот например скомпилировать движок и opengl рендер на gcc, а dll с directx рендером отдельно на msvs (потому что там есть интрументы для отладки dx11 хорошие), а затем слинковать вместе.


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


StaticZ пишет:
В теории да, но на практике самое смешное, что все поклонники С++ не могут жить без всяких STD, BUST, автосборщиков мусора и новомодных наворотов, вплоть до тех же лямбда выражений. А ведь весь этот тяжелый мусор ничем не лучше аналогичных высокоуровневых конструкций в том же C#, как с точки зрения скорости так и сточки зрения возможности низкоуровневой оптимизации.
Быть поклонником языка это плохо, нужно мыслить вне рамок языка =). Ну вообще то непосредственно в геймдеве осуждается использовать "новомодные навороты". boost однозначно критикуется в геймдеве и про него нужно забыть. Под автосборщиком мусора понимается управление памятью: обычно используют стандартное ручное, или же пишут специально для движка своё. std начиная с с++11 стал лучше, его можно использовать чтобы быстро наклепать прототип или пробную версию, но в процессе оптимизации std потихоньку заменяют на свой код в критических по скорости местах. Но в целом std это уже часть языка. А вот лямбда это конструкция ядра языка, так что это никак не наворот, это такая же базовая вещь как вызов функций, просто относительно новая и не все привыкли. Скорость она никак не портит, просто форма записи такая для удобства, она как inline функция в место вызова подставляет свой код.


Вот у вас тут все проекты в целом одинаковые с технической точки зрения. Можно написать под них сразу один движок. Он не универсальный, а под конкретный набор игр будет. И сразу на несколько лет вперёд перспектива.
Последнее редактирование: 13.03.2016 15:03 от sam0delk1n.
Тема заблокирована.
Спасибо сказали: StaticZ

Новости с фронта 13.03.2016 17:06 #7203

  • StaticZ
  • StaticZ аватар
  • Вне сайта
  • Разработчик
  • Демиург
  • Сообщений: 292
  • Спасибо получено: 143
  • Репутация: 68
sam0delk1n пишет:
Байт-код C#/Java работает на разных железах (например arm), видимо виртуальная машина их представляет некую абстракцию.
Ну никто и не утверждает, что это машинный код, я лишь сказал что при большом желании оптимизируя его можно влиять на машинный код. Другое дело что если Вы и правда серьезно собираетесь писать килотоны кода на MSIL возникает вопрос целесообразности выбора C#.

sam0delk1n пишет:
Нужно глубоко понимать работу виртуальных машин (а они ведь закрытые?)
Вообще-то нет, Mono - сам по себе опенсорс, мелкософт тоже открыла код .NetFramework.

sam0delk1n пишет:
С отключенной оптимизацией компиляторы действуют довольно прямолинейно и одинаково.
Ну если так смотреть, то можно сразу писать на ассемблере...

sam0delk1n пишет:
Ну вообще то непосредственно в геймдеве осуждается использовать "новомодные навороты". boost однозначно критикуется в геймдеве и про него нужно забыть. Под автосборщиком мусора понимается управление памятью: обычно используют стандартное ручное, или же пишут специально для движка своё.
Ну когда я пишу на С\С++ то я как раз и пишу низкоуровневый код безо всяких бустов и даже более я принципиально не пользуюсь даже string, в результате даже считывание и обработка текстового файла превращается в достаточно зубодробительный код на пару тысяч строк кода... И это здорово, только вот времени и сил требует в разы больше чем реальная польза.

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

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

sam0delk1n пишет:
В больших играх если текстуры не влезают в память -- их стримят параллельно (обычно сразу с диска, мимо озу), без фризов игры.
Кстати а это вообще возможно?? за работу с дисками отвечает ОС и в современных ОС получить доступ к железу в обход ОС не является возможным, даже пара строк на асме для бибикания на динамике и то уже не прокатывают (вернее прокатывают, но для этого надо писать свой драйвер, подписывать его и регистрировать в ОС, а это слишком уж напряжно и сильно будет смущать пользователей). Единственный вариант это отмапить файл в память, но это опять же посути WinAPI и за то как именно веден себя менеджер памяти остается на усмотрение винды
Game isn't a dream, it is the reality, reality which is coming while we dream...
Тема заблокирована.
Спасибо сказали: sam0delk1n

Клипер клипинга, как аутеизм современного движка 13.03.2016 17:52 #7204

  • StaticZ
  • StaticZ аватар
  • Вне сайта
  • Разработчик
  • Демиург
  • Сообщений: 292
  • Спасибо получено: 143
  • Репутация: 68
Дело потихоньку движется влево или куда там нас несет. На днях заменил текстурки на более подходящие по разрешению и детализации (конечно нагло заимствованные, возможно даже кто-то угадает откуда), результат нежданно порадовал глаз, даже без нормальных теней:

pic-20160313-153625_.jpg


pic-20160313-153420_.jpg


Ну и конечно, истинный 2D движок без клипира, всеравно что машина без мотора - поедет лишь если в нее засадить Флинстоуна. Для тех для кого слово клиппинг означает тоже, что и "лепсомиган", поясним что произошло оно от древне буржуйского clip - "обрезать". И как не сложно догадаться это техника обрезки изображения, что является основой оптимизации любого более менее серьезного истенного 2D движка. Ведь очевидно, что скорость отрисовки зависит от числа обрабатываемых пикселей, даже если тупо идет копирование картинки - чем меньше пикселей тем меньше надо копировать из одной области памяти в другую, а значит тем меньше это времени займет. Ну а в случае к примеру 3х мерного рельефа это дает куда больший выигрыш. Для чего оно нужно? Допустим у нас персонаж делает шаг и нам надо перерисовать спрайт, а значит и все что под ним, но зачем ради этого перерисовывать весь экран, если достаточно обновить небольшую область 60х28 пикселей? Конечно можно возразить, что в реальной жизни у нас на экране куча спрайтов и все двигается, но так ли это? Одни спрайты обновляются раз в 0.4 секунды, другие раз в 0.3, третье раз в 0.6 и в итоге мы получаем что для обновления экрана нам все равно не нужно перерисовывать абсолютно все, а это позволяет сократить нагрузку в десятки раз. Собственно над этим я и засиживался последние ночи, в случае с картой задачка усложняется тем что надо не только отбрасывать пиксели рисуемых тайлов, что не попадают в область, но и сделать предварительно выборку самой этой области, ибо проверка каждого тайла тоже не малая работа и когда их тысячи это сильно бьет по производительности. В нашем случае это все вышло немного сложнее, т.к. мало того что у нас ромбики так еще и карта не квадратная, в зависимости от строки и столбца число тайлов в ней\нем скачет, вместе с положением (а ведь так как рисовка идет по диагоналям, нужно определить начало и конец каждой). Кроме того так как карта у нас 3х мерная пришлось увеличить область поиска по оси Y на предмет возможных высоких "гор" снизу и "впадин" сверху, что могут попасть в нашу область. В итоге вышло вот что (сверху показан первый клипер, что делает выборку по тайлам, снизу результат после применения второго клипера что отсекает отрисовку вне заданной области):


pic-20160313-170918_.jpg



pic-20160313-171453_.jpg


Ну а заодно добавил скролл для карты, хотя еще остались пара небольших косячков, что надеюсь устраню в ближайшее время.
Game isn't a dream, it is the reality, reality which is coming while we dream...
Последнее редактирование: 13.03.2016 18:18 от StaticZ.
Тема заблокирована.
Спасибо сказали: AnnTenna, sam0delk1n

Новости с фронта 13.03.2016 19:32 #7205

  • sam0delk1n
  • sam0delk1n аватар
  • Вне сайта
  • Интересующийся
  • Сообщений: 76
  • Спасибо получено: 47
  • Репутация: 24
StaticZ пишет:
Ну если так смотреть, то можно сразу писать на ассемблере...
Не, высокоуровневые структуры помогают поддерживать порядок, разгружают сознание программиста, защищают от случайных ошибок, экономят время. Я считаю бинарный язык должен увеличивать уровень абстракции, но без отрыва от ассемблера, давать возможность писать код на любом подходящем уровне.

StaticZ пишет:
я принципиально не пользуюсь даже string
Можно сначала string, убедиться что всё работает, потом отдельные части заменять своими, если они удобнее или быстрее. Зависит от фокуса задачи, чтобы основная цель не затерялась в деталях.

StaticZ пишет:
Это лишь простой пример, у каждого компилятора свои заморочки и тараканы.
Всегда нужно выбирать в пользу стандарта. Компилятор по возможности выбрать наиболее совместимый. В gcc я встретил несколько багов, гуглил, читал на форумах, решение обычно находится. Если работа с компилятором планируется в течении нескольких лет, обычно вырабатывается набор решений обойти баги. Ну или почаще обновлять компилятор. Ещё стандарт описывает поведение std, но не его реализацию. У каждого компилятора реализация своя и разного качества. Например кажется в версии gcc 4.8 неработал std::thread, пришлось раздельно использовать pthread на linux и управление потоками через winapi на windows. Но в целом это не очень большие сложности.

StaticZ пишет:
Кстати а это вообще возможно?? за работу с дисками отвечает ОС и в современных ОС получить доступ к железу в обход ОС не является возможным, даже пара строк на асме для бибикания на динамике и то уже не прокатывают (вернее прокатывают, но для этого надо писать свой драйвер, подписывать его и регистрировать в ОС, а это слишком уж напряжно и сильно будет смущать пользователей). Единственный вариант это отмапить файл в память, но это опять же посути WinAPI и за то как именно веден себя менеджер памяти остается на усмотрение винды
Ничего шаманить не надо. Всё делается через winapi и gapi. Просто создаешь в озу небольшой буфер, по размеру самого большого ресурса (или его части). Например 100 мб. Затем читаешь с диска первый ресурс в буфер, из буфера в видеокарту, затем второй с диска в буфер и опять на видеокарту, и т.д., в озу только промежуточный небольшой буфер. Соответственно с диска в буфер читаешь через winapi, а из буфера на видеокарту загружаешь через gapi. В dx11 и выше есть функции которые это делают плавно, без фризов. В dx9 видимо нет, но можно выйти из ситуации: если после рендера остается время до следующей итерации, можно по чуть чуть передавать данные небольшими порциями. Только в случае потери устройства (которое есть в dx9, но уже нету в dx11 и выше), которое происходит когда например сворачивается полноэкранное приложение, все загруженные в видеопамять ресы будут утеряны, и их нужно заново загрузить с диска. Либо пользоваться другим режимом, который сохраняет копию данных в озу, но это двойной перерасход памяти. Но есть альтернативное решение: когда приложение в окне, оно не теряет устройство. Окно можно сделать borderless. Окно без рамки можно ровно совместить с экраном и будет полное ощущение что это полноэкранное приложение. Но нельзя будет менять частоту развертки. Разрешение можно менять заднего буфера, тогда при выводе на экран оно будет масштабироваться, немного смазано, но в целом ничего. В любом случае обычно все выставляют нативное для монитора разрешение и на рабочем столе и в играх.
Последнее редактирование: 13.03.2016 19:34 от sam0delk1n.
Тема заблокирована.
Спасибо сказали: StaticZ

Новости с фронта 13.03.2016 19:43 #7206

  • StaticZ
  • StaticZ аватар
  • Вне сайта
  • Разработчик
  • Демиург
  • Сообщений: 292
  • Спасибо получено: 143
  • Репутация: 68
sam0delk1n пишет:
Можно сначала string, убедиться что всё работает, потом отдельные части заменять своими, если они удобнее или быстрее. Зависит от фокуса задачи, чтобы основная цель не затерялась в деталях.
Ну вот поэтому когда фокус позволяет и предпочитаю C# ))

sam0delk1n пишет:
Затем читаешь с диска первый ресурс в буфер, из буфера в видеокарту, затем второй с диска в буфер и опять на видеокарту, и т.д., в озу только промежуточный небольшой буфер.
Ну так это стандартное чтение с харда в память с последующим копированием в видео память.
Game isn't a dream, it is the reality, reality which is coming while we dream...
Тема заблокирована.

Новости с фронта 13.03.2016 23:11 #7207

  • sam0delk1n
  • sam0delk1n аватар
  • Вне сайта
  • Интересующийся
  • Сообщений: 76
  • Спасибо получено: 47
  • Репутация: 24
StaticZ пишет:
Ну вот поэтому когда фокус позволяет и предпочитаю C# ))
Кстати вот C# для редактора самое то. Всякие эти кнопочки, окошечки и прочее, делать их самому вручную ужасно муторное занятие.

StaticZ пишет:
Ну так это стандартное чтение с харда в память с последующим копированием в видео память.
Механизмы стандартные, а их использование разное.

Вот например взять компьютер времён doom3/hl2. Это обычно 512-1024 мб озу и 64-128 мб видеопамяти. Разница в 8 раз. Поэтому обычно ресы загружались в озу и там держались, а в видеопамяти находились только те, которые нужны на небольшой промежуток времени чтобы рисовать только то что вокруг камеры в данный момент. Была даже такая технология на agp шинах, которая могла расширять объём видеопамяти, за счёт озу, просто потому что видеопамяти было мало. Теперь же её много, обычно от 50% до 100% от озу. Так что озу уже не рассматривается как некий кеш для быстрой подкачки. Всё что нужно для рендера прямо сейчас, уже должно быть в видеопамяти. А что понадобится в перспективе можно подгрузить с диска (пусть через небольшой буфер в озу). Но остальная озу нужна для других вещей: например звук может занимать много места, особенно рэндомный (музыку или диалоги можно стримить). Сами ОС сейчас много занимают озу. Всякие steam тоже не мало, особенно когда браузеры встроенные открывают. Одним словом озу просто не хватает чтобы использовать как зеркало для данных видеопамяти. Только небольшие буферы для перекачки данных там. Вот.

А что касается "без фризов". Вот взять опять же старую игру с большой локацией. Вот хороший пример Готика 3. Уже 10 лет прошло, а на чём не запускай её, она постоянно фризится при перемещении. Потому что чтение, распаковка, передача в видеопамять ресурсов идёт последовательно в одном потоке и рендер ждёт, прежде чем начать рисовать. А вот взять например новую игру Ryse. Там hdd по моему ни на секунду не останавливается, всё время грузит что-то новое, однако игра плавно работает: чтение, распаковка, передача в видеопамять идут в отдельном потоке, с более низким приоритетом чем рендер. А рендер рисует заранее подготовленную текстуру низкого разрешения, которая всегда в памяти и занимает мало места (обычно берётся mip уровень исходной текстуры). GTA 4,5 тоже имеют пример хорошего стриминга.

Вам я думаю это ненужно пока =). Хотя как можно гигабайт спрайтов нарисовать вручную я не понимаю, это студия художников целая нужна. В любом случае сразу на экране не весь гигабайт я думаю.

А как в этом 2d движке можно будет отображать закрытые пространства или несколько этажей здания? Ведь в следующих играх это будет?
Тема заблокирована.

Новости с фронта 14.03.2016 00:10 #7208

  • StaticZ
  • StaticZ аватар
  • Вне сайта
  • Разработчик
  • Демиург
  • Сообщений: 292
  • Спасибо получено: 143
  • Репутация: 68
sam0delk1n пишет:
Кстати вот C# для редактора самое то. Всякие эти кнопочки, окошечки и прочее, делать их самому вручную ужасно муторное занятие.
Это да всегда ненавидел ГУИ под С\С++ даже до шарпа предпочитал его делать в дельфях или лазарусе. Хотя шарп тоже не так уж хорошо в этом плане - контролов не так уж и много, единственный плюс что можно достаточно легко переписать под себя.

sam0delk1n пишет:
Сами ОС сейчас много занимают озу. Всякие steam тоже не мало, особенно когда браузеры встроенные открывают. Одним словом озу просто не хватает чтобы использовать как зеркало для данных видеопамяти. Только небольшие буферы для перекачки данных там. Вот.
Скажите это моим 64 гигабайтам ))))

sam0delk1n пишет:
Вам я думаю это ненужно пока =). Хотя как можно гигабайт спрайтов нарисовать вручную я не понимаю, это студия художников целая нужна. В любом случае сразу на экране не весь гигабайт я думаю.
Ну да не нужно и я не говорил о данном проекте, и кстати не обязательно для этого нужна студия, часто делают и аннимируют 3д модели а затем уже отснимают и загоняют в спрайты, при надобности подправляя.

sam0delk1n пишет:
А как в этом 2d движке можно будет отображать закрытые пространства или несколько этажей здания? Ведь в следующих играх это будет?
Не очень понимаю чем отличаются закрытые пространства - те же спрайты (в смысле спрайты другие, но технически тоже самое). С много этажностью в принципе тоже самое, просто нужен более умный буфер тайлов, что будет отсекать согласно неким правилам лишнии тайлы (к примеру те что находятся на втором этаже). Но сейчас в этом надобности нет, так как для игры это не нужно в принципе. А вот то что нужно это хорошая вода ну и тени, о которых потихоньку думаю. Думал сначала смухлевать (к примеру световое пятно на углу что напротив камеры и темное пятно в противоположном), но потом решил попробовать что-то серьезнее. Учитывая специфику алгоритмы освещения Фонга конечно тут не избыточны, в принципе хватило бы простого фейсет шединга, но неравномерность осветления\затемнения смотрится не очень, так что думаю над тем как сделать интерполяцию, на вроде как в освещении по Гуро... Вам конечно наверняка это покажется примитивным, но право считаю что этого будет достаточно, практика даже показала что высокие разрешения текстур больше портят картинку, лишь в случае крайне сильного растяжения... Вот потихоньку сижу ломаю голову как максимально упростить задачку, а для этого мне надо как минимум перейти к построчной интерполяции по Y.
Game isn't a dream, it is the reality, reality which is coming while we dream...
Тема заблокирована.
Спасибо сказали: sam0delk1n

Новости с фронта 14.03.2016 13:48 #7209

  • sam0delk1n
  • sam0delk1n аватар
  • Вне сайта
  • Интересующийся
  • Сообщений: 76
  • Спасибо получено: 47
  • Репутация: 24
StaticZ пишет:
А вот то что нужно это хорошая вода ну и тени, о которых потихоньку думаю.
Имеется ввиду затенение, в зависимости от угла поверхности к источнику света. Тень это когда она отбрасывается на поверхность от другого объекта. Кстати тень можно прямо в изображении спрайта рисовать.

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

А воду можно делать как в старых играх на 8 битных приставках. Там обычно всё заливается одним цветом (синим) и отдельные белые пиксели хаотично появляются, как бы блики от ряби.
Тема заблокирована.
Спасибо сказали: StaticZ

Новости с фронта 14.03.2016 14:43 #7210

  • StaticZ
  • StaticZ аватар
  • Вне сайта
  • Разработчик
  • Демиург
  • Сообщений: 292
  • Спасибо получено: 143
  • Репутация: 68
sam0delk1n пишет:
Имеется ввиду затенение, в зависимости от угла поверхности к источнику света.
Ну так клен пень, оно и имелось ввиду.
sam0delk1n пишет:
Кстати тень можно прямо в изображении спрайта рисовать.
Можно, но так можно сделать лишь статичные не динамичные тени. Я буду делать схером из исходного изображения затеняя не прозрачные пиксели основы. Это позволет легко сделать полупрозрачные динамические тени.

sam0delk1n пишет:
Они портят с точки зрения дизайна, дело не в разрешении, а в излишней зашумлённости фото-текстур
Дело не в зашумленности а в детализации, при сильном уменьшении детали становяться плохо различаемые (как на первом скрине там текстуры 128х128, а на последних 32х32).
sam0delk1n пишет:
для мультяшной графики лучше подходят текстуры с меньшим набором палитры и большими областями однородного цвета.
Не монотонные текстуры очень плохо ложаться, обязательно нужна "зашумленность", вообще как по мне на последних скринах почти идеальный вариант (на кривое освещение ака затемнение не обращайте внимание).

sam0delk1n пишет:
Лучше освещать попиксельно. Наподобие Фонга. Но видимо потребуется считать барицентрические координаты, а это затратная операция. Но если ландшафт не меняется и динамического освещения нет
Фонг слишком громзкие вычесления, да и и не даст тут особого эфекта, более чем достаточно фейсет шейдинга только с интерполяцией для равномерности, наподобии как Гуро. А рельеф кстати будет меняться и динамическое освещение тоже будет (правда только с одним источником света - солнцем, хотя в случае рельефа если припрет им можно и принебреч).
sam0delk1n пишет:
Гуро по моему не очень на больших тайлах будет, но можно и его попробовать.
Ну тут для освещения сильно подозреваю придется бить каждый тайл на 4 триангла и обрабатывать их по отдельности.

sam0delk1n пишет:
А воду можно делать как в старых играх на 8 битных приставках. Там обычно всё заливается одним цветом (синим) и отдельные белые пиксели хаотично появляются, как бы блики от ряби.
Я конечно тот еще мамонт, но это слишком даже для меня. Вода должна быть полупрозрачная, причем в зависимости от глубины (чем глубже тем меньше прозрачность), кроме того так как ее уровень будет меняться придется как следует повозиться с обработкой перекрытий. Кроме того там будут еще эфекты системы частиц для визуализации водных течений (что тоже являются одной из ключевых фич геймплея)
Game isn't a dream, it is the reality, reality which is coming while we dream...
Последнее редактирование: 14.03.2016 14:51 от StaticZ.
Тема заблокирована.
Спасибо сказали: sam0delk1n
Время создания страницы: 0.179 секунд
сайт другаСветлая зона и Академия РПГ Мейкераkn4kn5Плагины для RPG MakerДневник одной нэкоknНовая Реальность Топ Разработка игр