Вопрос по добавлению в список отображения

[Appleman]

Сообщение от Wolsh

а при загрузке в рантайме — не будет простыни и переменных?

Так, вот тут чувствую себя полным идиотом. Уже и коллега undefined писал про рантайм, и ты теперь. Что это за зверь такой и как его использовать на практике? В инете кроме общего определения, что, мол, среда выполнения, ничего по существу не нашёл.

Многие по возможности собирают много маленьких в одну большую — спрайтшит или атлас — и в рантайме "нарезают" ее на маленькие. Это особенно удобно, когда картинки являются кадрами какой-то секвенции или например иконками графического интерфейса; удобно, когда не нужен КЛАСС для каждой картинки, и даже отдельная переменная — когда можно хранить их в массиве.

Есть ссылки на описание/уроки/примеры? Вообще не соображаю, о чём речь, пардон.

[undefined]

Runtime в переводе - время выполнения(промежуток времени м-у запуском программы и ее завершением).
Также есть понятие compile time(промежуток времени м-у началом и завершением компиляции)
Также runtime иногда называют среду исполнения где исполняется тот или иной код например Java Runtime Environment(JRE)

[Appleman]

undefined, спасибо за разъяснения, вернул меня в контекст . То есть wolsh хотел сказать, что в какой момент не подгружай графические файлы, один хрен будет ад и Пакистан из-за их большого количества, которым нужно как-то управлять. Что ж, не поспоришь...

А есть какая-нибудь инфо по этим самым спрайтшитам и вообще по управлению загружаемой графикой в проекте?

[Wolsh]

Шит в смысле "таблица", "сетка". Допустим у тебя 12 иконок для какого-то тулбара, все одного размера 24х24 пикселя.
Собираешь их на одной картинке вплотную друг к другу, допустим 4 иконки в ряду, 3 ряда. Шит.
Теперь тебе не надо 12 раз писать [Embed] и создавать 12 классов, эмбедишь только эту картинку.
В рантайме создаешь ее экземпляр и получаешь ссылку на битмапдату. В цикле как по двумерному массиву "нарезаешь" ее обратно на 12 картинок, каждую битмапдату 24х24 сохраняешь в массив. И когда надо отобразить, создаешь Битмап и передаешь ему нужную битмапдату из массива.
Пока не почитаешь и не попрограммируешь битмапы/битмапдаты, для тебя эти объяснения останутся темным лесом. Надо просто знать, что эти классы из себя представляют и что умеют. Если коротко, Bitmap — экранный объект, умеющий показывать битмапдату. BitmapData содержит информацию о пикселях, по сути это двумерный массив чисел (цветов пикселей) с кучей всяких методов для работы с ними. Несколько Битмапов могут одновременно показывать одну и ту же битмапдату, что позволяет оптимально использовать память — ведь большая картинка это миллионы пикселей, так что битмапдата занимает прилично памяти. Одним из методов БитмапДаты является copyPixels(), который позволяет скопировать из одной битмапдаты в другую любой участок, прямоугольник заданных размеров и координат. Так что в цикле, смещая координаты этого прямоугольника по всей площади спрайтшита на 24 пикселя, мы можем снять все 12 иконок в отдельные новые битмапдаты 24х24, сложить их в массив и пользовать на своё усмотрение.

Добавлено через 11 минут
Когда говорят "атлас", подразумевают более сложную ситуацию, когда у картинок разные размеры и они разбросаны нерегулярно по большой картинке. Тогда нужна "карта" с координатами, то есть просто список, что такая-то картинка таких-то размеров находится в таких-то координатах (описание например в XML), и соответственно в рантайме их "снимаешь" не автоматически в цикле, а по данным из этого атласа.

Добавлено через 15 минут
Самый наверное классический пример спрайтшита — набор игральных карт для какого-нибудь покера.
Представь что пришлось бы каждую карту отдельно эмбедить и создавать под нее класс. 60 картинок.
А так их можно заэмбедить/загрузить одним изображением и нарезать на отдельные карты в рантайме.

