Flash makes it pretty easy to use any
DisplayObject as a
Stage3D texture. This is a great feature since you can use powerful, traditional classes like
Shape to build a texture—often with vector graphics—and then use
Stage3D‘s GPU hardware acceleration to render them with maximum performance. But this path is fraught with subtle problems, any one of which could result in poor rendering quality that’s quite hard to debug. Today’s article takes you through the process step by step to make sure you end up with great results.
Flash makes it pretty easy to use any
AMF is great for serializing AS3 objects. Its compact binary format is far more efficient than XML or JSON and it’s just as easy to use: just call
readObject. However, there are many ways to make it even more efficient. Today’s article presents one more way that eliminates some overhead you might not have thought out. Read on to learn more and for a helper class that will enable you to avoid it.
To save precious bandwidth, keeping your AMF data size small is crucial. By default, AMF has a tendency to create bloated data sizes. In the last article, I showed a way to shrink your class names to a single character when stored in AMF data. Today I’ll show a you a trick to shrink your class field names to a single character. Read on to find out how.
Stage3D is hugely powerful, but with that power comes a very new and very complicated requirement for many programmers: shaders. Shaders are tiny programs that run on the GPU and are hugely limited compared to fancy CPU-side languages like AS3. For many programmers new to shaders these things are truly mind-bending. They’re even split into two parts: vertex and fragment shaders. Today’s article focuses on the two kinds of inputs to vertex shaders and seeks to explain them and clear up some of the confusion.
Whether you’re using Adobe Scout or good old
getTimer, there is a fundamental limitation: all times are in whole milliseconds. This is an issue if you’re trying to measure code that executes very quickly or compare code that has only minor differences. In these cases you get inconsistent results (7ms, 8ms, 7ms, 7ms, 8ms, …) when you’d much rather have better accuracy (7.3ms) with sub-millisecond precision. Today’s article introduces a new helper class called
Timely that makes sub-millisecond precision a snap. Read on for the source code and an example app.
[Embed] metadata tag has been in AS3 since the beginning, but few know how to use it fully. Today’s article shows how you can go beyond the standard usage to maximize the usefulness of
[Embed]. Read on for some useful tricks you may not know about and take another step toward mastering AS3.
JSON class that debuted with Flash Player 11 has an interesting feature that few AS3 programmers know about. It turns out that
JSON.parse doesn’t just take the JSON document to parse but also a “reviver”
Function. What is this? How can it be used? Find out more in today’s article and take advantage of this powerful parsing option.
In last week’s primer on the new domain memory (“Alchemy”) opcodes the initial test showed that they couldn’t match the performance of good old
Vector when writing out a lot of float/
Number values. Today’s article expands on that test to check the performance of writing integers and the performance of reading integers and float/
Number values. Can the domain memory opcodes redeem themselves? Read on to find out.
Since January, Adobe has dropped the “premium features” requirement for Flash apps that use the “domain memory opcodes” (a.k.a. “Alchemy opcodes”) that provide low-level performance-boosting operations that let you deal more-or-less directly with blocks of memory. Then in February we got Flash Player 11.6 along with built-in ASC 2.0 support for this feature. Today’s article shows you how to use these opcodes and takes a first stab at improving performance with them. Are they really all they’re cracked up to be?