Честно говоря с пиксельартом не пробовал, не работаю в данном стиле. Нахожу 99% его реализаций сегодня жутким трешем с пикселями разного размера, мерцаниями при движениях и так далее. У вас пока пиксели очень радуют глаз.
Они не выпуклые, а наоборот. Максимальный уровень «выпуклости» достигается не более контура модели. Поглядите, те «выпуклые» в максимуме не больше «золота».
Достигается это множеством путей, но в целом схоже с обычным рейтрейсингом. То есть имеем карту высот, угол падения зрения к плоскости, вычисляем какая точка насколько уходит «вглубь», что перекрывает что. На эту тему почитайте про parallax occlusion mapping например. Реалистичности подобным «выпуклостям» добавляет еще self-shadowing, тогда вообще чудесно выглядит…
Про последний вопрос — это или постпроцесс или отдельный полигон. Вне модели шейдер ничего сделать не может. Весь материал только на модель наносится. Так что любое свечение это уже потом.
>>Потери в скорости при этом были около 20%
Довольно голословно. Демку бы.
>> будет образовываться чёрная рамка, у чёрных наоборот белая
Анимации на атласе имеют обыкновение по краям быть прозрачными, либо не менять свой цвет от кадра к кадру так сильно. Надумано довольно.
>>Если спрайтов 11, то в последних 2 строчках будут пустые места
Бывает такое, но это не очень критично, если честно.
>> 4096х4096 мне не хватает. А вам?
А мне хватает 2048х2048
>>А отдельные кадры можно подгружать уже по ходу воспроизведения анимации
А если не успеете? Всё будет крешиться? Или не рисоваться?
Мне такой подход кажется неприемлемым. Пользователь не должен видеть подгрузку ни в каком виде.
>>лучше тупо сделать 36 маленьких текстур
И чем же лучше? У вас на экране, скажем 100 таких анимаций одновременно, но все в разных стадиях, на разных кадрах. В вашем случаем мы получаем 100 смен стейтов, 100 Draw Call. Ужас, кошмар и тормоза.
Если текстура не кратная степени двойки, то в вашем случае будет довольно немалый оверхед по памяти лишней съеденной.
>>1)Немного меньше скорость чтения из такой текструры, чем из кадра отдельно
Наложение текстуры по UV всей текстуры или кусочка не отличается по скорости никак.
>> 2)Проблемы с фитрацией на краях кадров
Какие у вас проблемы, покажите пример?
>> 3)Из количества кадров должен извлекаться корень, что бы не было пустых мест на текстуре
Это вообще я не понял что за минус такой.
>> 4)Количества кадров ограничено максимальным размером текстуры
Вам кто-то запрещает бить анимации на несколько подобных атласов, или не хватает 4096х4096 текстур?
>> 5)Такую текстуру тяжелее стримить без пролагов чем отдельные небольшие кадры(т.е. плавно прогружать уже по ходу игры)
Такую текстуру можно грузить по мипмапам, и анимация будет уже целиком в памяти в худшем качестве, пока ваши 36 картинок будут еще грузиться.
Нет, не тоже самое. попробуйте замедлить скорость смены кадров до 5-10 в секунду и все будет дерганым. Да и даже на 25 все не сказать чтобы жутко плавно было. Речь о том, чтобы именно не было этой дерганности.
>>К игре, которая была выложена на площадке, был прикреплен урезанный вариант игры на Google Play. Так вот. За положенные полтора дня естественного прироста интереса, никто не скачал прототип.
Кстати, судя по времени, проводимому людьми на страничке они и видео не всегда смотрят. Зачастую решая уже по скриншотам. Так что скриншотов лучше не 200, а 4-5, но самых сочных, а дальше можно и еще несколько сотен, если хочется.
Недавно игра прошла с 351 голосом. Так что 400 не минимум. Но учитывая, что предыдущей игре в том году пришлось набирать более 1200 голосов, то число это стремительно падает.
Насколько я знаю там вообще не надо мешать русский \ английский, он будет выставляться автоматом в зависимости от региона игрока, зашедшего к вам на страничку.
Но в целом идею про английский поддерживаю, мы именно с английским текстом шли на первом месте.
>>Встроенная память 64 или 128 ГБ UFS 2.0
Так сколько же на самом деле?
Спасибо вам за интересную статью. Нового для себя почерпнул мало, но картинки посмотрел с удовольствием.
Достигается это множеством путей, но в целом схоже с обычным рейтрейсингом. То есть имеем карту высот, угол падения зрения к плоскости, вычисляем какая точка насколько уходит «вглубь», что перекрывает что. На эту тему почитайте про parallax occlusion mapping например. Реалистичности подобным «выпуклостям» добавляет еще self-shadowing, тогда вообще чудесно выглядит…
Про последний вопрос — это или постпроцесс или отдельный полигон. Вне модели шейдер ничего сделать не может. Весь материал только на модель наносится. Так что любое свечение это уже потом.
Серебро и золото совершенно неубедительны. Более того, серебро еще и не похоже. Откуда такие разводы, будто по нему бензин разлили?
Спасибо!
Довольно голословно. Демку бы.
>> будет образовываться чёрная рамка, у чёрных наоборот белая
Анимации на атласе имеют обыкновение по краям быть прозрачными, либо не менять свой цвет от кадра к кадру так сильно. Надумано довольно.
>>Если спрайтов 11, то в последних 2 строчках будут пустые места
Бывает такое, но это не очень критично, если честно.
>> 4096х4096 мне не хватает. А вам?
А мне хватает 2048х2048
>>А отдельные кадры можно подгружать уже по ходу воспроизведения анимации
А если не успеете? Всё будет крешиться? Или не рисоваться?
Мне такой подход кажется неприемлемым. Пользователь не должен видеть подгрузку ни в каком виде.
И чем же лучше? У вас на экране, скажем 100 таких анимаций одновременно, но все в разных стадиях, на разных кадрах. В вашем случаем мы получаем 100 смен стейтов, 100 Draw Call. Ужас, кошмар и тормоза.
Если текстура не кратная степени двойки, то в вашем случае будет довольно немалый оверхед по памяти лишней съеденной.
>>1)Немного меньше скорость чтения из такой текструры, чем из кадра отдельно
Наложение текстуры по UV всей текстуры или кусочка не отличается по скорости никак.
>> 2)Проблемы с фитрацией на краях кадров
Какие у вас проблемы, покажите пример?
>> 3)Из количества кадров должен извлекаться корень, что бы не было пустых мест на текстуре
Это вообще я не понял что за минус такой.
>> 4)Количества кадров ограничено максимальным размером текстуры
Вам кто-то запрещает бить анимации на несколько подобных атласов, или не хватает 4096х4096 текстур?
>> 5)Такую текстуру тяжелее стримить без пролагов чем отдельные небольшие кадры(т.е. плавно прогружать уже по ходу игры)
Такую текстуру можно грузить по мипмапам, и анимация будет уже целиком в памяти в худшем качестве, пока ваши 36 картинок будут еще грузиться.
А что Вас удивляет? Разумеется пропускать, нельзя показать все 150.
Вы еще учтите, что такое количество кадров жрет нехило памяти, и это очень жирно, даже сейчас с гигабайтами.
Я у себя, например, интеполирую кадры анимации, получая более плавную картинку.
Кстати, судя по времени, проводимому людьми на страничке они и видео не всегда смотрят. Зачастую решая уже по скриншотам. Так что скриншотов лучше не 200, а 4-5, но самых сочных, а дальше можно и еще несколько сотен, если хочется.
Но в целом идею про английский поддерживаю, мы именно с английским текстом шли на первом месте.