I'm a new flash developer. I have read here http://www.flashandmath.com/intermediate/children/stage.html that I should avoid adding children to the stage itself and only add them to my MainTimeLine derived main document class (which is itself a child of stage). However, the author does not give explanation/justification for this approach.
I am developing a project where I am considering adding UI popup windows to the stage directly rather than including them in my MainTimeline (it makes it easier to keep them above everything else and also makes it easier for me to know what I need to persist and what I don't when saving).
What are the downsides of this? Is it a "bad practice" in Flash? Why?
For quick demos and presentations I often use the Flash IDE's timeline to manage my depths. I create empty movieClips and put them on the different layers. For example, my top layer would be my Popup Layer, under that would be my Main Content Layer, under that would be my Background Layer. My main document class manages the adding and removing of popups, content and background instances.
I believe it is bad practice to add children directly to the Stage. Here is a decent thread explaining some differences between MainTimeLine vs stage.
Related
Novice programmer here.
I'm currently coding a simple game with the title screen and the main game loop in separate "keyframes" (this is in CS6). Once I transition from the title screen to the game keyframe I'm concerned that the buttons/movieclips/variables are going to stick around and waste memory + clutter the screen.
If I have the variables/functions set to "private" will that help the garbage collector take care of them? How should I go about "clearing the screen" and making sure I'm not being wasteful/leaking memory?
None of the tutorials or books I've been reading to learn AS3 have really covered this topic, if there are any good guides or obvious tips I've missed as far as memory management best practice goes in AS3 I'm interested in seeing them. The only thing I've learned so far is that I should manually set all my event listeners to weak reference.
Bonus question: I'm using a full-screen bitmap and blitting things onto it for my display. If I am blitting dozens of objects onto the screen per frame I don't need to worry about the blitted "sprites" that are being "covered up," do I? I'm hoping that the bitmap is one pixel thick and not just stacking things on top of each other.
Firstly, the only way you will have total control over your resources is if you leave the timeline for what it was intended for, creating and exporting assets in to swc or swf format, which you can embed the former and either embed or load the latter.
What you should be doing is learning how to develop in an Object Oriented manner, starting with a Document class (as you're using CS6) and then building your game using a series of classes which have defined tasks. Using classes promotes re-usability throughout your game. Depending on the complexity, I would consider a framework like PureMVC or Robot legs.
Garbage collection in flash is mark and sweep, which means you have to de-reference all your objects, which usually starts with removing associated listeners, timers and any further references to them, eg. clearing from arrays or objects hashes. Finally you would set the object in question to null which makes it 'elligible' for garbage collection but does not actually guarantee it. Flash will come and clean up as it sees fit.
Personally if you could get hold of Flash Builder, this has a fantastic memory management profiling tool, when you are developing using OOP mentioned above, you can use this tool to see all the instances that exist in your game. Now the good part here is you can do a memory snapshots in time, and compare them to see which objects linger around and are causing memory leaks. There is a garbage collection button which you should invoke between capturing snapshots, this is only available as you are developing, though using Adobe AIR you can force gc calls manually.
Regarding your bonus question, im not sure how you are doing this blitting, if you are adding objects to the stage this is increasing memory, you cannot avoid this. What you describe as 1px thick is what flash renders, you can see what is being redrawn by right clicking on the stage and selecting the redraw regions option, to see a red box showing what flash has to redraw, it will only redraw what it needs to, this is useful to check if your frame rate suffers.
So to summarize:
Consider using Flash CS6 for creating assets.
Learn about Object Oriented programming in Actionscript 3.
Consider developing in Flash Builder (or free Flash Develop).
OOP will help with organisation and de-referencing objects for garbage collection.
I hope this helps and good luck with your game.
I am trying to create an animation for lemon juice and baking soda experiment, and I was wondering how can I create a foaming effect such as the one shown in this image:
The idea I have in mind is to simply draw a foam in photoshop and then use motion tween to change the size. I was hoping I could find a better solution to this.
I have something somewhat similar that you can probably use as a springboard for doing your own thing.
http://www.shaunhusain.com/SteamEffect/
http://www.shaunhusain.com/SteamEffect/srcview/index.html
Currently I'm just drawing some circles with this and then setting a blur on them (not very efficient I know but it served the purposed as I didn't need it to create a bajillion particles to still be effective as "steam" which was the intended goal). You could swap out the shapes/filter I'm using for your own drawing and use the same basic structure.
EDIT
Perhaps this requires at least a little explanation:
Basically you'd want to look at the two files SteamCanvas.mxml and BitOfSteam.as. To be honest I have no idea why I decided to write SteamCanvas as an mxml file. I chose to use Canvas as the base class so I could just wrap it around any other component as a container and be able to detect mouse clicks anywhere within a region. If this is being used in a pure Flash environment, that is one not using the Flex libraries (or mxmlc compiler) it could be changed to extend from Sprite and be written purely in AS3, essentially just the creationComplete code should be moved to the constructor. How this works is the SteamCanvas is a wrapper for whatever controls or components you want to put in it (just like a normal canvas uses absolute positioning, but could have containers that define layout nested within it if need be). The SteamCanvas sets up a timer and if the mouse is down when the timer ticks, it creates instances of BitOfSteam and sets the properties for the steam based on the SteamCanvases own currently set properties. In the project you'll also see a SteamEffectTest.mxml which is just the file you see running that has the sliders on it to change the properties of the SteamCanvas, I used these to come up with what I thought were good values to make somewhat realistic steam. If I remember I'll revisit this component tomorrow and try to take Marty's suggestions to get it updated.
In AS3 I create a number of playing cards through a class that extends a sprite.
I then add and remove these to stage throughout the game.
I was wondering, is this the right way to do it? Is it processor intensive to keep adding and removing objects?
I suppose that when you say "adding and removing objects" you mean adding and removing to/from the stage.
It is more processor intensive to create and destroy the objects over and over than to add and remove to/from the stage. So I'd say that you're safe.
However, an alternative to adding and removing to the stage is to change the visible propety of your sprites. This is even less processor intensive and could be a suitable solution for you. Note that when an object is invisible, it's still there. It just doesn't show. See this question on StackOverflow: visible property of DisplayObject
My questioin is pretty much in the title, Why do I keep reading in actionscript 3.0 that its a good idea to seperate the 'mind' from the 'object' when writing code?
Thanks for any help, this is confusing the hell out of me.
If you're asking why graphics are separated from the positioning, movement and physics; take this tree I've drawn:
In the tree you'll see that Entity has two properties:
Graphics - what the entity should look like.
Body - where the entity should be.
Moving down, you will see that there are several things that extend Entity - most notable are the Player and the Enemy classes.
Extending my Entity class above, I can easily change what should be used as the graphics and also provide slightly different bodies. For example, the player and enemies will have obviously different appearances, and the Tree class won't need to use a Body that deals with values like velocity because it doesn't move.
Here are some advantages of the above:
We can create entities that don't have graphics, saving performance and memory.
We can use different types of graphics rather than having to stick to MovieClip if you had extended MovieClip with your Entity class.
We can add additional logic into the Graphics class such as being able to easily covert a Sprite or MovieClip into a sprite sheet for better performance.
The graphics will be easier to manage and more lightweight (as opposed to if it were auto-bundled with each entity).
Physics will be easier to deal with without needing to know about graphics.
The Body can be updated without immediate effects on the graphics.
Your understanding of physics being completely unrelated to appearance will improve significantly.
Wasn't sure if this question belongs here, but I'll try. So I'm about to move my project from Director | Shockwave Player (if you ever heard of these) to Flash Player for numerous reasons and while I'm thinking how to better start off I got a question which really made me wonder. To the point.
Currently in Director each game window in the user interface (like small alerts or large windows with lot of elements in them) is drawn upon need - meaning that the actual window's graphical image is being put together from configuration (all sorts of properties like width, height and all elements and their properties) from numerous pieces of graphics (e.g. window background is made from 9 small pieces like the 4 corners, 4 middle pieces between corners for dynamic width and height and 1 central piece to fill the window) and then added to stage. This approach makes it easy to edit each graphical element without having to redraw the actual windows and everything in them if we would like to change the color scheme or improve something in a element. It also saves the resources as windows are being drawn only when requested.
Now I got to figure out if it's worth writing such code in Flash too as opposite to just creating all the windows and placing them in the library and adding to stage when they are requested. What do you think? Is it worth writing such implementation?
IMO, it depends on 1) How comfortable you are with Flash's drawing API / graphics class, and 2) How flexible each window/dialog needs to be.
If it's easier to just throw them together as static objects -- and if they don't necessarily need the flexibility to change dimensions/style much (can you count on one hand how many times they've needed to change since it was originally done in Director many years ago?), it's obviously easier to do this than going through the time/energy to recreate them dynamically, especially if you're not very comfortable with Flash's drawing API.
That said, a lot can be accomplished dynamically with Flash's drawing API, so if you have the time/interest I'd certainly suggest digging in and doing it the "right" way if you want to familiarize yourself with the drawing API.
My method for doing this sort of thing usually goes like this:
Create a separate class that extends Sprite/MovieClip; something like 'Dialog.as'.
Create public init(), show(), and hide() methods, and a private build() method.
init() is called just once upon initialization of your app, and takes some global parameters to hold on to internally (padding, colors, etc).
show() takes an argument of either text (a String), or even a Sprite/MovieClip -- whatever it is you want to show in this dialog. When called (when you want to spawn a window), it uses this -- plus whatever init parameters were originally passed in during init() -- to draw itself, and then unhides itself (tween the .alpha property, or simply set the .visible property).
When you want to close the dialog, make sure to invoke the hide() method, which first hides itself, and then cleans up whatever was created (removing listeners, etc) so that the next time it is called upon it can draw itself fresh.
It might also make sense to pass into this object a reference to the Stage (in the original init() call), so that it can center and size itself accordingly on the stage, and also addChild itself to the top of the display list so that it's always above everything else.
I hope this helps.
If is 2D you can check this:
http://pushbuttonengine.com/
if is 3D you can start here:
http://alternativaplatform.com/en/alternativa3d/
I can suggest you also Unity3D but this is outside of flash
Hope it helps