Hey Revalis the last, fully backwards-compatible version of the fp10 trunk will be the update labeled 3.5.2 in the svn. We will make a tag of it soon so that people in the middle of production can upgrade to a point, without fearing any errors creeping in. as we move towards a fully native api however, it is inevitable that syntax will change slightly. In these cases, the overall speed benefits justify the move, and we hope that in any future projects, using the latest trunk from the start shoudl be a very familiar process
cheers Rob On Wed, Sep 22, 2010 at 9:09 PM, Fabrice3D <[email protected]> wrote: > Number3D to Vector3D is the most work. Updating projects made with versions > previous to 3.4, might ask more attention if animation > or extrusions are involved, but mostly it comes down to correct imports and > rename a few vars. Hovercam, Path classes are examples of these var names > changes. > > For the cases of N3d to V3d , such as add, substract etc, you indeed need > to rethink few lines. > Good news is that not only you get in speed for now, but getting used to > Vector3d will simplify your work in general. > Rob took great care at minimizing the impact on existing projects. > That's one of the reason Number3D is still here today for instance. But > it's already more or less obsolete, and you should try remove as much N3d as > you can. > > Dunno if applicable with your Matrix3dUtils calls, but I've added optional > Vector3D params in that class to prevent get a new Vector3D each time you > call it. > So trick is simple, you declare once a Vector3D holder and pass it to the > class methods over and over, only it's values are altered. No Vector3D > passed results in a new instance. > Meaning here that if its called often you should apply this construction. > If we encounter more cases where its required, we will add similar > solutions. > > Doc will also be updated soon. > > Fabrice > > On Sep 22, 2010, at 5:33 PM, Revalis wrote: > > > Just an fyi, and I'll probably post on transmote's page as well, but > > pulling the latest version of a3d killed all of my AR projects. :( > > > > Looks like it's because AwayMatrix3D has gone away and the > > Matrix3DUtils handles its variables differently. FLARManager makes > > calls to AwayMatrix3D in 2 different classes, and simply exchanging > > the class names doesn't handle correcting the issue... so it may need > > to be updated for the latest a3d version. > > > > Figured I'd post here in case anyone had caught it earlier and found a > > way to work around it. :) > > -- Rob Bateman Flash Development & Consultancy [email protected] www.infiniteturtles.co.uk www.away3d.com
