В казуалках есть одна штука, в которой есть месту техническому теку - это пайплайн, хорошо сжимающий графику. Кто-то считает что необоснованно "пользователю всё равно сколько скачать, 10 мегабайт или 100, он не разбирается", кто-то считает что важно "+10 % к размеру - минус 1% пользователей", ну и видел даму которая не скачивает игры с большим
(
Read more... )
в современных видеокодеах стоп-кадры пакуются с адаптивной квантизацией, как раз для этого.
2. Зачем редактор? Почему бы не определять по уровню шума автоматически эти квадратики?
Ну и "размытие" rgb канала это must-have для любых игр с текстурами с альфой, по понятным причинам. Ничего специфически казуального нету.
Reply
Функция загрузки текстуры есть, функция "нарисовать квадратик там" есть, 10 строчек на загрузку, 5 строчек на отрисовку, зачем вчитыватся в 1000 строчек libjpeg?
2) уровень шума - это не самая лучшая метрика для определения "человеческий глаз видит тут херню". Например, шум на волосах или на облаке может быть очень большой, а шум на глазах или губах меньше.
Reply
2) SSIM - примерно метрика для "человеческий глаз видит фигню". Картинок исходных нет, а то можно было бы проверить.
Ну то есть - сделано было как сделано, понятно.
Но на мой взгляд, что это очень сложный пайплайн, требующий большого количества ручного труда и не устойчивый к изменениям.
Reply
2б) Глянул в википедию, я не вижу что бы он хотя бы углы и границы считал чем-то более важным, не говоря уж о лице. Ну и даже абстрактные углы и границы не абсолютный показатель, листва дерева может быть любой, а вот глаза - нет.
Редактор был очень примитивный :) Я за первые полдня написал редактор, за вторые - прошелся по 25 комиксам. Естественно, если стоит задача ужать 5000 картинок в гигабайт, то это совсем не задача про то что бы ужать 25 картинок в 5 мегабайт.
Reply
У меня и отчеты есть.
Reply
А сколько же тогда занимала "работа над png сжатием", ещё месяц? :)
afair, первый маджонг сделали за четыре с половиной месяцев, май-июнь-июль-август, первый месяц был потрачен чисто на спрайтовый движок на DX8. Видимо, его и обозначили "работа над jpeg" :)
Вот этот редактор - он был сделан для комиксов второго маджонга, вне каких либо тайм-трекеров, и уже не в старом офисе.
Reply
Я прекрасно помню как и над чем шла работа в первом МА, мне не нужны были отчеты, я и лично все видел. И как раз тогда-то все делалось быстро и эффективно.
А вот при работе в МА2 - ты работал над jpeg сжатием, и редактором, и у меня были только отчеты.
Ну и почему-то - МА2 делался дольше, хотя и спрайтовый движок, и базовая логика уже были. :(
Думаю, впрочем, дело все-таки не в редакторе jpeg, который делался полдня :)
Reply
1) тупой скрипт сортировки тестур по коэффициенту степени сжатия умноженный на размер текстуры, что бы найти голубое небо 2048x2048 в RGBA8888.
2) выкидывание тестур и моделек, на которых не было ссылок из уровней.
Reply
2) вообще немного странный - текстуры и модельки, на которых нет ссылок, не должны попадать в игру, и не надо их выкидывать соответственно. Это, кстати, и TCR такой есть.
Для гигабайтов графики есть вполне себе техники сжатия, но там другое - практически всем наплевать, сколько занимает игра - 2гб или 4. Надо только влезать в фиксированные размеры (размер DVD, например, или лимит скачивания в XBLA).
Reply
Reply
И что, на PC в MMORPG принято что ли складировать никогда-не-используемые файлы в дистрибутив игры? Не верю :). Это же абзац, считать такое "методом сжатия".
TCR, кстати, тоже на пустом месте возник.
Reply
Вот про это я написал, что в MMORPG для PC не наплевать на размер, он влияет на количество игроков
> на PC в MMORPG принято что ли складировать никогда-не-используемые файлы в дистрибутив игры?
Не принято, такие файлы Винни и устранил.
Reply
Reply
Чтобы художники могли класть что захотят, а в билд попадало только то, что нужно.
Reply
Как такое можно проверить на практике вообще...?
Reply
Reply
Leave a comment