Войти
ПрограммированиеФорумГрафика

Текстурный кэш (4 стр)

Страницы: 1 2 3 4 5 Следующая »
#45
20:04, 27 окт. 2013

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

Вот например Sonic с Sega Genesis:
Изображение


#46
20:05, 27 окт. 2013

> есть некое давление со стороны
SoulSharer, какое ещё давление? С какой ещё стороны? Пусть сидят и рисуют - это их работа. А программить - работа программера. Пусть каждый занимается своей работой, а не суёт нос в дела, в которых он дуб дубом ;-)

>Учитывая то, что еще и в Deponia все было с этим хорошо
А если кто-то посрёт себе на голову и ему будет от этого хорошо - от тебя "команда" потребует что бы ты делал так же? )))

#47
20:09, 27 окт. 2013

slava_mib
лол, есть в этом правда, но наверное тут еще и перфекционизм отыгрался :)

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

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

#48
20:16, 27 окт. 2013

> либо сжимать с небольшими артефактами
SoulSharer, с этого надо было НАЧИНАТЬ, а не заканчивать. Потому как это был самый простой и самый быстрый способ - начинать надо именно с таких, что бы минимально терять время на всякую фигню. Лучше за неделю успеть реализовать 10-15 простых методов, чем сидеть с 1 сложным.

Артефакты там, как я уже писал выше - на глаз заметить очень сложно, даже почти что невозможно, если не знать где именно их искать. Тем более, в принципе, если у тебя конвейер уже выстроен был - для внедрения этого решения, тебе всего лишь надо было перекодить текстуры в pvrtc, что, по факту, заняло бы не не делю и даже не 2-3 дня, а 2-3 часа - и то не твоей работы, а работы компрессора pvrtc... Думаю, 3 часа - не то время, которое надо было экономить, после чего попусту потратить 2 недели )))

З.Ы. Тайлы не помогут - это такой же тупик, как тот, которым ты занимаешься сейчас.

#49
20:28, 27 окт. 2013

Да, пожалуй стоит загнать все это под компресс уже наконец и посмотреть финальную картинку. Судя по вашему опыту более чем уверен, что разницы мы и не увидим.
А время наверняка только уйдет на разбор командной строки компрессеров, поиска наилучшего сжатия, а все остальное поменять это минут 5-10.

Вобщем говоря спасибо за помощь, будем делать.

#50
21:48, 27 окт. 2013

slava_mib
> Артефакты там, как я уже писал выше - на глаз заметить очень сложно, даже почти
> что невозможно, если не знать где именно их искать

Да ну. У автора векторная двумерная графика с альфой. Артефакты будут заметны и весьма. Покажите мне игру топ гроссинга на мобильных с подобной графикой и применением pvrtc. Таких кажется просто нету. Картинка становится значительно грязнее.

#51
22:16, 27 окт. 2013

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

#52
23:01, 27 окт. 2013

> Да ну. У автора векторная двумерная графика с альфой. Артефакты будут заметны и весьма
glap, артефакты вылезают на градиентах или не контрастных цветах. Судя же по персу - тут ситуация строго противоположная. Потому, думаю, даже не нужно будет зашумлять картинку - и так нормально будет. Тем более, выше я уже писал - можно просто поднять разрешение арта и тогда артефакту станут ещё менее заметны.

> возможно для статики еще и незаметно, но вот в по-кадровой анимации очень даже заметно, потому что что на разных кадрах оданиковые области внешне слегка разнятся
Frankinshtein, у нас, в пререндеренной графике с кучей цветов и оттенков - не заметно совершенно. Так что, думаю, должно быть нормально. В любом случае - попробовать, ИМХО, стоит. Т.к. есть шанс совершенно ничтоженой ценой решить кучу проблем. Ну а уж если не получится - тогда и надо искать более сложные решения, ИМХО.

#53
23:06, 27 окт. 2013

Именно на переходах цветов в векторе и заметно. Особенно на светлых тонах. В тёмной графике ещё куда ни шло. Любопытно было бы посмотреть вашу графику если есть возможность. Я реально не видел пока удачных решений с ПВР в 2Д.

#54
23:21, 27 окт. 2013

