Большая текстура не отрисовывается

[zand]

Здравствуйте!

Есть такая проблема. Имеем картинку размером 13000х768 (размер текстуры 16384х1024). Такая длинная, чтобы можно было скроллировать экран.
Image создается нормально, никаких ошибок, судя по отладчику. Данные из стрима тоже вроде загружаются, но она не отрисовывается. Точнее, не отрисовывается ее часть, размером с экран.

Подскажите, в чем может быть проблема? Подозреваю, что как-то связано с размером видеопамяти, но в то же время ведь DirectX текстура требуемого размера создается без ошибок.

[Aegis]

В чём конкретно проблема не знаю (в твоём случае), но так делать не стоит по-любому. Хотя многие СОВРЕМЕННЫЕ видеокарты и поддерживают разрешение текстур больше 1024 и даже 2048, но впихивать 16384 это уже почуть перебор... По-нормальному разбей рисунок на текстуры по 1024x1024 и отрисовывай нужные части двух соответствующих текстур. Тогда и работать будет не только на самых новых видюхах, и отрисовываться намного быстрее. А вообще, что это за программа такая? Если игра (а рисунок - фон), то это как-то крутовато - тратить столько видеопамяти на один бэкграунд Обычно используют парочку-троечку циклично повторяющихся рисунков, которые на фоне неспеша перемещаются... А при переходе на "новую" территорию/уровень старые картинки выгружаются из памяти и грузятся новые. Если не игра - вопросов нет

[zand]

Это игра, не не простая. Бек не повторяющийся вообще.

А можно подробнее, как это организовать? В смысле, хранить всю картинку одной записью в базе, но разбить эту запись на несколько текстур?

Или резать прям руками эту "ленту" и создавать запись для каждого куска?

[Aegis]

1) Можно резать руками (есть проги для этого, режут/склеивают анимацию).

2) Я пользуюсь eXtreme, там при добавлении картинки указываешь размер текстуры, после чего она сама режется на нужное кол-во текстур. Если указать размер кадра 1024x1024 и текстуру такого же размера, то потом при отрисовке номер кадра (Pattern) будет равнозначен номеру текстуры. В базе получится одна запись. Этим и удобен TAsphyreImage относительно простой текстуры. Думаю, в Sphinx всё точно так же.

Бэк в 2д-играх обычно абстрактный, поэтому как правило повторяется, тем более обычно движется медленно (для получения такого аля-3д из нескольких 2д слоёв). Хотя, никто же и не говорил что это платформер, это мне после слова "скроллинг" сразу так подумалось... Что же это за игра с таким бэком? Заинтриговал

[zand]

Здравствуйте!

Проблему частично "решил", но все-таки пара вопросов осталась.
Мне не совсем понятен смысл разделения на паттерны и текстуры. Можете пояснить?

Вот есть у меня серия кадров. Иногда эта серия может быть достаточно длинной. Доступ к кадрам я использую через паттерны, т.е. все кадры находятся в рамках одной текстуры. Однако, на некоторых компах текстуры более 2048 не загружаются, выдает ошибку загрузки ресурса.
Получается, что для длинных серий нельзя использовать паттерны, а каждый кадр нужно хранить в отдельной текстуре? Я правильно понимаю?

А в чем принципиальная разница, в случае анимации, между паттернами и текстурами?

[Aegis]

Не совсем так.

AsphyreImage в отличие от текстуры удобен тем, что конечному пользователю (программисту) не нужно заботиться о разбиении анимации на текстуры и, собственно, текстуры на паттерны - как раз обо всём этом и заботиться AsphyreImage.

Если имеется анимация, например, из 20 кадров на рисунке размером 2048 * 512 - можно при добавлении рисунка в ASDb указать размер текстуры 512x512 - в таком случае анимация будет разбита на 4 текстуры, и на каждой будет по 5 кадров (а не каждый кадр на отдельной текстуре).

То есть, для длинных серий паттерны использовать как раз-таки можно и нужно, а разбитие на текстуры будет произведено самим Asphyre Manager при добавлении рисунка (размер текстуры там указывается).

И, как я уже говорил - текстура более 1024x1024 - это жирно, особенно для 2д игрушки (если, конечно, это не супер-навороченная игруха изначально позиционируемая как hi-end под топовое железо, где используются всякие карты теней высокого разрешения и т.д.).

