Нужна помощь с отображением мукивкипов

[WaldeMar1321]

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

Есть идеи?

Спасибо.

[ZackMercury]

Вы можете сделать скриншот мувика с помощью BitmapData.draw(...), затем в цикле ввести массив битмапов, каждому из которых присвоить экземпляр BitmapData, в который вы нарисовали кадр мувика, и в итоге иметь N битмап, ссылающихся на одну битмапдату.

[WaldeMar1321]

Спасибо, получилось. походу это придется поставить на ENTER_FRAME чтоб подобным образом перерисовывалось постоянно, если камеру двигать. Сомнительный вариант.

[ZackMercury]

Зачем перерисовывать? И о какой камере идёт речь, речь ведь шла о DisplayList?
BitmapData.draw(...), вероятно, замедлит работу вашей программы, чем обычный мувиклип, если использовать первый каждый кадр.

[caseyryan]

draw довольно быстрый метод

[WaldeMar1321]

Вот черновой пример кода:
var Blit:BitmapData = new BitmapData(floor.width, floor.height);
//..........
for (var Y:int = 0; Y < 480; Y += 50)
for (var X:int = 0; X < 640; X += 50)
{
var B:Bitmap = new Bitmap(Blit);
B.x = X;
B.y = Y
this.addChild(B);
}
Камеру я имел ввиду "условную". А вот про DisplayList мне интересно.

[ZackMercury]

draw довольно быстрый метод
Нет .

Добавлено через 4 минуты
for (var Y:int = 0; Y < 480; Y += 50)
for (var X:int = 0; X < 640; X += 50)
{
var B:Bitmap = new Bitmap(Blit);
B.x = X;
B.y = Y
this.addChild(B);
}
Вы хотите каждый кадр создавать кучу битмап? Зачем?
Объявите двумерный массив, и двигайте его элементы.

[WaldeMar1321]

этот кусок кода находится в классе экземпляр которого вызывается из Main. На сцену экземпляр этого класса добавляется уже после вышеупомянутого куска кода. Мне просто не хочется заводить лишний двухмерных массив чтоб отобразить простой пол. Я пытаюсь, взять маленькое 50х50 пикселей, или меньше изображение, и копировать его нужное количество раз на "экран". а потом уже вызвать stage.addChild() и пользоваться им как одним изображением. В случае выхода за границу экрана удалить не нужные removeChilAt линии и столбцы, и "дорисовать" нужные. в цикле, внутри вышеупомянутого класса. Но это не окончательное решение...

[caseyryan]

Нет .

А я тебе говорю, что да. Уже сто раз эта тема обсуждалась. Кучи тестов проводили. Если у тебя уже есть готовая битмапдата, то draw() очень шустро может в нее что-то врисовывать. Я в свое время делал систему видеонаблюдения на AIR, которая с нескольких камер потоки с помощью draw() рисовала в битмапки и определяла движение с помощью бленд модов. Это не тормозило даже на слабом компе.

[Bletraut]

этот кусок кода находится в классе экземпляр которого вызывается из Main. На сцену экземпляр этого класса добавляется уже после вышеупомянутого куска кода. Мне просто не хочется заводить лишний двухмерных массив чтоб отобразить простой пол. Я пытаюсь, взять маленькое 50х50 пикселей, или меньше изображение, и копировать его нужное количество раз на "экран". а потом уже вызвать stage.addChild() и пользоваться им как одним изображением. В случае выхода за границу экрана удалить не нужные removeChilAt линии и столбцы, и "дорисовать" нужные. в цикле, внутри вышеупомянутого класса. Но это не окончательное решение...

Если честно, то это извращение. Куча битмап не даст тебе прироста производительности. Лучше сделать так:
1) Рисуем мувик в битмап.
2) Создаем битмап с полом и рисуем туда методом copyPixel наш мувик из битмапки столько раз сколько нужно.
3) Когда выходим за границу экрана, то создаем новый bitmap, выравниваем его так чтобы казалось, что пол зациклен и присваиваем ему битмапдату нашего пола.

[Wolsh]

А что не так с Graphics#beginBitmapFill(), который автоматом делает тайлинг без всяких циклов?
например (http://flasher.ru/forum/showpost.php?p=1179299&postcount=6)

а потом уже вызвать stage.addChild()..да когда вы уже поймете, что ТАК делать НЕЛЬЗЯ..

[WaldeMar1321]

что именно нельзя, и почему? Это типа как "глобальные переменные это зло!" но никто толком не объяснит почему?

[Wolsh]

Потому что стейдж — это не ваше приложение.

[WaldeMar1321]

А в чем принципиальная разница? Работает ведь и так. Это вопрос этики, или эффективности? Если второе то хотелось бы по подробней.

[caseyryan]

Работает ведь и так. Это вопрос этики, или эффективности?
Эффективности и архитектуры. Если отовсюду использовать глобальный доступ, и у всего будут ссылки на всех и вся, то приложение превращается в такую задницу, в которой потом сам черт ногу сломит. Его будет невозможно не то что масштабировать, но и просто улучшать или исправлять баги. Будет сложно отыскать кто там реденок, а кто родитель, кто дядя, а кто тетя (образно говоря конечно). Постоянно будут появляться какие-то нелепые ошибки, типа попыток доступа к Null объектам, и будет совершенно непонятно откуда и каким образом они вылезают. Любое подобное приложение заходит в тупик в своем развитии. Но к пониманию как делать правильно нужно еще прийти. Все через это проходят, и у меня в свое время было много таких приложений, и я тоже задавался вопросом почему это нельзя делать везде глобальный доступ или передавать везде ссылки на Main класс, к примеру. И вот потом, когда все эти приложения заканчивались полным коллапсом, я начинал подробнее изучать то, как нужно делать правильно. Неспроста же появились все эти многочисленные шаблоны проектирования. Люди пытались выработать путь, которые будет наиболее правильным в том или ином случае. И наиболее удачные попытки превратились в такие "общепринятые" шаблоны.