Тёмная тема
Разработчик фреймворков - как-то подозрительно звучит. А разработчики игр, которые будет этим фреймворком пользоваться?
Да и вообще тот факт, что TexturePacker сжимает хуже вас устроит? У меня лично он экспортирует всё с водяными знаками и за$%#вает напоминанием о покупке лицензии.
Что было бы очень интересно - библиотека с внятным интерфейсом, через которую можно было бы заказать какой метод использовать, кого, куда, еще какие опции. Все же обычно упаковщик ресурсов(по моему опыту) - лишь часть большой системы сборки.
Этот упаковщик сейчас оформлен в виде класса, и таки да, примечательно что его код практически не пришлось менять при портировании из шрифтового генератора, то есть выпуск библиотеки вполне возможен, но вот как делать Crop, Merge и т. п. - я не знаю, она же на Qt Pixmap завязана.
RPG
> Crop, Merge и т. п. - я не знаю, она же на Qt Pixmap завязана.
А нельзя просто имплементацию этих функций через Qt Pixmap зашить в результирующую библиотеку? Ну типа статически слинковать. Размер библиотеки увеличится, но это для утилитной библиотеки неважно...
Проблема в том, что тогда я обязываю всех разработчиков использовать Qt и грузить изображения только в Pixmap. А там обычно кто в лес кто по дрова...
RPG
А кто мешает во внешних интерфейсах не использовать ничего из Qt? Манипулировать изображениями на уровне путей, может еще каких-то сущностей, главное полностью абстрагируясь от реализации на Qt.
Обрезанные и перевернутые изображения как-то нужно отдавать:) Граф. оболочка, например, использует предпросмотр. Или придётся отдавать crop-data и оболочка сама должна резать картинки. В общем, я думаю, что скорее всего это будет просто как утилитка командной строки - и удобно использовать в сценариях, и можно прикрутить куда-нибудь.
+ Есть еще один вопрос интересный: у меня например свой велосипед уже давно есть, но до решения одной проблемы у меня так руки и не дошли - когда после сборки получается несколько атласов, то последний естественно является наименее плотно заполненным, соответственно этот атлас стоит отдельно пересобирать с отличными параметрами(размер атласа, метод и т.д.), чтобы максимально плотно упихнуть в меньший размер, то что осталось.
RPG
> Обрезанные и перевернутые изображения как-то нужно отдавать
Можно дескриптор операции создать - конфиг какой-нибудь(например с помощью libconfig). Но в целом это не надо - это не задача упаковщика атласов, обрезать и поворачивать(ну повороты только в процессе упаковки используются, но это пользователем напрямую не контролируется).
Paltr
> + Есть еще один вопрос интересный: у меня например свой велосипед уже давно
> есть, но до решения одной проблемы у меня так руки и не дошли - когда после
> сборки получается несколько атласов, то последний естественно является наименее
> плотно заполненным, соответственно этот атлас стоит отдельно пересобирать с
> отличными параметрами(размер атласа, метод и т.д.), чтобы максимально плотно
> упихнуть в меньший размер, то что осталось.
Я буду решать автоматическим выбором минимально возможного размера. Но пока функционал упаковки в много-корзин у меня не реализован, учитывая дикое число методов это займет время. Дополнительно там много вариантов эвристик и их можно также перебирать для достижения лучшего результата. Перебор достаточно долго выполняется, но может дать хороший результат - в отличие от шрифтов результаты упаковки менее предсказуемы и остается до 30% свободного места. В общем, я тоже решил что без нескольких корзин пока не буду выпускать бету - с шрифтами была другая история - важно сделать один спрайт для дипов, а тут - может быть море картинок, не влезающих даже в текстуру 4096. Также возможно будет "разрезание" больших спрайтов. Но это всё планы...
Paltr
> Но в целом это не надо - это не задача упаковщика атласов, обрезать и
> поворачивать(ну повороты только в процессе упаковки используются, но это
> пользователем напрямую не контролируется).
Возможно, у меня просто используются техники сортировки, поворота, слияния и обрезания для уменьшения занимаемого пространства, внешний тулкит может этого просто не уметь делать.
RPG
> Также возможно будет "разрезание" больших спрайтов.
Ну главное - чтобы это было бы интересно кому-либо, на твоем месте я бы опрос устроил надо ли оно кому.
RPG
> Возможно, у меня просто используются техники сортировки, поворота, слияния и
> обрезания для уменьшения занимаемого пространства
Ну подожди - это же автоматически в процессе упаковки делается, нет? А не пользователем вручную с помощью твоей утилиты(и даже если и такое есть - никто не мешает все эти действия простыми дескрипторами описать)? А ежели так, то как эти операции реализованы, извне видно не будет, это только ипмлементация. Значит внешних зависимостей видно не будет - будет твоя dll(so) и только - ничего более. Это то же что твоя программа бы принимала аргументы из консоли, просто в более удобном для программиста-пользователя виде...
Paltr
> Ну подожди - это же автоматически в процессе упаковки делается, нет?
Правильно, это всё делает упаковщик. При этом он у меня сейчас работает в двух режимах: предпросмотр и экспорт. В обоих случаях класс принимает массив QImage, и уже там выполняет все операции по конвертации. Сейчас упаковщик, утилита - всё в одном и выдает уже финальный атлас. В случае библиотеки мне придется принимать не растровые данные, а адрес файла, чтобы полностью отделаться от внешнего мира. Я думал уже разделить прогу на две части - пакер и оболочка, но тут нужен быстрый предпросмотр, и его как-то через темп-файлы пришлось бы гонять, что медленно.
Paltr
> Ну главное - чтобы это было бы интересно кому-либо, на твоем месте я бы опрос
> устроил надо ли оно кому.
Пока не знаю, профит только в том, что 8000 на 6000 можно затолкать в текстурки 1024 на 1024. ну мало ли, весь уровень нарисован в фотошопе и просто сохранен как слои:) А вот такой спрайт просто просится на разрезание, так как много пустого места:
Минус - нужна поддержка со стороны движка очень сложного формата составных атласов, особенно весело когда части одной картинки на разных текстурах - можете забыть про батч. Конечно, пустота по альфа-тесту отсекается, но и память жрёт.
RPG
> весь уровень нарисован в фотошопе и просто сохранен как слои:)
Ну ИМХО это уже задача разработчика разбить это так, как надо.
RPG
> В случае библиотеки мне придется принимать не растровые данные, а адрес файла,
> чтобы полностью отделаться от внешнего мира.
Ну это же просто - просто класс-обертка над текущим классом :)
RPG
> особенно весело когда части одной картинки на разных текстурах - можете забыть
> про батч.
Ну просто тогда нахождение текстуры нельзя заабстрагировать - придется ломать на другом уровне - нужно порождение геометрии для таких текстур. Но это возможно только для простых случаев. В общем там ОЧЕНЬ много подводных камней, если что-то подобное нужно - это весьма специфичная штука и она должна реализовываться разработчиком.
Моя миссия пока - сделать хотя бы упаковку атласов:). Алгоритм хороший и в принципе даже без вращения уделывает всякие платные TexturePacker'ы. А вращение я добавил - будет в файле описания помечаться дополнительной буковкой r. Ну и дополнительно сможет на несколько текстур один атлас размазывать. Поддержка со стороны движка причём уже есть давно.
RPG
Ну ок :) Удачи тогда - буду следить за проектом.
Тема в архиве.