flixel
June 5, 2009 6:01 PM Subscribe
flixel is an ActionScript 3 framework abstracted from Adam Atomic's raster-based games, including FATHOM (previously) and Gravity Hook.
Because raster-based games are precise to the pixel level, they feel very different from most Flash games, which are usually vector based, run at a low framerate, and use Flash's imprecise libraries and tools.
This is a pure ActionScript framework, so it can be compiled using free tools.
Because raster-based games are precise to the pixel level, they feel very different from most Flash games, which are usually vector based, run at a low framerate, and use Flash's imprecise libraries and tools.
This is a pure ActionScript framework, so it can be compiled using free tools.
As someone who just learned how to program in Actionscript, like, yesterday, is this something I can use or is this more advanced? I'm not sure how to make the leap out of the Flash program itself..
posted by amethysts at 6:45 PM on June 5, 2009
posted by amethysts at 6:45 PM on June 5, 2009
As someone who just learned how to program in Actionscript, like, yesterday, is this something I can use or is this more advanced? I'm not sure how to make the leap out of the Flash program itself..
It's pure code. To use it, you don't do any work on Flash's timeline (or use Flash's graphics tools). You write code in an editor like Eclipse, FlashDevelop, Flex or Flash's Actions window.
If you want to make that leap, there is a huge training industry salivating to help you: course, books, tutorials, online training. I recommend this book, coming soon from Friends of Ed (the publish the best books for beginners). You might also want to watch the training videos on Lynda.com.
posted by grumblebee at 7:19 PM on June 5, 2009
It's pure code. To use it, you don't do any work on Flash's timeline (or use Flash's graphics tools). You write code in an editor like Eclipse, FlashDevelop, Flex or Flash's Actions window.
If you want to make that leap, there is a huge training industry salivating to help you: course, books, tutorials, online training. I recommend this book, coming soon from Friends of Ed (the publish the best books for beginners). You might also want to watch the training videos on Lynda.com.
posted by grumblebee at 7:19 PM on June 5, 2009
"...and use Flash's imprecise libraries and tools"
huh?
posted by grumblebee at 7:24 PM on June 5, 2009
huh?
posted by grumblebee at 7:24 PM on June 5, 2009
So could a person with a smattering of amateur experience of programming in Java, Python and C++ pick this up and make a complete small game in a reasonable amount of time without paying any money? (or maybe small outlay for a good book? Suggestions?)
posted by DetonatedManiac at 7:37 PM on June 5, 2009
posted by DetonatedManiac at 7:37 PM on June 5, 2009
Yes! Actionscript 3.0 is the most Java-like language besides Java. Java folks get it immediately. The syntax is almost identical. I program AS for a living, and I read a lot of Java books for reference. It's like Spanish to AS's Portuguese.
If you're a developer, DON'T start with Flash (the authoring program), because it's chiefly a design and animation tool. Start with Flex, which is Eclipse + some Adobe addons. (The forthcoming version of Flex is going to be called Flash Builder.)
posted by grumblebee at 7:41 PM on June 5, 2009
If you're a developer, DON'T start with Flash (the authoring program), because it's chiefly a design and animation tool. Start with Flex, which is Eclipse + some Adobe addons. (The forthcoming version of Flex is going to be called Flash Builder.)
posted by grumblebee at 7:41 PM on June 5, 2009
Oh, you said "without paying any money." Flex is about $250. There's a free IDE called FlashDevelop that you could use, too. And Adobe has a free command-line compiler. So you can do it for 0$.
posted by grumblebee at 7:43 PM on June 5, 2009
posted by grumblebee at 7:43 PM on June 5, 2009
The free command-line mxmlc thing really does work. It's not at all easy to get arguments right. But it does indeed compile SWF's from the command-line, with absolutely no GUI interface, which made me fall in love with it, because I <3 command-line utilities and abhor the awful Flash movie/timeline metaphor, but I really like Flash in general.
Not for the faint of heart unless you've had some significant experience compiling other languages (especially java) from the command-line. But it really does work, which is something I wasn't fully convinced of until I actually got it to work.
As for this framework, haven't tried it, but I do find that the rather sparse documentation for most fashionable AS/Flex frameworks nowadays assume you have Flex Builder and leave you to fend for yourself otherwise. Which is kind of a shame, because a few copy-and-pasted shell commands can go a very long way.
posted by treepour at 7:56 PM on June 5, 2009
Not for the faint of heart unless you've had some significant experience compiling other languages (especially java) from the command-line. But it really does work, which is something I wasn't fully convinced of until I actually got it to work.
As for this framework, haven't tried it, but I do find that the rather sparse documentation for most fashionable AS/Flex frameworks nowadays assume you have Flex Builder and leave you to fend for yourself otherwise. Which is kind of a shame, because a few copy-and-pasted shell commands can go a very long way.
posted by treepour at 7:56 PM on June 5, 2009
> "huh?"
I've heard game designers shun Flash's collision detection in particular, as well as some of its other built-in features -- though I'm not an expert on the subject myself. Raster games in Flash generally use a single full-screen Bitmap and provide their own algorithms.
> "So could a person with a smattering of amateur experience of programming in Java, Python and C++ pick this up and make a complete small game in a reasonable amount of time without paying any money? (or maybe small outlay for a good book? Suggestions?)"
Definitely. I'm finding ActionScript really easy to learn, and I've only had experience with Java and C++. Try the tutorial I linked to: it's written for C++/SDL, but I'm having a lot of fun porting it to ActionScript 3.
Flex doubles as a nice ActionScript compiler and might be free for students. (Otherwise, it's a 60-day trial.)
posted by archagon at 8:28 PM on June 5, 2009
I've heard game designers shun Flash's collision detection in particular, as well as some of its other built-in features -- though I'm not an expert on the subject myself. Raster games in Flash generally use a single full-screen Bitmap and provide their own algorithms.
> "So could a person with a smattering of amateur experience of programming in Java, Python and C++ pick this up and make a complete small game in a reasonable amount of time without paying any money? (or maybe small outlay for a good book? Suggestions?)"
Definitely. I'm finding ActionScript really easy to learn, and I've only had experience with Java and C++. Try the tutorial I linked to: it's written for C++/SDL, but I'm having a lot of fun porting it to ActionScript 3.
Flex doubles as a nice ActionScript compiler and might be free for students. (Otherwise, it's a 60-day trial.)
posted by archagon at 8:28 PM on June 5, 2009
I <3>
Adobe has a marketing problem on their hands. The history of Flash is complicated, and people are really confused about the relationships between the various dev tools. Without going into the confusing history, here's where things stand now:
There's a browser plugin called the Flash Player (available for all major browsers and platforms, including Linux). It can play many different types of media (videos, audio, still images), and it's programmable with a language called Actionscript 3.0.
AS was once similar to Javascript (AS 1.0 and 2.0), but it's now more like Java. It's object oriented (classes, interfaces, getter/setters, etc.) and strongly typed. The file format for the Flash player is called SWF. Any app that can compile SWFs can make content for the Flash Player, and there are a ton of SWF-making programs (from Adobe and other companies). Several years ago, Adobe opened up the SWF format, making it legal for anyone to build a SWF-making application.
The main reason to use AS is to make SWFs interactive (e.g. as in a game). Without AS, SWFs can "only" display graphics, animations and videos -- and play sounds. SWFs without AS play the same way every time. They don't respond to user-interaction.
There's a development tool called the Flash CS4. It generates graphical content in the form of SWFs, so it's one of many tools that can develop content for the Flash Player. CS4's strength is making vector art and animation. It does have some weak tools that allow you to write Actionscript, but that's definitely not its strong point.
Adobe has a ton of other apps that can generate SWFs: After Effects, Photoshop, Illustrator, Dreamweaver... But they only have one tool that is an Pro-level Actionscript Editor: Flex. Flex can also compile your AS code into a ready-to-pay SWF. Flex is what most AS pros use for coding, though there are plenty of 3rd-party tools, most notably FlashDevelop and FDT.
But you can use any text editor to write AS. And you can compile your code into a SWF with free command-line tools.
Adobe is upset that people don't understand that Flex and Flash CS4 generate the same types of files -- SWFs that play back via the Flash Player. So they are about to rebrand Flex as "Flash Builder." I think this is a mistake. What is a "builder"? I would rebrand the two apps as Flash Coder (formerly Flex) and Flash Animator (Formerly CS4).
The other facet to all this is that Adobe is trying to build Flash Players into everything. Many mobile devices have Flash players on them (notably NOT the iPhone), and you can now compile Flash content into Adobe Air files, which run on the desktop, like native OS apps.
posted by grumblebee at 8:31 PM on June 5, 2009 [4 favorites]
Adobe has a marketing problem on their hands. The history of Flash is complicated, and people are really confused about the relationships between the various dev tools. Without going into the confusing history, here's where things stand now:
There's a browser plugin called the Flash Player (available for all major browsers and platforms, including Linux). It can play many different types of media (videos, audio, still images), and it's programmable with a language called Actionscript 3.0.
AS was once similar to Javascript (AS 1.0 and 2.0), but it's now more like Java. It's object oriented (classes, interfaces, getter/setters, etc.) and strongly typed. The file format for the Flash player is called SWF. Any app that can compile SWFs can make content for the Flash Player, and there are a ton of SWF-making programs (from Adobe and other companies). Several years ago, Adobe opened up the SWF format, making it legal for anyone to build a SWF-making application.
The main reason to use AS is to make SWFs interactive (e.g. as in a game). Without AS, SWFs can "only" display graphics, animations and videos -- and play sounds. SWFs without AS play the same way every time. They don't respond to user-interaction.
There's a development tool called the Flash CS4. It generates graphical content in the form of SWFs, so it's one of many tools that can develop content for the Flash Player. CS4's strength is making vector art and animation. It does have some weak tools that allow you to write Actionscript, but that's definitely not its strong point.
Adobe has a ton of other apps that can generate SWFs: After Effects, Photoshop, Illustrator, Dreamweaver... But they only have one tool that is an Pro-level Actionscript Editor: Flex. Flex can also compile your AS code into a ready-to-pay SWF. Flex is what most AS pros use for coding, though there are plenty of 3rd-party tools, most notably FlashDevelop and FDT.
But you can use any text editor to write AS. And you can compile your code into a SWF with free command-line tools.
Adobe is upset that people don't understand that Flex and Flash CS4 generate the same types of files -- SWFs that play back via the Flash Player. So they are about to rebrand Flex as "Flash Builder." I think this is a mistake. What is a "builder"? I would rebrand the two apps as Flash Coder (formerly Flex) and Flash Animator (Formerly CS4).
The other facet to all this is that Adobe is trying to build Flash Players into everything. Many mobile devices have Flash players on them (notably NOT the iPhone), and you can now compile Flash content into Adobe Air files, which run on the desktop, like native OS apps.
posted by grumblebee at 8:31 PM on June 5, 2009 [4 favorites]
I've heard game designers shun Flash's collision detection in particular
Weird. Flash doesn't have "collision detection." It has graphics with x/y coordinates. It can calculate these down to fractions of pixels. You can roll whatever collision detection you want. There is a simplistic Actionscript method called hitTest() which can tell you if bounding boxes are touching. Maybe that what you've heard about. It's not sufficient for complex tasks, and so most developers don't use it.
posted by grumblebee at 8:35 PM on June 5, 2009
Weird. Flash doesn't have "collision detection." It has graphics with x/y coordinates. It can calculate these down to fractions of pixels. You can roll whatever collision detection you want. There is a simplistic Actionscript method called hitTest() which can tell you if bounding boxes are touching. Maybe that what you've heard about. It's not sufficient for complex tasks, and so most developers don't use it.
posted by grumblebee at 8:35 PM on June 5, 2009
grumblebee, I meant collision detection between MovieClips, probably using hitTest(). Again, I'm not an expert on the subject, so I could be totally wrong.
In any case, raster-based Flash games feel a lot smoother and more precise than normal Flash games, for whatever reason. There are definitely exceptions (N comes to mind), but they use a ton of custom code.
posted by archagon at 8:45 PM on June 5, 2009
In any case, raster-based Flash games feel a lot smoother and more precise than normal Flash games, for whatever reason. There are definitely exceptions (N comes to mind), but they use a ton of custom code.
posted by archagon at 8:45 PM on June 5, 2009
There's something kinda cute/sad about watching the generation raised on Flash's timelines and vector-based graphics reinvent bitmap blitting.
posted by spudsilo at 8:50 PM on June 5, 2009 [8 favorites]
posted by spudsilo at 8:50 PM on June 5, 2009 [8 favorites]
Sorry, but you are wrong. There is no difference between collision detection between MovieClips and raster graphics. MovieClips are just containers, and raster graphics must be placed in containers. In fact, they are often placed in MovieClips. Whether you're programming raster or vector in Flash, you have the same coding options to move the graphics around and detect collisions. If you've seen imprecise games, you've just seen bad examples.
N would have taken the same amount of code if it had used raster graphics.
posted by grumblebee at 8:52 PM on June 5, 2009
N would have taken the same amount of code if it had used raster graphics.
posted by grumblebee at 8:52 PM on June 5, 2009
Also, Flash allows you to take a bitmap snapshot of a vector graphic, so ANY graphic in Flash can be a raster graphic if you want it to be.
I've been looking at Flixel tonight, and it's not a raster engine. It's a generalized game engine that moves game pieces around and applies physics to them. The actual pieces can be raster or vector. The Flixel developer just happens to like raster art, so he used it in his examples. But his framework is neutral about it.
posted by grumblebee at 8:55 PM on June 5, 2009
I've been looking at Flixel tonight, and it's not a raster engine. It's a generalized game engine that moves game pieces around and applies physics to them. The actual pieces can be raster or vector. The Flixel developer just happens to like raster art, so he used it in his examples. But his framework is neutral about it.
posted by grumblebee at 8:55 PM on June 5, 2009
grumblebee, you misunderstand. The raster games in Flash that I've seen don't use containers. They use a single Bitmap object for the screen and use copyPixels and the like to change the graphics.
To quote DrPetter: "The bitmap graphics are all done by simply copying rectangular regions between different bitmaps and having a single 320x240 one attached to the scene at 2x scaling. It all basically ends up being exactly like coding pixel games in any traditional language/api."
From what I understand, they feel smoother than most Flash games because a) they run at 60fps, and b) they use their own code for collisions, physics, graphics, etc. I didn't mean to imply that raster-based Flash games are inherently smoother than normal Flash games.
posted by archagon at 9:06 PM on June 5, 2009
To quote DrPetter: "The bitmap graphics are all done by simply copying rectangular regions between different bitmaps and having a single 320x240 one attached to the scene at 2x scaling. It all basically ends up being exactly like coding pixel games in any traditional language/api."
From what I understand, they feel smoother than most Flash games because a) they run at 60fps, and b) they use their own code for collisions, physics, graphics, etc. I didn't mean to imply that raster-based Flash games are inherently smoother than normal Flash games.
posted by archagon at 9:06 PM on June 5, 2009
Also, check out box2d, an AS Physics Engine (also fisix and APE); Papervision3D, a powerful 3D system with shapes, texture mapping, cameras and lights; GTween, an animation engine; flint, an AS particle system; flare, an AS data-visualization system;
posted by grumblebee at 9:11 PM on June 5, 2009 [5 favorites]
posted by grumblebee at 9:11 PM on June 5, 2009 [5 favorites]
"The raster games in Flash that I've seen don't use containers. They use a single Bitmap object for the screen and use copyPixels and the like to change the graphics."
(With that said, as grumblebee pointed out, it seems this framework uses a different technique.)
posted by archagon at 9:15 PM on June 5, 2009
(With that said, as grumblebee pointed out, it seems this framework uses a different technique.)
posted by archagon at 9:15 PM on June 5, 2009
The raster games in Flash that I've seen don't use containers. They use a single Bitmap object for the screen and use copyPixels and the like to change the graphics.
Ah, I see. Though that's not what Flixel does. But I'd like to see an engine that helps with what you're describing. I've done it a little, but nothing heavy-duty.
Flash movies, raster or vector run at any frame rate you want.
As I said, ALL well-made games use there own code for collisions and other physics. There's some good info on coding such stuff in "Making Things Move" and its sequel.
posted by grumblebee at 9:16 PM on June 5, 2009 [1 favorite]
Ah, I see. Though that's not what Flixel does. But I'd like to see an engine that helps with what you're describing. I've done it a little, but nothing heavy-duty.
Flash movies, raster or vector run at any frame rate you want.
As I said, ALL well-made games use there own code for collisions and other physics. There's some good info on coding such stuff in "Making Things Move" and its sequel.
posted by grumblebee at 9:16 PM on June 5, 2009 [1 favorite]
Yes. All I meant to say was that it's a lot easier to make a crappy-playing game in normal Flash than using the single-Bitmap technique, and that most normal Flash games aren't nearly as smooth as the recent crop of raster-based Flash games -- probably because they have crappy collision and run at around 30FPS.
Hopefully, this framework will help to change this.
posted by archagon at 9:32 PM on June 5, 2009
Hopefully, this framework will help to change this.
posted by archagon at 9:32 PM on June 5, 2009
But I must confess that I had some misconceptions when posting this, so thanks for the clarification, grumblebee!
posted by archagon at 9:36 PM on June 5, 2009
posted by archagon at 9:36 PM on June 5, 2009
From a seasoned pro, FlashDevelop is the best thing to code in (if you're on Windows or you don't mind being in a VM) and it's open source. Please donate if you come to love it.
posted by dickasso at 11:20 PM on June 5, 2009
posted by dickasso at 11:20 PM on June 5, 2009
I downloaded it and found it extremely interesting to see how he sets up his game architecture. Clearly Adam has used it to make some very well executed games.
But I don't think it's well suited to its aim of providing a framework for rapid game development. A beginner would probably be completely lost at how to use or extend the various classes. A more experienced coder would already have his or her own way of accomplishing the same tasks.
The code isn't as well organized as one would want for a general purpose game framework-- for example the main enter frame method is over 400 lines long. A lot of the functions aren't well documented, so it's not obvious what they do or why you would use them.
Still, I think it's great that he released this.
posted by justkevin at 11:31 PM on June 5, 2009
But I don't think it's well suited to its aim of providing a framework for rapid game development. A beginner would probably be completely lost at how to use or extend the various classes. A more experienced coder would already have his or her own way of accomplishing the same tasks.
The code isn't as well organized as one would want for a general purpose game framework-- for example the main enter frame method is over 400 lines long. A lot of the functions aren't well documented, so it's not obvious what they do or why you would use them.
Still, I think it's great that he released this.
posted by justkevin at 11:31 PM on June 5, 2009
There's something kinda cute/sad about watching the generation raised on Flash's timelines and vector-based graphics reinvent bitmap blitting.
spudsilo, imagine what some of us Flash programmers had to do with QR decompositions for multi-touch apps. It's like reinventing a linear least squares solver.
The flixel library looks interesting. Flash only got pixel access back in version 8. Per pixel manipulation on a large scale wasn't really worthwhile until the rewrite of the engine in 9 (AVM2). With the increases in computer performance, things are even better now with 10. Alchemy shows promise for certain situations, alas, not many clients want to pay for play time.
flixel is a welcome addition to the OSS libraries based on that old, crappy vector animation tool. Now if Adobe will only grace us with GPU acceleration and multithreading.
For dev tools, I'll also give thumbs up to Flex, Eclipse, and FlashDevelop. You can use ant with all three which makes building much nicer.
posted by ryoshu at 12:04 AM on June 6, 2009
spudsilo, imagine what some of us Flash programmers had to do with QR decompositions for multi-touch apps. It's like reinventing a linear least squares solver.
The flixel library looks interesting. Flash only got pixel access back in version 8. Per pixel manipulation on a large scale wasn't really worthwhile until the rewrite of the engine in 9 (AVM2). With the increases in computer performance, things are even better now with 10. Alchemy shows promise for certain situations, alas, not many clients want to pay for play time.
flixel is a welcome addition to the OSS libraries based on that old, crappy vector animation tool. Now if Adobe will only grace us with GPU acceleration and multithreading.
For dev tools, I'll also give thumbs up to Flex, Eclipse, and FlashDevelop. You can use ant with all three which makes building much nicer.
posted by ryoshu at 12:04 AM on June 6, 2009
This sounds interesting... but retro-style, low resolution games are exactly the sort of thing that doesn't usually need highly-optimised coding. I just completed a game simulating an '80s coin-op and used ordinary Movieclips etc., only adding bitmap manipulation to grab the low-res game area, zoom, blur and apply a scanline effect (might release a library for simulating dodgy old displays). Using timelines made it easier to tweak visuals and quickly incorporate sounds.
flixel would be ideal for something like a hectic retro shoot-em-up though.
Nowadays there seems to be a huge gulf between those approaching Flash from the coding-orientated, Java-friendly side, and those working with the IDE to tie things together more visually. There's interesting work being produced on both sides, but developing 'properly' with AS3, class files, etc., is difficult and cumbersome for many people vs. hooking things together with simple AS2 in the IDE. Adobe could've done more to minimise that divide.
"There's something kinda cute/sad about watching the generation raised on Flash's timelines and vector-based graphics reinvent bitmap blitting."
Yeah, as someone who started doing games with BASIC and hand-coded machine code, I don't know whether to wince or smile at some of the contortions people go through to reinvent Flash rendering and animation. It's great when they're doing it to achieve something new and interesting, but all too often it's more about reproducing the restrictions they're used to from other technologies, or avoiding paying for the IDE.
posted by malevolent at 2:21 AM on June 6, 2009
flixel would be ideal for something like a hectic retro shoot-em-up though.
Nowadays there seems to be a huge gulf between those approaching Flash from the coding-orientated, Java-friendly side, and those working with the IDE to tie things together more visually. There's interesting work being produced on both sides, but developing 'properly' with AS3, class files, etc., is difficult and cumbersome for many people vs. hooking things together with simple AS2 in the IDE. Adobe could've done more to minimise that divide.
"There's something kinda cute/sad about watching the generation raised on Flash's timelines and vector-based graphics reinvent bitmap blitting."
Yeah, as someone who started doing games with BASIC and hand-coded machine code, I don't know whether to wince or smile at some of the contortions people go through to reinvent Flash rendering and animation. It's great when they're doing it to achieve something new and interesting, but all too often it's more about reproducing the restrictions they're used to from other technologies, or avoiding paying for the IDE.
posted by malevolent at 2:21 AM on June 6, 2009
Some digging into the source suggests that Flixel is based on blitting stuff around in Flash - have a look at render() in FlxSprite.as and notice all the references to copyPixels() and draw(), both happening on FlxG.buffer, which is a Flash BitmapData object. This is a pixel-blit framework for Flash.
As to why pixel-blit games tend to feel smoother: the Flash player draws all your vector objects with nothing but CPU - no hardware acceleration, no nothing. Bitmap objects, on the other hand, hook into the capabilities of your computer's video card, and are much simpler to draw even if they have to be done by the CPU. Block-copying a bitmap is a hell of a lot less work than evaluating a long list of vector drawing instructions! Blitting stuff around like this also works around some serious retardedness in how Flash handles updating the screen.
This framework looks like it would be pretty useful for starting with for someone who wanted to make games reminiscent of the eighties and nineties; it handles a lot of simple videogamey 2D physics for you, it does pixel-level collision detection, and it handles building a tile-based world and following a given sprite around it - a lot of common gruntwork that's nice to not have to write from scratch when you're starting! It looks like there's some capabilities he hasn't really used in his games, either - for instance I think it would be pretty easy to do some slick parallax background/foreground tricks with this.
(Grumpy rant about how Adobe took AS2, a nice fun Javascript dialect [far far better than the nightmare of AS1, a Basic-flavored thing you had to enter via a drop-down menu], and turned it into AS3, a formerly fun Javascript dialect now weighed down by the incredible verbosity of Java programming conventions goes here.)
posted by egypturnash at 7:20 AM on June 6, 2009
As to why pixel-blit games tend to feel smoother: the Flash player draws all your vector objects with nothing but CPU - no hardware acceleration, no nothing. Bitmap objects, on the other hand, hook into the capabilities of your computer's video card, and are much simpler to draw even if they have to be done by the CPU. Block-copying a bitmap is a hell of a lot less work than evaluating a long list of vector drawing instructions! Blitting stuff around like this also works around some serious retardedness in how Flash handles updating the screen.
This framework looks like it would be pretty useful for starting with for someone who wanted to make games reminiscent of the eighties and nineties; it handles a lot of simple videogamey 2D physics for you, it does pixel-level collision detection, and it handles building a tile-based world and following a given sprite around it - a lot of common gruntwork that's nice to not have to write from scratch when you're starting! It looks like there's some capabilities he hasn't really used in his games, either - for instance I think it would be pretty easy to do some slick parallax background/foreground tricks with this.
(Grumpy rant about how Adobe took AS2, a nice fun Javascript dialect [far far better than the nightmare of AS1, a Basic-flavored thing you had to enter via a drop-down menu], and turned it into AS3, a formerly fun Javascript dialect now weighed down by the incredible verbosity of Java programming conventions goes here.)
posted by egypturnash at 7:20 AM on June 6, 2009
But they only have one tool that is an Pro-level Actionscript Editor: Flex. Flex can also compile your AS code into a ready-to-pay SWF. Flex is what most AS pros use for coding ...
Just a minor quibble; Flex Builder is the editing tool, Flex is the SDK with compiler.
(Grumpy rant about how Adobe took AS2, a nice fun Javascript dialect [far far better than the nightmare of AS1, a Basic-flavored thing you had to enter via a drop-down menu], and turned it into AS3, a formerly fun Javascript dialect now weighed down by the incredible verbosity of Java programming conventions goes here.)
My understanding is that this is where the better runtime performance comes from. Flex 1 and all prior versions of the Flash IDE targeted AVM1, which runs AS1 and AS2. Flex 1 programs had lots of performance problems, such as the inability to handle large data sets. AVM2, which runs AS3, provides much better runtime performance, making Flex apps suitable for actual business use.
And, for what it's worth, AS3 appears to be the future of JavaScript - it conforms to the latest ECMAScript standard, and of course ECMA is the "owner" of official JavaScript specs. Adobe/Macromedia employees have been contributors to the ECMA JS board. So eventually, strong typing, etc, may be coming to a browser near you!
posted by me & my monkey at 9:29 AM on June 6, 2009
Just a minor quibble; Flex Builder is the editing tool, Flex is the SDK with compiler.
(Grumpy rant about how Adobe took AS2, a nice fun Javascript dialect [far far better than the nightmare of AS1, a Basic-flavored thing you had to enter via a drop-down menu], and turned it into AS3, a formerly fun Javascript dialect now weighed down by the incredible verbosity of Java programming conventions goes here.)
My understanding is that this is where the better runtime performance comes from. Flex 1 and all prior versions of the Flash IDE targeted AVM1, which runs AS1 and AS2. Flex 1 programs had lots of performance problems, such as the inability to handle large data sets. AVM2, which runs AS3, provides much better runtime performance, making Flex apps suitable for actual business use.
And, for what it's worth, AS3 appears to be the future of JavaScript - it conforms to the latest ECMAScript standard, and of course ECMA is the "owner" of official JavaScript specs. Adobe/Macromedia employees have been contributors to the ECMA JS board. So eventually, strong typing, etc, may be coming to a browser near you!
posted by me & my monkey at 9:29 AM on June 6, 2009
I understand why you pine for the simpler days of AS2. For instance, here's one thing that tends to bug people. In 2, you could load an external asset this way:
someLoaderClass.load( "resource.jpg" );
Whereas in 3, you have to do this:
var urlReq : UrlRequest = new URLRequest( "resource.jpg" );
someLoaderClass.load( urlReq );
Of course, you can shorten that to...
someLoaderClass.load( new URLRequest( "resource.jpg" ) );
... but it still seems overly verbose.
The problem with the 2 version is that it's not scalable. The load() method just accepts a string, and a string can't contain any data except the text of that string. On the other hand, the URLRequest object can contain all sorts of info that travels along with the url, for instance whether or not a locally-cached version of the resource should be used if it exists:
var urlReq = new URLRequest( "http://www.site.com/resource.jpg" );
urlReq.useCache = true;
someLoaderClass.load( urlReq );
More important, the URLRequest object can scale for unforeseeable future developments. Say that a second web arises, called web2, and our browsers can pull resources from web1 or web2. Both webs can have a url called www.site.com/resource.jpg which might be totally different files. If this happens, Adobe could instantly release an update with a new property for the URLRequest object:
var urlReq = new URLRequest( "http://www.site.com/resource.jpg" );
urlReq.webNumber = 2;
someLoaderClass.load( urlReq );
Although that's an unlikely possibility, technology IS moving quickly and Flash needs to be scalable to keep up.
Finally, I would say that there's no reason to be grumpy about AS3, because (a) AS1 and AS2 are still supported (and I've heard nothing about them going away). Flash Player 10 can playback SWFs created using any of the AS Versions. And (b) you can easily write classes and methods in AS3 that simplify it for everyday use:
function loadReasource( url : String ) : void
{
var urlReq = new URLRequest( url );
someLoaderClass.load( urlReq );
}
loadResource( "resource.jpg" );
In fact, this is good programming practice: abstract away from lower-level, frequently used statements and processes.
Just gradually develop a library of such methods, and you'll bring the swiftness of AS2 back into AS3.
posted by grumblebee at 9:56 AM on June 6, 2009
someLoaderClass.load( "resource.jpg" );
Whereas in 3, you have to do this:
var urlReq : UrlRequest = new URLRequest( "resource.jpg" );
someLoaderClass.load( urlReq );
Of course, you can shorten that to...
someLoaderClass.load( new URLRequest( "resource.jpg" ) );
... but it still seems overly verbose.
The problem with the 2 version is that it's not scalable. The load() method just accepts a string, and a string can't contain any data except the text of that string. On the other hand, the URLRequest object can contain all sorts of info that travels along with the url, for instance whether or not a locally-cached version of the resource should be used if it exists:
var urlReq = new URLRequest( "http://www.site.com/resource.jpg" );
urlReq.useCache = true;
someLoaderClass.load( urlReq );
More important, the URLRequest object can scale for unforeseeable future developments. Say that a second web arises, called web2, and our browsers can pull resources from web1 or web2. Both webs can have a url called www.site.com/resource.jpg which might be totally different files. If this happens, Adobe could instantly release an update with a new property for the URLRequest object:
var urlReq = new URLRequest( "http://www.site.com/resource.jpg" );
urlReq.webNumber = 2;
someLoaderClass.load( urlReq );
Although that's an unlikely possibility, technology IS moving quickly and Flash needs to be scalable to keep up.
Finally, I would say that there's no reason to be grumpy about AS3, because (a) AS1 and AS2 are still supported (and I've heard nothing about them going away). Flash Player 10 can playback SWFs created using any of the AS Versions. And (b) you can easily write classes and methods in AS3 that simplify it for everyday use:
function loadReasource( url : String ) : void
{
var urlReq = new URLRequest( url );
someLoaderClass.load( urlReq );
}
loadResource( "resource.jpg" );
In fact, this is good programming practice: abstract away from lower-level, frequently used statements and processes.
Just gradually develop a library of such methods, and you'll bring the swiftness of AS2 back into AS3.
posted by grumblebee at 9:56 AM on June 6, 2009
Somebody sent me this interesting link about display list vs. single bitmap rendering in ActionScript. Apparently, the "naive" display list method is significantly slower than the single bitmap method.
posted by archagon at 12:23 PM on June 6, 2009
posted by archagon at 12:23 PM on June 6, 2009
Reasons why AS3 makes me grumpy:
- Create a new file in Flash and it defaults to AS3. Every time.
- Even just wiring up a button is about 30% more stuff to type - even if you're a non-programmer type just looking to add some basic interactivity to your Flash file.
- sweet mother of fucker if I wanted the hassle of declaring every single variable before I could use it I would be using a language that actually compiles to a real binary.
- Sure, the player will interpret your old AS1/2 files... but none of the speed boosts apply.
- It's just one more thing amidst all the other changes for the sake of change that have been done to the Flash editor since v5. I still loathe all the extra clicks that furslugginer "smart" inspector panel makes me do when I'm trying to do symbol manipulation.
- Maybe I gave up looking too early, butMacromedia'sAdobe's docs on migrating from AS2 to AS3 are pretty much nonexistant. Bring an AS2 codebase into an AS3 file, try to compile it, and Flash vomits forth an absolute torrent of errors and there's very little guidance on how to fix this.
I know they're not going back to the old way, what with their dreams of World Domination Through Flash On Everything than look pretty much exactly like Sun's failed dreams of World Domination Through Java On Everything. But I sure ain't coming along for the ride; I like being able to knock out something that's quick, sloppy, ugly, and functional and get on with my life instead of having to make it absolutely Stylistically Correct and Thoroughly Extensible. Hacking stuff in Actionscript is just the part-time day job, and not even the whole of it; the real passion is art.
Anyway, pardon my rant, but hey, y'all responded to my parenthesis, and that kinda invoked the actual rant instead of the placeholder. *grin*
posted by egypturnash at 6:02 PM on June 6, 2009
- Create a new file in Flash and it defaults to AS3. Every time.
- Even just wiring up a button is about 30% more stuff to type - even if you're a non-programmer type just looking to add some basic interactivity to your Flash file.
- sweet mother of fucker if I wanted the hassle of declaring every single variable before I could use it I would be using a language that actually compiles to a real binary.
- Sure, the player will interpret your old AS1/2 files... but none of the speed boosts apply.
- It's just one more thing amidst all the other changes for the sake of change that have been done to the Flash editor since v5. I still loathe all the extra clicks that furslugginer "smart" inspector panel makes me do when I'm trying to do symbol manipulation.
- Maybe I gave up looking too early, but
I know they're not going back to the old way, what with their dreams of World Domination Through Flash On Everything than look pretty much exactly like Sun's failed dreams of World Domination Through Java On Everything. But I sure ain't coming along for the ride; I like being able to knock out something that's quick, sloppy, ugly, and functional and get on with my life instead of having to make it absolutely Stylistically Correct and Thoroughly Extensible. Hacking stuff in Actionscript is just the part-time day job, and not even the whole of it; the real passion is art.
Anyway, pardon my rant, but hey, y'all responded to my parenthesis, and that kinda invoked the actual rant instead of the placeholder. *grin*
posted by egypturnash at 6:02 PM on June 6, 2009
I don't want to come across as an Adobe apologist, especially since I think Flash CS4 is a sucky program. But I'm confused about this: "Create a new file in Flash and it defaults to AS3. Every time."
That's not how my copy of CS4 works (Mac version). Whether I choose File > New or type Command+S, I get a dialogue that asks me which version of AS I want to use. And whatever I choose will become the default from that time on. I just tried it: I chose AS 2, and then started a new file. Flash assumed I wanted that file to be AS2, also.
But I do sympathize your desire to hack together messy code that works. Alas for you, the entire programming community is moving farther and farther away from that. It's because apps are getting so complex that those sort of hacks are dangerous. Complex systems must be well organized if they have any chance of working and being extensible. But it does leave the dabbler in the dust, and as a former dabbler, I agree it's sad.
However, there are a TON of resources to help people make the switch from AS2 to AS3. For instance, Friends of Ed has some great books on the subject. Let me gently suggest that you NEVER EVER EVER tget your main info on an app from the app's vendor. I know it seems like Adobe should be the source of Adobe Flash info, but Adobe's skills are building software and selling software. They are not experts in documenting software. In my experience the software vendor ALWAYS has the worst information about their software. So turn to the REAL experts for help: the book publishers, the teachers, the tutorial writers, etc. Avoid "from the souce" books.
And don't sit around grumbling about having to do too much work in AS3. Write yourself some code to make your work easier -- or get someone else to do it for you.
Here's how to wire up a button really easily:
makeButtonWork( myButton, doThis );
doThis = function( event : MouseEvent ) : void
{
trace("hello");
}
Compare that to AS 2:
myButton.onRelease = doThis;
function doThis() :Void
{
trace("hello");
}
Almost the same amount of code. Of course, I cheated. In order to make my AS 3 version work, I had to create this function:
function makeButtonWork( button : DisplayObject, func : Function ) : void
{
button.addEventListener( MouseEvent.CLICK, func );
}
But I only had to do that once, and from then on, all I have to do is to import that function into new AS files. So it seems a little silly to me to grumble and rant about something that's so easy to fix.
Finally, if you don't like the verbosity of AS 3 variables, just do this:
var highscore : * = 10;
var username : * = "Fred Smith";
highscore = highscore + 14;
Compare that to AS 2:
highscore = 10;
username = "Fred Smith";
highscore = highscore + 14;
The AS 3 version is only a few characters longer. Of course, declaring all variables as * (variables that can accept any type) is a bad practice, but if you're hacking, it works.
posted by grumblebee at 9:27 PM on June 6, 2009
That's not how my copy of CS4 works (Mac version). Whether I choose File > New or type Command+S, I get a dialogue that asks me which version of AS I want to use. And whatever I choose will become the default from that time on. I just tried it: I chose AS 2, and then started a new file. Flash assumed I wanted that file to be AS2, also.
But I do sympathize your desire to hack together messy code that works. Alas for you, the entire programming community is moving farther and farther away from that. It's because apps are getting so complex that those sort of hacks are dangerous. Complex systems must be well organized if they have any chance of working and being extensible. But it does leave the dabbler in the dust, and as a former dabbler, I agree it's sad.
However, there are a TON of resources to help people make the switch from AS2 to AS3. For instance, Friends of Ed has some great books on the subject. Let me gently suggest that you NEVER EVER EVER tget your main info on an app from the app's vendor. I know it seems like Adobe should be the source of Adobe Flash info, but Adobe's skills are building software and selling software. They are not experts in documenting software. In my experience the software vendor ALWAYS has the worst information about their software. So turn to the REAL experts for help: the book publishers, the teachers, the tutorial writers, etc. Avoid "from the souce" books.
And don't sit around grumbling about having to do too much work in AS3. Write yourself some code to make your work easier -- or get someone else to do it for you.
Here's how to wire up a button really easily:
makeButtonWork( myButton, doThis );
doThis = function( event : MouseEvent ) : void
{
trace("hello");
}
Compare that to AS 2:
myButton.onRelease = doThis;
function doThis() :Void
{
trace("hello");
}
Almost the same amount of code. Of course, I cheated. In order to make my AS 3 version work, I had to create this function:
function makeButtonWork( button : DisplayObject, func : Function ) : void
{
button.addEventListener( MouseEvent.CLICK, func );
}
But I only had to do that once, and from then on, all I have to do is to import that function into new AS files. So it seems a little silly to me to grumble and rant about something that's so easy to fix.
Finally, if you don't like the verbosity of AS 3 variables, just do this:
var highscore : * = 10;
var username : * = "Fred Smith";
highscore = highscore + 14;
Compare that to AS 2:
highscore = 10;
username = "Fred Smith";
highscore = highscore + 14;
The AS 3 version is only a few characters longer. Of course, declaring all variables as * (variables that can accept any type) is a bad practice, but if you're hacking, it works.
posted by grumblebee at 9:27 PM on June 6, 2009
« Older Nature's Elegant Solutions | Let's get this thing goin' before cats start dyin'... Newer »
This thread has been archived and is closed to new comments
posted by archagon at 6:06 PM on June 5, 2009