[Starling] Рациональность использования Starting

[Akopalipsis]

Пробовал искать ответ о ситуациях в которых нет смысла использовать данный фраймворк, но чем больше искал, тем больше меня ответы запутывали. Раньше я думал что Starting исключительно для создания игр и задумываться о нём мне пока рановато. Но однажды я чисто случайно наткнулся на статью, где автор говорил о повсеместном использовании Starting. То есть не только в играх, а вообще везде где есть - эффекты и графика. Вот мне и хочется узнать у тех кто с ним на ты, так ли это?
Действительно ли его можно или даже нужно использовать во всех проектах?

[caseyryan]

Совсем не обязательно. В играх на нем будет шустрее работать, так как процессор освободится от просчета графики, а в приложениях, где графика не самую большую роль играет, особого смысла нет. Разве что на мобилах, где производительность очень критична.

[Akopalipsis]

caseyryan Спасибо! Вот и Ваши я слова интерпретировал как - желательно использовать. Спасибо, буду учить.

[KumoKairo]

Чисто игровых средств в Starling нет вообще - это просто вспомогательная библиотека для использвания стандартного (привычного) флеш API, когда на самом деле работаешь со Stage3D и аппаратным ускорением.

Создавался этот фреймворк именно для реализации любого рода приложений на мобильных устройствах. Плюс ко всему там очень много вкусных плюшек вроде встроенного твинера (с возможностью использования пула твинов), встроенный менеджер ассетов для автоматического управления памятью, выделяемой под визуальные и звуковые ресурсы.
Но что самое главное -комьюнити здорово развивается, буквально через неделю-две Дэниел обещал новую версию выпустить (уже 1.4)

[Tails]

Твины не самое главное, главное - это МОЩЬ! нереальная производительность графики, 60 fps на фул скрине и не хилые спец эффекты при этом. Не зря же оно - gpu.

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

При использований нативного stage3D, сложность возрастает не хило так. Старлинг обёртка - самое оно. Хотя конечно, знание stage 3D всё-равно потребуется, если захотите изобразить чего посерьёзнее простых прозрачных текстур да и вообще понимать, что "там" происходит.

[Akopalipsis]

Спасибо всем! Жду не дождусь когда смогу приступить к изучению!)

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

[KumoKairo]

http://feathersui.com/

[Котяра]

Огромадный список всего на свете с описаниями и разделениями на категории.
http://www.as3gamegears.com/

[Akopalipsis]

Котяра Спасибо! я там посмотрел раздел - частицы и мне сразу вспомнилось... Какая самая лучшая библиотека для частиц? Видел на ютубе просто сногсшибательные эффекты.. знать бы чем они сделаны. Сейчас найду покажу.

Добавлено через 2 минуты
http://www.youtube.com/watch?v=ndO4yJ24HzU просто как AE

[C4Grey]

При использовании Starling в не-игровых приложениях нужно учитывать, что иерархия контейнера отрисовки в играх и приложениях, может сильно отличаться по количеству уровней вложенности. В играх объединять ресурсы в батчи, писать свои схемы отрисовки, жонглировать данными, перегоняя их с оперативной в видеопамять(когда же в Stage3D добавят возможность использовать PBO...) - это нормальный рабочий процесс, чем больше разгрузим GPU, тем лучше. Разработка приложения ориентирована на бизнес-логику, под которую реализуются адаптивные интерфейсы, которые часто должны учитывать экзотические параметры экранов, изменение размеров и способа отображения в зависимости от локализации, и прочее. Если реализовать это как привыкли в программном режиме отрисовки - множеством вложенных контейнеров, в глубинах которых находятся TextField-ы, то очень скоро столкнемся с критическим падением уровня FPS, вызванным частыми переключениями состояний отрисовки(смена текстуры). Это применимо и для растровых шрифтов -запихнуть все глифы для всех локализаций и размеров в одну текстуру со шкурками - очень проблематично, а использование даже одной дополнительной текстуры даст нам прибавление DC на каждый уровень вложенности контейнеров, например: панель, у которой есть Label, в которую добавлены кнопка, внутри которой тоже есть Label даст нам 3 или 4 DC, если шрифт будет реализован отдельной текстурой. Для другого режима отрисовки текста(когда TextField Flash-а рисуем в битмапу и загружеам в текстуру) характерны те же проблемы + он еще и порядочно отжирает видеопамять, особенно при больших размерах символов.
Я сейчас работаю над приложеним на Feathers, там есть ScrollContainer, в него загружаются картинки предварительного просмотра. Каждый элемент в контейнере это: Quad для фона, Image для картинки, еще один Quad для фона небольшой надписи поверх картинки. Все вместе дает нам 4 DC. Элементов на экране может быть 15-20. Само-собой, во время скролла это все порядочно подергивается на слабых мобильных. Приходится использовать собственный пайплайн для отрисовки как бы по слоям - сначала рисуем фон, потом картинки, потом текст с фоном. Текст тоже с хаком - используется упрощенный вариант Distance Field Font.
Но проблема даже не в этом Разумной альтернативы с исользованием "родной" отрисовки, ориентированной под мобильные платформы просто нету - разве что брать чистый Flex и самому писать компоненты, оптимизированные для тач-ввода, обработку жестов, и т.п.