Если говорить непосредственно о производительности - надо достичь как можно меньшее количество переключений текстур и при этом стараться использовать как можно меньшие размеры текстур...

[zand]

О, спасибо!

Начинает проясняться потихоньку! То есть в базу автоматом поместится изображение и будет разбито на текстуры? А потом я буду обращаться к конкретному кадру по номеру паттерна,так?

Для примера: кадр имеет размер 200х200. Серия из 100 кадров хранится в картинке размером 2000х2000 (10х10 кадров). Я хочу, чтобы размер текстуры не превышал 1024х1024. Устанавливаю это в параметрах. Получается, что будет создано 4 текстуры, по 25 кадров каждая?

А что будет с границами кадров? Или, если я укажу размер одного кадра, то картинка будет правильно порезана по границам кадров?

Картинку с анимацией я подготавливаю при помощи ImageMagick, которая делает из серии результирующую картинку максимально приближенную к квадратной. Такой формат подойдет для AsphyreImage?

Спасибо за оперативные ответы!

ЗЫ: игра, конечно, не навороченная, просто персонажи достаточно крупные и много анимации. детская развивающая игра...

[Aegis]

1) Да, именно так.

2) Тоже совершенно верно, будет создано 4 текстуры по 25 кадров.

3) Да, будет порезана правильно по указанным границам. Картинка может быть как вытянутая в длину (100 кадров подряд слева направо), в высоту (100 кадров сверху вниз), так и в любом другом порядке (50x2, 25x4, 10x10 и т.д.). Естественно, кадры должны плотно примыкать друг к другу и иметь одинаковый размер.

4) Насчёт "квадратности" картинки не совсем понял, но попробую ответить: отношение ширины к высоте не имеет значения, кадр может быть размером как 10x1024 так и 512x512 - это не имеет вообще никакого значения. Главное чтоб размер текстуры был 2^n (опять же, вовсе не обязательно квадратная, хоть 16x1024). И, как я уже говорил, все кадры (в пределах одного рисунка, одной анимации) должны быть одинакового размера. Не нужно стараться делать их как можно "квадратнее", нужно (не обязательно, конечно, просто и рендерится быстрее будет и занимать меньше места в базе) максимально уменьшить размер кадра (убрать лишнее пустое пространство).

[zand]

Здравствуйте!

Вроде бы все получилось, большое вам спасибо! Теперь все гораздо оптимальнее

1. Однако, иногда проявляются некоторые артефакты (тонкие вертикальные и горизонтальные линии - cм. аттач). Ощущение, что проблема в текстуре (последний паттерн) данного персонажа. Скажите, а размер паттерна имеет какие-нибудь ограничения? Скажем, должен быть кратен двум или еще что-то...

2. Кстати, а просмотрщик базы действительно с багами? Или это я неверно текстуры формирую? Дело в том, что он как-то странно отображает текстуры и сетку паттернов. Во-первых, запись содержит три текстуры, а просмотрщик записи позволяет увидеть только две, а во-вторых, начиная со второй текстуры сетка безжалостно едет по вертикали. Или может у меня версия старая (2.21)?

Спасибо.

[Aegis]

Привет

1. Нет, размер паттерна не имеет ограничений. Артефакты появляются строго скраю данного паттерна, или внутри? Если первый случай, то, думаю, причина следующая: при повороте/деформации паттерна (если деформации нет - причина другая) и при включенном AntiAlias канваса, происходит аппаратное сглаживание выводимой текстуры, т.е. смешиваются соседние точки. Таким образом, верхняя/левая граница паттерна может захватить для сглаживания пиксель с прерыдущего. Решение - ограничить каждый паттерн с каждой стороны одним пикселем с нулевым альфаканалом или не использовать antialias или не вращать спрайты. Во многих казуалках наблюдал подобные артефакты во время какой-либо анимации, они похоже на них просто забивают.
Вообще, по аттачу непонятно происхождение артефактов, особенно нижнего - не похоже, что он лежит на краю паттерна... Если действительно не лежит, и никакой деформации не происходит - будем думать дальше...

2) Просмотрщик действительно ведет себя несколько странно, как будто упаковка идёт плотно кадр за кадром, поэтому я некоторое время ошибочно считал, что некоторые паттерны захватывают сразу две текстуры, но когда понял что это напрямую противоречит базовым требованиям производительности, выяснилось что проблема в просмотрщике, а упаковка работает всегда правильно. Можно не обращать на это внимания.