Посоны, вы на ровном месте в стенку долбитесь, сколько можно-то уже?
Нужна обычная видео текстура, разве что сжатие стоит подобрать с учетом специфики арта.
Я бы даже не заморачивался с видео-кодеками, тупой RLE-на-коленке утрамбует всё в десятки раз.
Далее апдейт текстуры смешного размера 30 раз в секунду (а то и меньше, зависит от анимаций) по цене примерно копирования памяти.

Ну и?

#55
23:38, 27 окт. 2013

>Любопытно было бы посмотреть вашу графику если есть возможность.
glap, на iOS пока не вышли (на апруве у издателя), а андроид (ETC), можно посмотреть: https://play.google.com/store/apps/details?id=com.chillingo.tinyc… roid.rowgplay -  советую поставить на девайс и там смотреть - мы тестили на всём, начиная от 320x240 до 1920x1080 - везде качество нас устроило. Могу сказать, что на iOS (там PVRTC) графика на глаз не отличается. Смотреть там проще всего в магазе - если кникнуть по зданию в магазине, то откроется большое окошко с превьюшкой здания. Если здание анимировано в игре - оно будет с анимацией и в магазине.

> Ну и?
x, ну и это тоже затраты времени - причём, вряд ли пара часов. ну и рисованные анимации, при жатии в видео без потерь дадут экономию не сильно больше, чем хранение просто отдельных кадров (что тоже вполне даже вариант).

#56
0:40, 28 окт. 2013

slava_mib
Да ладно, покадровый RLE не пара часов? 10 строчек на сжатие, 10 на разжатие.

> при жатии в видео без потерь дадут экономию не сильно больше, чем хранение просто отдельных кадров
...
>Я бы даже не заморачивался с видео-кодеками, тупой RLE-на-коленке утрамбует всё в десятки раз.

#57
1:53, 28 окт. 2013

slava_mib
> а андроид (ETC), можно посмотреть:
в ETC1 нет альфы, потому сравнение не совсем корректно с PVRTC
понятно, что вы выкрутились запаковав альфу в RGB того же или 2ого ETC1, цена этого  2х кратное увеличения памяти, что все равно лучше, чем голый RGBA32.

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

#58
3:44, 28 окт. 2013

На мой взгляд, стоит сразу отказаться от сжатия без потерь, ибо это очень серьезный удар по размеру. В то же время, использовать железные форматы стоит только в том случае, если все помещается в память или можно наладить стриминг (что не наш случай, как я понял). Основной недостаток железных форматов в том, что они тратят фиксированное количество бит на блок, что абсолютно неэффективно, а также не имеют возможности настраивать качество. Стоит хранить все анимации в памяти целиком в качественном софтовом сжатом формате (png c палитрой, jpg, h264) и разжимать на лету. Выбор формата определяется возможностями железа.

#59
7:27, 28 окт. 2013

> Да ладно, покадровый RLE не пара часов? 10 строчек на сжатие, 10 на разжатие.
x, в условиях реального проекта - нет, не пара.

> только вот для PVRTC такое не пройдет
Frankinshtein, конечно, там же альфа есть - зачем извращаться? ))

> можешь выложить реальный пример сжатия какой-нибудь анимации в PVRTC где совсем не заметно искажений?
Frankinshtein, у меня его нет - он в игре, а игра на iOS ещё не заапрувлена и её нет в маркете. Но если нас (разрабов) качество устроило, устроило наше руководство, устроило наших тестеров, устроило Q&A чиллинги - почему оно не должно устроить т/с ?

> На мой взгляд, стоит сразу отказаться от сжатия без потерь, ибо это очень серьезный удар по размеру
}:+()___ [Smile], поддерживаю на 200%.

> а также не имеют возможности настраивать качество.
Имеют. Но тут правило такое - что в релизе всегда должно быть макс качество. Ибо настройки качества никак не влияют на размер - они влияют только на качество ))

> если все помещается в память или можно наладить стриминг (что не наш случай, как я понял).
}:+()___ [Smile], выше я уже делал калькуляции, из которых вышло, что у TC весь арт (который он назвал по крайней мере) легко влезет в память и ещё останется целая куча места, в которое можно запихать ещё больше арта, чем у него есть сейчас.

Страницы: 1 2 3 4 5 Следующая »
ПрограммированиеФорумГрафика

Тема в архиве.