int *ptr = malloc(sizeof(int) * N); if (!ptr) ... Для N=0 имеем "the behavior of malloc is implementation-defined", получается классической проверки всё равно не достаточно, могут быть ложные срабатывания. Что если беззнаковое выражение sizeof(int) * N переполнится и выделится меньше, чем ожидалось. Сплошные вопросы от кода C...
В запасе еще есть как минимум 2 способа для iOS:
1) Положить все ресурсы в zip без сжатия и сменить расширение полученного архива на что-то другое (dat). Будет экономия на подписях — вместо сотни файлов только один. Плюс некий аналог solid архива для ipa.
2) Положить все ресурсы в .7z. Придется проверить приемлемость скорости запуска. Важен баланс…
На сам текст могут накладываться эффекты. По большому счету это быстрые аналоги эффектов из программ Adobe Photoshop/Flash. В движке есть опция рисовать ли эффекты отдельно (чтобы буквы читались поверх тени) или можно применять сразу для глифа. Особо сложные надписи выполнены художниками в растре. Но это уже скорее не про артефакты…
Про анимации как раз есть интересный момент: мы рассчитываем финальное положение и размер надписи (prescale) и на этих данных запускаем анимацию. Таким образом при пульсации глифы не перестраиваются.
Успешно применяем бесплатные векторные шрифты и библиотеку. Размер шрифта делаем такой, чтобы глиф получился ровно по физическим пикселям. Получаются четкие тексты.
Когда на сцене не слишком много надписей хорошее ускорение дает кэширование глифов: растеризация символов делается один раз, а рисование готовых символов происходит достаточно быстро в каждом кадре.
У нас при создании атласов (статических) препроцессинг делается самостоятельным шагом. Для динамических атласов хорошим подспорьем будут заранее подготовленные блоки. Также рекомендую решение с premultiplied alpha для несжатой графики.
Обсуждение сжатия в Unity натолкнуло на мысль сделать прокладку совместимую с PVRTexTool, но умеющую вызывать нужный упаковщик в зависимости от командной строки.
За последний год с PVRTC4BPP провел много экспериментов и тоже наблюдал проблемы со сжатием альфы. На некоторых проектах применяем сжатие аналогично 2xETC1 — когда RGB(PVRTC4) + A(PVRTC4), но это по метрикам слабее, чем 2xETC1. Пока не определились будет ли статья про PVRTC4. Тем не менее, успешно используем свою утилиту сжатия в PVRTC4, и качество заметно выше.
Решение для ETC1 получилось хорошее, поэкспериментирую с Unity…
А так витают мысли скрестить ETC1 от EtcCompress и ETC2 от etc2comp, был бы мощный инструмент.
Код открытый, возможно всё. Утилита понимает командную строку. Стоит доработать функции-заглушки LoadEtc1 и SaveEtc1 под нужный формат, например KTX/PVR.
Если есть конкретный пример командной строки и известен формат могу попробовать доработать.
int *ptr = malloc(sizeof(int) * N);
Для N=0 имеем "the behavior of malloc is implementation-defined", получается классической проверки всё равно не достаточно, могут быть ложные срабатывания.if (!ptr) ...
Что если беззнаковое выражение
sizeof(int) * Nпереполнится и выделится меньше, чем ожидалось. Сплошные вопросы от кода C...1) Положить все ресурсы в zip без сжатия и сменить расширение полученного архива на что-то другое (dat). Будет экономия на подписях — вместо сотни файлов только один. Плюс некий аналог solid архива для ipa.
2) Положить все ресурсы в .7z. Придется проверить приемлемость скорости запуска. Важен баланс…
Когда на сцене не слишком много надписей хорошее ускорение дает кэширование глифов: растеризация символов делается один раз, а рисование готовых символов происходит достаточно быстро в каждом кадре.
А так витают мысли скрестить ETC1 от EtcCompress и ETC2 от etc2comp, был бы мощный инструмент.
Если есть конкретный пример командной строки и известен формат могу попробовать доработать.