mikhailk, atf формат не пробовали? Они меньше видеопамять потребляет.
Если старлинг не последней версии, лучше обновить. Пару дней назад вышел 1.6 с множеством оптимизаций.

Старлинг как раз 1.6 поставил сегодня. Там, кстати, у АссетМенеджера появился параметр количества параллельных загрузок. Думал, если поставить 1, то асинхронная загрузка станет синхронной. Тоже не помогло.

ATF-формат не пробовал, спрайтшиты собираю в пнг.

Кстати, а как можно посмотреть доступный остаток видеопамяти?

Через scout. Кстати, изучите свой проект через скаут. Возможно, это поможет разобраться с проблемой.

При запуске на компьютере у меня получается (смотрю через Scout), что приложение занимает примерно 320Мб памяти GPU. Походу, это и есть проблема? Надо уложиться в 256?

Добавлено через 15 минут
Не, не в этом дело.
Поставил скалирование, чтобы суммарно текстуры уложились в 95Мб, все равно смартфон отвалился на том же этапе.

В общем, пища для размышлений:

- в основном приложении у меня пара изображений подключалась как Embed и затем грузилась в память через Texture.fromEmbeddedAsset
- я собрал стендик, в котором эти изображения грузятся как и все остальные через AssetManager, и на стендике добиться падения мне не удалось - все грузится и крутится.

Т.е., походу для надежности надо отказаться от любых вариантов загрузки/создания текстур, кроме как спрайтшитов через AssetManager. Но факт требует проверки.

ЗЫ. Глюк проявляется не на всех девайсах. У меня проявлялся на Samsung Galaxy SII.

В общем, ситуация такова - у меня глючил даунскейл.

Картинки были выполнены в расчете на планшет среднего размера - думал обойтись одним набором изображений с апскейлом/даунскейлом для всех разрешений. Пришлось сделать второй набор изображений меньшего размера и на небольшом разрешении использовать его.

Значит все-таки дело было в перерасходе памяти?

В общем, ситуация такова:

1. Объем растровых секвенций в виде спрайтшитов PNG - около 20Мб.

2. При запуске приложения в варианте нативного флеша (без использования Starling'а) объем под графику после распаковки секвенций в битмапдату где-то около 300Мб. Приложение визуально жутко тормозит, но не крашится. Из этого я сделал вывод, что проблема не в оперативной памяти при работе непосредственно AIR-приложения.

3. При запуске приложения в варианте на Starling'е объем данных, которые грузятся в видеопамять (судя по данным Scaut'а) 320 Мб. При загрузке в какой-то момент происходит краш. Однако, если уменьшить скейл текстур при загрузке в два раза, чтобы данные заняли в видеопамяти примерно в 4 раза меньше (80-90 Мб), то краш происходит все равно. Из этого я сделал вывод, что проблема не в том, что исчерпалась видеопамять. В обоих случаях, естественно, имел место даунскейл.

Если же уменьшить сами исходные изображения текстур в 2 раза (в 4 раза по объему данных) и грузить при правильном скейле (получается без изменений или апскейл), то загрузка происходит штатно. Из этого я сделал вывод, что вероятнее всего проблема в самом AssetManager'е при даунскейле изображений текстур в момент загрузки.

В принципе, можно конечно провести дополнительный эксперимент. Когда я делал вариант синхронной загрузки (в котором так же наблюдался краш), я грузил битмапы последовательно, но по сути в режиме того же даунскейла средствами AssetManager'а. Можно немного докрутить метод загрузки с тем, чтобы скейлить битпамдаты средствами нативного флеша до загрузки в видеопамять и грузить их средствами AssetManager'а без скейла или с апскейлом. Но тогда потребуется так же править и xml-файлы описания текстур и что там в итоге выйдет, не совсем понятно.

Вот, как-то так.


ЗЫ. На всякий случай уточню, что под скейлом при загрузке я имею в виду скейл, настраиваемый параметром scaleFactor при инициализации AssetManager'а.

300 метров — это уже очень много. Скажем, на iPhone 4 (это как бы нижний порог) краш будет уже при ~50-80 метрах.

Ок, значит для айфона будет упрощена визуализация.
Но пока айфон на повестке дня не стоит.