Flash 10.1 is out!
You can download it from the Adobe website: http://get.adobe.com/fr/flashplayer/.
Aerys joins the 24H Adobe AIR Challenge
The 24H Adobe AIR Challenge is a 24 hours long contest that will take place the 18th of June in Paris, France.
During this coding challenge, 15 teams of two people will have to build the best AIR application regarding a precise subject. This very subject will be unveiled as the competition starts.
The challenge will be broadcasted live from http://www.adobeairchallenge.com/.
Aerys is very proud to join the competition and we hope to see you there!
And here are a few useful links (in French) :
Flash 10.1 gets a release date
In reaction to Steve Jobs' latest outrageous declarations, Kevin Lynch himself announced the release date of Flash 10.1 for Android devices:
"We look forward to delivering Flash Player 10.1 for Android smartphones as a public preview at Google I/O in May, and then a general release in June. From that point on, an ever increasing number and variety of powerful, Flash-enabled devices will be arriving which we hope will provide a great landscape of choice."
You can read is full post here : Moving Forward.
From what I'e heard from Adobe so far, Flash 10.1 for the desktop should be released before the Android version. Meaning we can expect Flash 10.1 desktop to be released in May...
Update: In the following Wall Street Journal interview, Shantanu Narayen - Adobe's CEO - also comments Steve Jobs declarations and says Flash 10.1 will be released June 17th (3'10):
Flash 11 drawing API will be hardware accelerated
I love catchy titles. I know nothing about the next major version of Flash and all of this is just speculations.
Anyway, as the whole HTML5 versus Flash battle is raging, it appears Flash relatively poor performances are indeed criticizable at best. Beside poor developers, the Flash Platform suffers from a very very slow software renderer. Or at least much slower than the rest of the platform. It's no secret: hardware acceleration is a key feature for the future of the Flash Player. It's even hard to believe it is not available yet!
As you must already know, Flash 10.1 will support OpenGL ES 2 on mobile devices to leverage the lack of CPU horsepower. While hardware HD video decoding will be available on the desktop too, the drawing API will only be accelerated on mobile devices.
Anyone knowing a bit about OpenGL ES knows it is a subset of OpenGL. Thus if it works with OpenGL ES, it should work with OpenGL. With this in mind, a few questions:
- Why isn't Flash 10.1 drawing API hardware accelerated on any OpenGL capable platform, including the desktop?
- How will it work?
- Will Pixel Bender be hardware accelerated?
1. Hardware Accelerated Desktop Flash Player
Let's face it: there must be an hardware accelerated desktop Flash Player in the works. As I said previously, OpenGL supports all features of OpenGL ES so this is not far fetched at all. Yet, it is neither released nor announced. Why?
My first guess is OpenGL provides with a lot of features that would make the desktop experience a lot smoother than just using what offers its little brother OpenGL ES. So at some point Adobe had to make a choice :
- release a fully hardware accelerated Flash 10.1 on both mobile and desktop platforms, with the last one being very far from what desktop hardware is actually capable to handle
- or release Flash 10.1 focusing on mobile devices and announce hardware acceleration for the desktop just after its the final release... and I'm guessing it might be a key feature of Flash 11
When I was at the French Flash User Group (TTFX - les TonTons FleXeurs) a few months ago, I spoke with Lee Brimelow and Mike Chambers about the just announced microphone raw-data access. I asked them why it was announced only for AIR 2.0 and not Flash 10.1. The answer was something about the "quality guys" making sure the feature was well suited on both the roadmap and the logic of the incoming updates. And this feature eventually made its way into the Flash Player! I think that's what is happening with hardware acceleration on the desktop.
But if you don't believe me, you don't have to take my word for it! What about Adobe's word? Cnuuja, one of the engineer working on the Flash Player, posted this very message on the Flash 10.1 Forum:
Can OpenGL 3.3/4.0 improve Flash 10.x ?
"Yes.... with a lot of work. We have spent the last year writing new code which allows OpenGLES2 to render flash content on mobile devices. Performance varies significantly from one gpu to the next, with some gpus being slower than the software renderer. What Flash does is significantly different from the 3d triangles+shaders GPUs were designed to support. Its a lot of work to make OGL/D3D usable as our renderer, but we're working on it 
-chris"
2. How will it work?
Just like in Flash 10.1 for mobile devices. But much faster thanks to OpenGL and Direct3D.
The internals of such feature is very important: developers must know and understand how it works to make the best out of it. Adobe already talked about how the drawing API is accelerated in Flash 10.1 on mobile devices:
"When a GPU renders vector graphics, it breaks them up into meshes made of small triangles before drawing them, a process called tesselating. There is a small cost to doing this, which increases as the complexity of the shape increases. To minimize performance impact, avoid morph shapes, which must be retesselated on every frame."
It's straight forward and I think it's actually the best (and only...) way to do it. Tesselation will create triangles by computing sets of vertices/indices (also called Vertex and Index Buffers) and push them to the graphics hardware. The end of the quote suggests such data is cached and should not be recomputed if no redraw occurs.
Something very important though: z-sorting. People might think hardware acceleration implies z-sorting. But it doesn't. When you know how 3D hardware and APIs work, you know it will be very tricky to make it work with something as general purpose as Flash. If Adobe wants to use the z-buffer, they will have to cut the compatibility with the software renderer. And I don't think this will happen anytime soon.
3. Hardware Accelerated Pixel Bender
Pixel Bender is already hardware accelerated pretty much everywhere except the Flash Platform. I'm not sure why. Still, it's hardware accelerated in other products of the Creative Suite so I guess that an OpenGL/Direct3D shader languages compliant intermediate represenation of Pixel Bender kernels does exist.
This said, it's just a matter of how to make it work with the very general purpose Flash Player. Considering Flash 10.1 is using tesselation, my guess is pixel shader should follow quite easily.
Apple makes its own compiler… illegal!
"3.3.1 … Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited)."
This is the very bad (sad) addition (restriction) to the iPhone developers program everyone is talking about right now. And I feel very concerned about this... and now everyone is wondering if software like the Flash-to-iPhone packager, Mono or Unity are definitely banned from the iPhone programming tool-chain.
I never talked about it before, but Aerys is working on a project targeting the iPhone and the iPad (among a lot of other platforms). And this very project is leveraged by some home-made code generation tool. Therefore, we are very scared of what this kind of restrictions might imply for our business.
But as scary as this statement might look at first, it is actually even funnier when you understand it makes any iPhone/iPad application illegal. And it gets even better because even Apple's standard tool-chain finds itself... prohibited!
The reason is very simple: Objective-C, C or C++ never "link" to any library providing the Documented iPhone APIs. Objective-C, C or C++ actually never link to anything. When compiling your code, the compiler creates an intermediary representation of your program in order to make it easier to (eventually cross-)compile it. In the case of GCC, the compiler used to build such applications, those intermediary languages are:
- the historical Register Transfer Language (RTL)
- the tree language GENERIC
- the SSA-based GIMPLE
(Source: Wikipedia - Intermediate language)
This very intermediate representation is built before the symbols resolution and before any linking is done. Thus, linking against the "Documented APIs" has always been done "through an intermediary translation or compatibility layer". And it won't change anytime soon! But, still, I wish good luck to Apple's engineers in their future work to patch GCC and make it "compliant" (sic!).
To me, it is the most obvious sign that Apple doesn't care about its developers (but I was still pretty thrilled to eventually become one of them about a few days ago...). Not because it bannishes any interesting cross-compiling software venture. And not even because any iPhone/iPad developper who knows about other platforms openness and ease of production will feel sick just by reading this kind of restrictions.
No. To me, Apple is losing it all simply because this kind of idiocy can only be written by someone who doesn't have a clue about how a computer/compiler works! Apple started building casual devices and ends up targeting casual developers. Could this be the first sign of how (so called) intuitiveness - when enforced by completely hermeticly closed devices - finally makes people... dumber? So now the real question is "What happens when your developers program EULA is written by a marketing control-freak moron?".
PS : The title of this article was desgined to attract the eye. It is my interpretation of the latest Apple's developers program EULA additions and I might be completely off or wrong. Anyway, the doubt and worry caused by this very fuzzy and unclear addition stands as a major issue for all the companies and developers targeting the iPhone and iPad platforms.
AS3 Monitor released on Google Code
I just released a small but useful piece of software on Google Code: my ActionScript 3.0 Monitor class. This little class makes it possible to watch the properties of any object directly on the stage.
It was inspired by Mr. Doob's Stats class. But my Monitor class is entirely dynamic and you can watch any property of any object.
The following simple (and useless?) code sample show how to track the (x, y) position of the mouse cursor on the stage:
package { import aerys.monitor.Monitor; import flash.display.Sprite; public class MonitorDemo extends Sprite { public function MonitorDemo() { var monitor : Monitor = new Monitor(30); monitor.watch(stage, "mouseX", 0xff0000, 1. / stage.stageWidth); monitor.watch(stage, "mouseY", 0x008800, 1. / stage.stageHeight); addChild(monitor); } } }
And here is the result:
Here is another simple use case: tracking the (x, y, z) rotation of a 3D camera (the actual application is available on the official Aerys website):
The code is open source and available on Google Code. Comments and suggestions would be greatly appreciated!
Build Flash 10.1 applications with Flex Builder 3 or Flash Builder 4
It was one of my first posts on this blog: Work with Flash 10 in Flex Builder 3. This post has proven to be very helpful and is still read a lot every day!
As Flash 10.1 is currently accessible in beta. I thought it would be nice to have some tutorial to build applications targeting this new version of the player to take advantage of the new APIs (like multitouch for example). This tutorial will provide a generic solution to enable the creation of Flash 10.1 capable projects in both Flex Builder 3 and Flash Builder 4.
Step 0: Download the latest Flex SDK
This step is not mandatory and should not be necessary if you already have a Flash 10 capable Flex SDK. Still, keeping your SDK up to date is always a good thing and this tutorial might be a good opportunity to do it!
As the Flex 4 SDK was just released a few days ago, I recommend you download, install and use it for the rest of the tutorial.
In the rest of the tutorial, $SDK_DIR will designate the path to the Flex SDK you want to use (ie. "C:\Program Files\Adobe\Flash Builder 4\sdks\4.0.0" for example).
Step 1: Download and install playerglobal.swc
- Go to $SDK_DIR\frameworks\libs\player and create a new folder called "10.1"
- Download the new Flash 10.1 capable playerglobals.swc library from Adobe Labs
- Extract playerglobals.swc from the downloaded ZIP file to the new "10.1" directory you just created
Step 2 : Setup your Flash 10.1 project
- Open Flash Builder 4
- Create a new Flash/Flex project or open the project you want to setup
- Open the properties of your project (right click on your project in the Package Explorer > Properties)
- If you are using Flash Builder 4, go to the "ActionScript compiler" panel and in the "Adobe Flash Player options" section, check "Use a specific version" and enter 10.1.0 as the version number
- If you are using Flex Builder 3, go to the "Flex compiler" panel and in the "Additional compiler arguments" text input add "-target-player=10.1.0"
- Click "OK"
Step 3 : Build your project
Press F11 to build and run your project. Everything should work fine and you should now be able to use the new Flash 10.1 APIs!
You can now create as much projects as you want and you just have to do Step 2 to make sure it will target Flash 10.1!
Speaking at the french Flash user group
... or at least that's the plan! The next meeting of the Tonton Flexers - the closest thing to a "french Flash user group" - is taking place the 23rd of this March and I'll be there to present my 3D library.
I would be more than happy to talk about the software, the way I built it and the technical choices that drove its development. I will also try to emphasize what makes this library different through a few demonstrations.
Depending on the agenda of one of my co-worker, we might also present a very cool piece of software I never spoke about!
You can read more about the event here (in french).
Google Maps 3D Overlay
The Flash Google Maps API offers what they call a 3D map. It's nothing more than a component that enables a perspective view of a classic 2D map with the associated controls. Here is how it works:
- The 3D view is engine independant and uses Flash 10 3D maths and "drawTriangles" method if available
- The API provides everything one needs to integrate 3D graphics as an overlay using the library of its choice
- It works just the same as the good old 2D Google Maps API
The first point is very important. It ensures the library is lightweight and does not include any third party software you wouldn't want to use.
The second is what makes the magic possible: the API exposes the viewport and camera data and provides methods to convert latitude/longitude into 3D world coordinates. With a little math and a few hours of debugging it is then easy to wrap it with the 3D engine of your choice.
The Experiment
You can use CTRL + mouse drag or SHIFT + mouse drag to look around.
The Code
You might want to read the official Google Maps Flash API documentation first, including the dedicated 3D maps section.
The Viewport
The Google Maps API provides the viewport width and height and the focal length. I use the field-of-view instead of the focal length but there is a simple formula to convert from one to the other:
var fieldOfView : Number = 2. * Math.atan(viewportWidth / (2. * focalLength));
Another issue is to find proper values for the near and far clipping planes. I chose 0.000001 for the near plane and 0.2 for the far plane. Those values are extremely low and might cause floating point inconsistencies. The best thing to do would be to scale the whole scene to be able to use reasonable clipping values. Maybe for a later version! This problem does not seem to affect the experiment though...
The following function presents how to get the relevant viewport values from the Google Maps API:
public function buildViewport(myMap : Map3D) : void { var g : TransformationGeometry = myMap.camera.getTransformationGeometry(); var width : Number = g.viewportSize.x; var height : Number = g.viewportSize.y; var fieldOfView : Number = 2. * Math.atan(g.viewportSize.y / (2. * g.focalLength)); // build viewport... }
The Camera
The following function retrieves the camera position and look-at vectors from the Google Maps API:
public function buildCamera(myMap : Map3D) : void { var cam : ICamera = myMap.camera; var mapCenter : Point = cam.latLngToWorld(cam.center); var g : TransformationGeometry = cam.getTransformationGeometry(); var pos : Point3D = g.cameraPosition; var zAxis : Point3D = g.cameraZAxis; var yaw : Number = cam.attitude.yaw * (Math.PI / 180.); var lookAt : Vector3D = new Vector3D(); var eye : Vector3D = new Vector3D(); eye.x = pos.x - 128; eye.y = pos.z; eye.z = 128 - pos.y; if (!zAxis.x && !zAxis.y) { lookAt.x = eye.x + EPSILON * Math.sin(yaw); lookAt.z = eye.z + EPSILON * Math.cos(yaw); } else { lookAt.x = eye.x - zAxis.x; lookAt.z = eye.z + zAxis.y; } lookAt.y = eye.y - zAxis.z; // build camera using eye position, look-at and Vector3D.Y_AXIS as the up vector }
I prefer computing the eye position and look-at vectors and using them to create the transform matrix rather than just creating the matrix directly. This way, you can expose the actual camera parameters (even if in read-only) and still use the transform matrix to do the math.
The Scene
The last step is to make it possible to position 3D objects on the map. What you actually want to do is to be able to add objects specifying their latitude/longitude instead of their actual (x, y, z) coordinates. Then again, the Google Maps API does it just fine:
public function computePosition(myLatitude : Number, myLongitude : Number) : Vector3D { var pos : Point = _map.camera.latLngToWorld(new LatLng(myLatitude, myLongitude)); return new Vector3D(pos.x - 128., 0., 128. - pos.y); }
Know Issues
As said previously, the extremely low far and near clipping plane values might introduce float point inconsistencies. Therefore, some clipping glitches might appear and frustum culling is performed only on the far clipping plane.
Credits
Credits goes to Marc Fahmi for the low-polygon 3D model of the Eiffel Tower.