PDA

View Full Version : What happened to duplicateMovieClip()


csdstudio
08-02-2006, 09:27 PM
So now that duplicateMovieClip is gone, how can we duplicate a Sprite? It would seem that this great feature is gone with the wind. :rolleyes:

senocular
08-02-2006, 09:37 PM
Basically, you just create a new instance of the sprite using its class (whether it be Sprite or a subclass) and copy over transformation information (just assign transform property to the transform of the original object). That pretty much gives you a direct duplication outside of code placed on the object in the IDE (which was retained in AS1/AS2 but no longer applies to AS3) and dynamic drawings. Dynamic drawings is a little more tricky since that would have to be done over from scratch, but thats about the only thing that has changed (not counting the transform reassignment, but thats minimal)

csdstudio
08-03-2006, 04:13 AM
Basically, you just create a new instance of the sprite using its class (whether it be Sprite or a subclass) and copy over transformation information (just assign transform property to the transform of the original object). That pretty much gives you a direct duplication outside of code placed on the object in the IDE (which was retained in AS1/AS2 but no longer applies to AS3) and dynamic drawings. Dynamic drawings is a little more tricky since that would have to be done over from scratch, but thats about the only thing that has changed (not counting the transform reassignment, but thats minimal)

That could work great, but only if the Sprite belongs to a class and not just a MovieClip created in the IDE. What are dynamic drawings?

senocular
08-03-2006, 02:17 PM
MovieClips in the IDE have their own classes as well

By dynamic drawings I mean anything done to an object's graphics property, such as beginFill, lineTo, curveTo, etc.

csdstudio
08-04-2006, 11:25 PM
MovieClips in the IDE have their own classes as well

By dynamic drawings I mean anything done to an object's graphics property, such as beginFill, lineTo, curveTo, etc.

Gotcha, that's where the duplicate movieclip method will be missed. :D

senocular
08-04-2006, 11:46 PM
Gotcha, that's where the duplicate movieclip method will be missed. :D

Sadly I don't think there's a way to easily carry that over from one movie clip to the next :o

Tink
08-05-2006, 03:41 PM
Not sure if you'll find it useful, but i put this little thiing together http://www.tink.ws/blog/as-30-cloningconcatenating-graphics/#more-175.

astgtciv
08-05-2006, 04:07 PM
Wow, Tink! Nice! How elaborate...
For invokeStep, couldn't you just do


private function invokeStep( step:Object ):void {
var vo:CloneableGraphicsVO = CloneableGraphicsVO( step );
var method:Function = _graphics[ vo.method ];
method.apply(_graphics, vo.arguements);
}

senocular
08-05-2006, 04:29 PM
I've gone through this process before, and though that kind of solution works for some cases, the problem is the clonablegraphics class lacks the typing that allows it to be used in place of graphics instances in situations where graphics instances are expected. So, for instance, if there is some drawStar(graphics:Graphics):void method out there, clonable graphics fails. Similarly it wont work on operations which may accept a sprite but then use it's graphics property.

It would have been nice if there was an interface that could be used for graphics objects (especially since there is no base class that relates to graphics usage - not all display objects have graphics but a few of its subclasses do), but that does not seem to be available despite there being one for IBitmapDrawable.

Additionally, these problems prevent the graphics property from being overridden in sprites/shapes should you decide to go that route, essentially that falling apart, again, because of typing.

So this approach is great in controlled environments, but really isn't robust enough to work in all cases - just something to be aware of I guess.

astgtciv
08-05-2006, 07:29 PM
Could a sprite-cloning technique along the lines of taking a snapshot of the state of the graphics object with BitmapData, and then drawing on top of that work (and then overriding clear() to destroy the bitmapaData)? Hmm... the graphics object is the furthest in the depth stack, though, so we'd have trouble inserting something under it. Plus, a bitmapData snapshot image is not the same as the original vector graphics of the graphics object, which will probably become noticeable when the object is scaled... (I guess that was the message in "Sprite: Image Is Nothing" :D)

Tink
08-06-2006, 11:04 AM
Wow, Tink! Nice! How elaborate...
For invokeStep, couldn't you just dooh yeag the Function.apply() method is a lot more swanky, ive update my post.

So, for instance, if there is some drawStar(graphics:Graphics):void method out there, clonable graphics fails.Yeah unfortunately ya can't extend Graphics as its final.Similarly it wont work on operations which may accept a sprite but then use it's graphics property.
Unfortunately yes.So this approach is great in controlled environments, but really isn't robust enough to work in all cases - just something to be aware of I guess.Yes i would presume anyone using the class would be aware of it and its limitations.

senocular
08-06-2006, 04:10 PM
bitmapData copies would be an option for some cases, but like with any approach here, there are limitations. bitmapdata copies, for instance, are raster and would not retain the scaling abilities of the original vector drawing. Also in maling a bitmap copy, you would need a slot in the display list to contain your bitmap (as opposed to using the graphics layer which resides below all objects in the display list).