Flash Player v9.0.60.184
It seems that with the r60.184 version the vertical bar thing went away, anyway still remains that very new singularity ;)
Noticeable difference
I haven’t had much time to test things out, but i managed to put together an ultra simple example on how 9.0.47 and 9.0.60.120 perform differently. This is the original image i’ve used to setup things:
Flash Player v9.0.60.120 issues
I’m trying to get a clue of that vertical bar and it just seems very closely related to how the BitmapData’s draw() method internally works: for instance, if you have the source at hand, at line 67 of the PostProcessor.as file there is the line:
ppbmpData.draw( source, new Matrix( .5, 0, 0, .5 ), null, BlendMode.NORMAL );
The ppMatrix is the precomputed transformation matrix and, by changing that with the following, the bar will go away and it won’t crash the VM anymore:
ppbmpData.draw( source, new Matrix( .501, 0, 0, .501 ), null, BlendMode.NORMAL );
Since i do not think a mere transformation operation can be SO wrong, i’m trying to extrapolate the smallest context into which the problem can be reproduced: so far i also noticed i can get very different results between Flash Player v9.0.47 and v9.0.60.120 by changing the code in order to produce a predictable result.
In other words, i got the expected result in v9.0.47 but only the top-most output_height / 2 portion is correct in v9.0.60.120: i’m not sure if that can be related to multi-threaded optimizations in the Flash Player since by changing the process’ affinity mask seems to affect framerate and flickering only… bah! I have to dig some more…
Carpet’s sources
Here is the source code for the Magic Carpet demo, just unpack it in your project directory of choice and import the project in Flex Builder, making sure to resolve the dependancies as it makes use of the following packages:
- PaperVision3D in its head revision;
- ASWing in its 1.0 A3 Flex compiler release;
- APE in its v0.45 alpha release (provided w/ modifications);
Let me explain the modifications in APE: i just wanted the engine to perform the timestep in a fixed fashion, so i initially modified it to accept a value, expressed in Hz, that represents the integrator’s timestep to be used, this way no matter if different machines have different framerates, animating will be the same everywhere.
Read more
The Magic Carpet
>> Looking for the source code? Just go the next post here<<
I managed to have some time to put together the simulation i was talking about last week: roughly based on a “Flade” (now APE) demo of that time, it makes use of APE for the physics and Papervision3D for the rasterization process.
Actually, using PV3D for merely rasterizing polygons its obviously an ugly solution if you, like me, don’t need all the scene management and just need to stretch bitmaps around: the real reason behind that choice is simply i was curious to see (1) how PV3D performed in a similar situation and (2) how to be able to bind APE and PV3D together.
Anyway, just modelling and simulating the carpet wasn’t enough: the motion were great and performing quite well, but it was lacking completely the sense and taste of realism one would expect from such a scene and the particular type of motion one can interact with.
I started by adding a (really) fake shadow that i’m too lazy to change and, since then, i liked the idea and adding a reflection was the next logical step for that context: it was still lacking some motion “feeling” so i also tried to mimic a directional blur simply by programmatically reducing the amount of blur on the slowest x-y direction.