[Appleman]

Камрады, я возвращаюсь к кнопочкам и картинкам. Ещё почитал всякого на эту тему...

Скажите, пожалуйста, существует ли какой-либо общепринятый стандарт хранения bitmap-файлов проекта? Где обычно размещается подобный каталог и есть ли какое-то общеупотребимое имя на него?

И второй вопрос. Я правильно понимаю, что для всех bitmap-файлов, используемых в проекте, желательно создать отдельный класс, который их будет эмбедить (слово-то какое!) и отдавать в другие классы по запросу? Или эмбедить прямо в классы, непосредственно использующие данные файлы, например, в классе кнопки подгружаем файлы и "плашками" для кнопки и т.п. Не будет ли в последнем случае многократного использования памяти на одно и то же?

[Godwarlock]

И второй вопрос

Appleman Для таких вещей можно написать ассет менеджер или использовать готовый. Это объект, который содержит в себе весь графический(и не только) контент, по получению контента, используется get функция, например getImage(name:String):Bitmap или getXml(name:String):XML и т.д. Нет смысла эмбедить все по разным классам, достаточно одного.

[Appleman]

Сообщение от Godwarlock

Appleman Для таких вещей можно написать ассет менеджер или использовать готовый. Это объект, который содержит в себе весь графический(и не только) контент, по получению контента, используется get функция, например getImage(name:String):Bitmap или getXml(name:String):XML и т.д. Нет смысла эмбедить все по разным классам, достаточно одного.

Спасибо, понятно. У меня уже есть файл-менеджер для чтения XML. Но он в рантайме читает. Я думал, битмапки на этапе компиляции должны загружаться. А есть примеры ассет-менеджера на посмотреть?

И ещё пачка практических нубских вопросов. Пишу класс для кнопочки меню (по уроку, но не бездумно копируя, а сразу модифицируя под свои задачи). Имеем там:

		private var _defaultState:Sprite = new Sprite; 	// Состояние по умолчанию
		private var _overState:Sprite = new Sprite; 	// при наведении мыши
		private var _downState:Sprite = new Sprite;	// при нажатии кнопки мыши
		private var _inactiveState:Sprite = new Sprite;	// если кнопка неактивна
 
		private var _currentState:Sprite; 	// Текущее состояние
		private var _container:Sprite;		// Контейнер для состояний

Первое, что я не понимаю из этого урока, это наличие переменной _container. Зачем иметь в классе

this.addChild(_container);

чтобы потом писать

_container.addChild(_defaultState);

Почему нельзя все состояния сразу помещать в this, зачем ещё один контейнер нужен?

Второе. По уроку там кнопочки - это битмапки, причём сложной формы. Поэтому дополнительно создана переменная sensor:Sprite, которая накладывается сверху и определяет область чувствительности к наведению и кликам. На неё же вешаются все слушатели событий от мыши. Я решил, что поскольку у меня кнопки - это пока обычные прямоугольники, рисуемые с помощью drawRect, то на фига мне этот сенсор сдался, и не стал его добавлять. Теперь сижу и мучаюсь, куда слушатели вешать. То ли на _currentState, то ли на _container, то ли на this - и ведь все варианты, зараза, работают Проясните, плиз!

Третье. Если кнопка должна уметь быть неактивной, что в этом случае будет правильнее: запрограммировать в том же классе вариант (как это сделано сейчас), унаследоваться или сделать вообще новый класс? В каждом из вариантов что-то смущает. Если всё в одном классе писать, то непонятно, что делать со слушателями событий, т.к. неактивная кнопка, например, не будет менять свой внешний вид при наведении мыши, что ломает единую логику класса. Тогда можно было бы унаследоваться и переопределить методы. Но тогда кто-то должен "знать", экземпляр какого из классов кнопки создавать: обычный или неактивный. Не понимаю, куда запихивать эту логику.

