I’d like to share here the origins of the header image of this weblog, and give others a chance to play with a small toy I have enjoyed both making and interacting with. The application was created in the waning days of September 2009, in the midst of a difficult project at work, and has lain untouched since due to parental neglect. I share it here in the hope that another may take its ideas further, or instead inspire me to go further with them. You may view that application here: http://modern-carpentry.com/workshop/spiderweb
Origins
The origins of the spiderweb program above begin with the fundamentals of display-list programming in Actionscript 3 [1]. Put simply, Actionscript 3 gives the programmer the ability to add display objects ( whether they are MovieClips, Sprites, Shapes, Bitmaps, or anything else ) as children of other display objects. With this parent->child kind of relationship, a child inherits all transformations applied to a parent object, so that by rotating, scaling, or applying any kind of transformation to a parent, each of its children inherit that transformation, and children of any child also inherit that transformation, and any children of that child inherit, etc, etc. Though this idea is not new, and indeed has been a central part of Actionscript programming for 10 years now, it was made much more sensible and easy to work with in Actionscript 3.
New Methods
I did not set out to create a Dual Parented Child. Instead, it was nearing Halloween and I wanted to have some spiderweb program for the holiday. As I thought about the best way to do this, it became clear to me that something like this might be needed to enable the interactivity that I desired. I must mention that I looked around quite a bit for more information on doing something like this, and couldn’t find much regarding Actionscript or other languages. Please let me know of any resources that may help me in this task.
The central idea of this application is that it struck me quite odd, in the terms of parent->child display list programming, that a child would only have one parent. It seems that native Actionscript display objects are the children of widowers or divorcees, or something. So in my efforts to create the spiderweb application, I created something I called the DualParentedSprite. This object extends the native Sprite object, and adds one important modification– a child can have more than one parent. Mom and Dad! DualParentedSprite acts very similar to the native Sprite, except that it inherits the transformations of both of its parents, and then calculates the middle value between the two and exhibits that character. In this way the DualParentedSprite is a much more human programmatic object than a traditional Actionscript 3 display object, in that it has two parents rather than one, just as all humans do. That being so, I would argue that an object such as the DualParentedSprite can be used to exhibit complex behavior without too much engineering.
In this simulation, there are 3 generations. The first generation ( the black circles around the edges that you can click and drag ) only have one parent– the stage. The second generation connects two sprites from the first generation, and then the third generation connects two sprites from the second generation. Any changes in position made to the first generation propagate down through the generations, as each child updates according to its parent, and further each parent updates any children.
Going Forward
This recursive dual parenting gets rather complex to my mind after a bit, and even now looking at code from 4 months ago I’m not sure how I got it all ( kind of ) working. There is a bug or two, which is evidenced by the odd horizontal gap you see when you initially view the program, and I definitely want to fix that. But that is the problem of the spiderweb program, and not the DualParentedSprite.
I’ve also tried animating this on a frame-by-frame basis ( in order to add a more fluid mouse interaction, or some noise ), and, due to the amount of recursive graphics operations being performed each frame, performance slows for this. With a small amount of time I think this problem could be solved using bitmap blitting [2].
Other improvements to be made would involve a more robust writing of DualParentedSprite. Currently, each child only inherits the x and y positions of its parents. With some work, the class could be made so that each child also inherits an average of its parents’ rotation, alpha, transform matrix, etc, etc. A further improvement would give the ability of a child to have more than 2 parents– say 3 or 4 or 8 or 16. But that would get crazy.
Further, at some point I would like to investigate whether there is any functionality similar to the Actionscript 3 display list in Processing.js or other Javascript graphical programming libraries, and, if not, begin to implement one for Javascript. If I ever were to undertake such a project, I would also like include dual parenting behavior. If you’d like to view the source of the application or contribute any ideas, please look here [3] [4] or share a comment below. Otherwise, enjoy this short video of me playing with teh spiderweb.
on flickr...
Dual Parented Child
I’d like to share here the origins of the header image of this weblog, and give others a chance to play with a small toy I have enjoyed both making and interacting with. The application was created in the waning days of September 2009, in the midst of a difficult project at work, and has lain untouched since due to parental neglect. I share it here in the hope that another may take its ideas further, or instead inspire me to go further with them. You may view that application here: http://modern-carpentry.com/workshop/spiderweb
Origins
The origins of the spiderweb program above begin with the fundamentals of display-list programming in Actionscript 3 [1]. Put simply, Actionscript 3 gives the programmer the ability to add display objects ( whether they are MovieClips, Sprites, Shapes, Bitmaps, or anything else ) as children of other display objects. With this parent->child kind of relationship, a child inherits all transformations applied to a parent object, so that by rotating, scaling, or applying any kind of transformation to a parent, each of its children inherit that transformation, and children of any child also inherit that transformation, and any children of that child inherit, etc, etc. Though this idea is not new, and indeed has been a central part of Actionscript programming for 10 years now, it was made much more sensible and easy to work with in Actionscript 3.
New Methods
I did not set out to create a Dual Parented Child. Instead, it was nearing Halloween and I wanted to have some spiderweb program for the holiday. As I thought about the best way to do this, it became clear to me that something like this might be needed to enable the interactivity that I desired. I must mention that I looked around quite a bit for more information on doing something like this, and couldn’t find much regarding Actionscript or other languages. Please let me know of any resources that may help me in this task.
The central idea of this application is that it struck me quite odd, in the terms of parent->child display list programming, that a child would only have one parent. It seems that native Actionscript display objects are the children of widowers or divorcees, or something. So in my efforts to create the spiderweb application, I created something I called the DualParentedSprite. This object extends the native Sprite object, and adds one important modification– a child can have more than one parent. Mom and Dad! DualParentedSprite acts very similar to the native Sprite, except that it inherits the transformations of both of its parents, and then calculates the middle value between the two and exhibits that character. In this way the DualParentedSprite is a much more human programmatic object than a traditional Actionscript 3 display object, in that it has two parents rather than one, just as all humans do. That being so, I would argue that an object such as the DualParentedSprite can be used to exhibit complex behavior without too much engineering.
In this simulation, there are 3 generations. The first generation ( the black circles around the edges that you can click and drag ) only have one parent– the stage. The second generation connects two sprites from the first generation, and then the third generation connects two sprites from the second generation. Any changes in position made to the first generation propagate down through the generations, as each child updates according to its parent, and further each parent updates any children.
Going Forward
This recursive dual parenting gets rather complex to my mind after a bit, and even now looking at code from 4 months ago I’m not sure how I got it all ( kind of ) working. There is a bug or two, which is evidenced by the odd horizontal gap you see when you initially view the program, and I definitely want to fix that. But that is the problem of the spiderweb program, and not the DualParentedSprite.
I’ve also tried animating this on a frame-by-frame basis ( in order to add a more fluid mouse interaction, or some noise ), and, due to the amount of recursive graphics operations being performed each frame, performance slows for this. With a small amount of time I think this problem could be solved using bitmap blitting [2].
Other improvements to be made would involve a more robust writing of DualParentedSprite. Currently, each child only inherits the x and y positions of its parents. With some work, the class could be made so that each child also inherits an average of its parents’ rotation, alpha, transform matrix, etc, etc. A further improvement would give the ability of a child to have more than 2 parents– say 3 or 4 or 8 or 16. But that would get crazy.
Further, at some point I would like to investigate whether there is any functionality similar to the Actionscript 3 display list in Processing.js or other Javascript graphical programming libraries, and, if not, begin to implement one for Javascript. If I ever were to undertake such a project, I would also like include dual parenting behavior. If you’d like to view the source of the application or contribute any ideas, please look here [3] [4] or share a comment below. Otherwise, enjoy this short video of me playing with teh spiderweb.
dual parent sprite and conversation from thomas saunders on Vimeo.
Reference
1. Display List Programming
2. Bitmap Blitting
3. SpiderWeb.as
4. DualParentSprite.as