Подход к отображению изображений/мувиков

[Ioangum]

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

[Akopalipsis]

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

Добавлено через 39 секунд
Четыре мувика - тяжелее одного.

[alatar]

Akopalipsis, вам осталость развить мысль дальше и прояснить насколько "тяжелее" и когда "тяжелее".

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

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

...разделив мешок на четыре части, Вы увеличите вес, в четыре раза.

Ага, прочитал по диагонали. Ну, бред же.

Добавлено через 6 минут
Ioangum, по описанию больше похоже на то, что проще разделить (как и в большинстве случаев, если речь не идет о последовательных кадрах анимации).

[Akopalipsis]

Ага, прочитал по диагонали. Ну, бред же.

Почему?

new MovieClip()+new MovieClip()+new MovieClip()+new MovieClip()===new MovieClip() ?

То что я не развил мысль, это только по тому, что дальше я только на словах знаю.
И только по этому, оставил это для Вас, так как Вы возможно посоветуете отказаться от MovieClip в пользу BitmapData.
И я про вес не в прямом смысле сказал, что КБ вырастут, а в том смысле, что создаваться будет дольше.
И сказал это не по тому что четыре или один мувик, а по тому, что в будущем может пригодится.

Добавлено через 11 минут
И ещё добавлю, что на первых порах изучения, когда только немного понял ОПП, то стремился к тому, чтобы все разбить на как можно больше частей. Но это же не так, вот я по этому и обьяснил, как бывает в жизни, что разделить - это легче и как тут - разделить, значит, создать в несколько раз больше.
А вот вчера сделал набросок своего класса scale, который координаты смещает и решил посмотреть, как сделано в самой быстрой анимации. Так вот там автор, просто создает новый спрайт и кладёт в него обьект.

[alatar]

И я про вес не в прямом смысле сказал, что КБ вырастут, а в том смысле, что создаваться будет дольше.

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

Не могли бы вы прояснить вашу терминологию слов "больше", "тяжелее", "легче" и "вес" (хотя его значение вы уже прояснили). И что может пригодиться в будущем.

А вот вчера сделал набросок своего класса scale, который координаты смещает...

>_< А класс с таким названием должен смещать?

[Wolsh]

А класс с таким названием должен смещать?

)) Я подозреваю, что речь о скейле "из центра", как и популярная тема про вращение вокруг центра))

[Akopalipsis]

И почему вы решили, что они будут создаваться все одновременно и откуда вывод

я всегда предполагаю худшее.

и откуда вывод, что четыре будут обязательно создаваться дольше одного?

я когда скорость выполнения меряю при помощи getTimera, то заметил, что чем больше обьектов создаёшь,
тем дольше уходит время я ошибаюсь?

>_< А класс с таким названием должен смещать?

Вот я думаю, что да... Вообще я тут немного расскажу, как я вижу "это" и был бы рад, если бы на вопрос,
ответили не вопросом.
Класс унаследован от Object, если нужно что то увеличить, то создается его экземпляр, в который помещается скалируемый обьект. Там я рассчитываю и скорость и конечный размер и смещение координат. И этот класс я добавляю в класс с EF. А как Вы делаете?

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

) Я подозреваю, что речь о скейле "из центра", как и популярная тема про вращение вокруг центра))

А что не так в такой постановке? я просто не знаю про вращение во круг центра и не могу догадаться, что не так.

[Wolsh]

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

я просто не знаю про вращение во█круг центра

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

[Akopalipsis]

Уж если класс, то с большой, и если смысл его существования делать что-то из центра,

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

То есть Вы не догадываетесь, что все объекты по-умолчанию вращаются вокруг точки регистрации,

Для меня шоком было, что круг рисуется относительно 0:0.

Почему не из любой назначенной точки?

Спасибо! Не думал об этом, сейчас буду переделывать

[Wolsh]

Вот кстати о вращении, может что-то лучше придумаете