[Wolsh]

1. Есть миллион способов устроить кнопку. В данном случае создатели попытались сотворить нечто универсальное — флаг им в руки, иногда это интересно, хотя в большинстве случаев бессмысленно: универсальность всегда воюет с оптимальностью.
Для чего нужен контейнер? Ну, разные цели могут быть. Например, для анимаций, таких как дрожание/вибрация, раскачивание (может и с изменением размера), просто смещение (например, на пару пикселей по вертикали, имитирующее вдавливание кнопки при нажатии), да просто изменение размера при наведении, мало ли какие фантазии навалят. Удобно, чтобы эти анимации совершались именно с контейнером, а не с конкретным стейтом потому, что тогда замена стейта не вызовет резкое прекращение анимации, анимация продолжится с новым стейтом и это будет выглядеть более натурально. Также удобнее применять фильтры к контейнеру а не к стейтам (тень, свечение и тп). Ну и, наконец, куда-то же еще надо пихнуть лейбл (текст кнопки), и хотелось бы чтобы он тоже раскачивался и прыгал вместе со всеми во время анимаций)
2. Если нет контейнера, то this. На каррент нельзя, потому что это переменная-ссылка, и ее значение будет меняться, так что слушатели будут повешены на какой-то стейт, а на другие нет, и при смене стейта кнопка оглохнет.
3. Никто никакую логику не ломает. Кнопка должна уметь быть неактивной (это кстати не всегда означает "мертвой" — например в винде в выпадающих менюшках неактивные кнопки показывают таки рамочку при наведении — чтобы было визуально приятней водить курсором по списку пунктов) и показывать неактивный стейт (обычно неконтрастный серый). Это вполне себе входит в логику (умения) кнопки.

[Appleman]

Сообщение от Wolsh

Для чего нужен контейнер? Ну и, наконец, куда-то же еще надо пихнуть лейбл

Точняк, спасибо. Попробовал менять значения альфы при наведении, если нет контейнера, то текст на кнопке тоже "бледнеет", что не есть гуд. С контейнером такой фигни по понятным причинам не происходит. Вернул.

3. Никто никакую логику не ломает. Кнопка должна уметь быть неактивной (это кстати не всегда означает "мертвой" — например в винде в выпадающих менюшках неактивные кнопки показывают таки рамочку при наведении — чтобы было визуально приятней водить курсором по списку пунктов) и показывать неактивный стейт (обычно неконтрастный серый). Это вполне себе входит в логику (умения) кнопки.

Тогда не ломать, а усложнять придётся. Я так понимаю, в зависимости от значения переменной, определяющей активность кнопки, нужно будет добавлять различное поведение всем методам event-handler'ам. Верно?

[Wolsh]

Ну.. да) Если ты хочешь, чтобы она как-то "себя вела" в неактивном состоянии, то придется это описывать, как иначе то.. Тогда и стейты надо вводить "неактивный овер", "неактивный даун", "неактивный дефолт".. Но это ж совсем не обязательно.. Это имеет смысл для кнопок-итемов выпадающего списка, да и то по чисто эстетическим соображениям. А так — просто засовываешь неактивный стейт в контейнер, делаешь контейнеру .маусЧилдрен и .маусЕнаблед = false и хорош, режим дизаблед готов, можно даже не отписываться.

Добавлено через 8 минут

если нет контейнера, то текст на кнопке тоже "бледнеет", что не есть гуд.

я тебе больше скажу — все стейты сделаны спрайтами для того, чтобы пихать в них лейблы. Так то можно было бы прямо битмапы состояний совать в контейнер, нет смысла каждый упаковывать в спрайт. Но нет, иногда хочется на разных стейтах иметь по-разному оформленную надпись, а то и разный текст (особенно если это toggle button — кнопка с фиксацией "вкл / выкл", как у чек-бокса).