I’m teaching a class on ActionScript 3.0 this year so I’ve been making slides for it, and in the spirit of educational freedom I thought I’d post them up here to see if they’re of use to anyone. The original class I’m taking is Certificate III in Media, CUFDIG302A – Author Interactive Sequences. For those of you unfamiliar with the Australian education system, this means that the course is quite rudimentary, and is aimed at students aged 17 and over.
These slides will not cover the in-depth use of Flash CS4 tools (instead I’ll post a quick Zero-Week primer soon), but will cover some interactive design techniques. Mainly though, they’ll teach you how to use ActionScript 3.0 with Flash CS4 – from the ground up, starting from scratch.
There’s a download link to the slides along with some legal gubbins regarding their use after the jump, so if you fancy learning ActionScript – you’ll find the knowledge to start from absolute basics right here, and over the coming weeks we’ll ramp up to Symbols, Classes, Events, Object Orientation, Interaction, Sound, Collision Detection and all that other good stuff. We’ll even make a couple of flash games – which should be quite fun :)
I got a comment about ActionScript 3 the other day which asked a simple and fair question (paraphrased as):
If you’re just using simple shapes like circles, is it faster to draw them to the stage with drawCircle, or to use MovieClips/Sprites to draw them?
Did I know the answer? Um, no… So I knocked up a quick bit of flash to find out. Before you’re given the answer, why not have a quick ponder about what you think will happen? I’ve got to admit, when I did this I got completely the wrong result! Ha! Shows what I know about anything…
Brief analysis plus source-code n’ file after the jump…
Ha! I’ve cracked it! This really shouldn’t have taken me as long as it did to get working, but now I can have pegs and balls of any size I fancy, and the collision detection works flawlessly. No more cheaky bodges to avoid double collisions, proper trig. offsets all the way… In fact, the only bodge left is adding a slight horizontal speed jitter to a ball if it ends up with a horizontal velocity of < 0.01 after a collision, because if it's bang over over the centre of the peg it'll stay there happily bouncing away until it comes to rest otherwise - which I think is fair enough.
So after all the additional hours, does it look any better? Nope… If anything it looks worse – but she’s my baby, and I’ve finally got ‘er working properly, so I don’t care! :D
Update: And by flawlessly, I mean that I’ve just noticed a very small ball going fast will go through a very small peg, because they never intersect… Drats! Guess I’ll have to check for ranged collisions (or increase the minimal ball/peg size, or limit the movement speed). Nothing’s ever easy, is it?
I’ve been working on writing a collision detection class, and it’s not as easy as you might think. It’s simple enough to boundary test (i.e. bounding-box overlap test), but to do per-pixel collisions you have to dump your symbol data into a BitmapData object, and you HAVE to use the top-left as the registration point for all your colliding symbol instances, which means you end up doing a lot of offsets & shiz… Ho hum.
Anyways, I knocked this Peggle / Pachinko thing together over the course of yesterday and today. You can place as many “pegs” as you want, wherever you want ’em, same with the “balls”, and in theory, I should be able to scale both pegs and balls to any size while still keeping the collisions accurate, but I’ve not tested that yet because after debugging this for a while I need a break.
But hey, look at the purty colours :)
No source-code for this one just yet as it’s not in a fit state (it has waaaay too much debug output per collision that I don’t want to strip out just yet, and enough swearing to make a salty sea-dog blush ;)). When I’ve knocked it into shape some more I’ll chuck the Peg, Ball and Collision classes here in an update.
Update: Source code and flash files now available after the jump. Some of the code is a bit yucky, so apologies in advance for my bodge-hackery =P
Flash gets a lot of negative press because it’s seen as using a heap of CPU time and bogging everything down. And it’s a fair cop. Most flash will eat up your CPU cycles even when it’s sitting there doing nothing. But this isn’t a fault of flash, but rather of flash developers. Let me explain…
When you start a piece of flash work, you assign it a frame rate at which you want it to run, so it’ll update the screen, say, 30 times a second. This is all fine and good for when you’re animating things on the stage. But what about when you’re not? Well, it’s still running at 30 frames per second and chewing up your CPU like a crazy melon farmer. This is Not A Good Thing. So, anyhow, I’m watching this video about SWF Framerate Optimisation, and the guy’s showing how you can modify your code to lower the frame rate when there’s not a lot happening, and bring it back up when you’re animating. So I had a crack at it, and lo & behold, it works fine for the specific piece of flash I’d coded it into, so I wondered if I couldn’t just go and make a RateController class. This way, I could add a RateController object to any project to dynamically change the project’s frame rate depending on whether the mouse was over the stage or not.
And after much swearing about not having global access to the stage properties, I found that I COULD!!!
Here’s a working example placed into the attracting particles code I wrote yesterday:
Note: The animation starts at full speed for two seconds on startup. It’ll drop to the sleeping rate (5 fps) two seconds after the mouse leaves the stage, and then ramps back up to its waking rate (30 fps) instantly when the cursor is back over the stage. The FPSCounter shows intermediate numbers because it’s based on an average.
To add a RateController to any flash project, you can just use something like:
import RateController;// Add a new RateController, uses the root stage, runs at 5fps when sleeping, 30fps // when active (i.e. when mouse is over the stage), and uses a 2000 millisecond// delay after the mouse leaves the stage before dropping the FPS to the sleeping rate.addChild(new RateController(stage,5,30,2000));