unsafe casts don't generate extra code. Safe casts generate an extra Std.is test (which is totally uncessary on avm2, btw) But it shouldn't matter much anyway :)
2010/11/7 [email protected] <[email protected]> > Cauê > > I used a lot of casts in the patch, are they efficient, or did you replace > with better? > > Cheers > > ;j > On 7 Nov 2010, at 20:18, Cauê Waneck wrote: > > Hey Justin! > > I've applied all the patches! Thanks for that. I've now rebuilt all swfs, > and they are jsut fine now in 2.06. But I don't think I will change the code > to support flash namespaces. Flash namespaces are slower than the way haXe > does it, and we don't have to rely on untyped code (so it's safer this way). > Also requiring to run an injector after build is also messy by itself. > > Thanks! > Caue > > 2010/11/7 [email protected] <[email protected]> > >> Cauê and Michael >> >> Re: Namespace injection. >> >> For the moment to get the namespace changes working I had to add lots of >> untyped (Franco told me it would allow the compiler to skip checking on the >> privates accessing so it seemed a quick temporary fix till a better approach >> was found), but I have commented where these were added by putting comments >> in the xml injection file. I am sure there is a better solution but Jan was >> not around for me to pick his mind and the IRC channel seemed quiet or >> atleast no one smart was offering ideas. >> >> I know the injection file is doing something because it throws a runtime >> error, so I had to comment some of the namespace out, (but I was not using >> Sprite3D)... >> <class name="away3dlite.sprites.Sprite3D"> >> <member name="index" ns="arcane"/> >> <!--member name="indices" ns="arcane"/--> >> <!--<member name="uvtData" ns="arcane"/>--> >> </class> >> as it was having problems in Renderer, line 217 >> _triangles = new GraphicsTrianglePath(); >> _ind = _triangles.indices = new Vector<Int>(); >> _vert = _triangles.vertices = new Vector<Float>(); >> _uvt = _triangles.uvtData = new Vector<Float>(); >> it complained about trying to create arcane on GraphicsTrianglePath so >> maybe the namespace injection code needs more work?? >> >> >> Now the trouble is that the code that I have now modified works fine >> without the injection or the arcane class!!!... so I am really questioning >> if away3dlite haXe version even needs namespaces... surely its an overhead >> that is just unnecessary from my naive perspective? >> >> Anyway the proposed away3dlite haxe code with the injection xml file I >> have uploaded to... >> >> http://www.justinfront.net/away/away3dlite.zip >> >> Jan Flanders injection file I have uploaded >> >> http://www.justinfront.net/away/namespaceInjector.n.zip >> >> Sorry they are zips, but I figured I am noisy enough for you to know and >> trust me :), well I know Rob (I always ask him silly questions at LPUG :) ) >> and Cauê is also on my fb. >> >> For injection you need to add this line in your hxml compile file like >> so... >> -cmd neko namespaceInjector away3dlite/inject.xml main.swf new_main.swf >> >> The injection code Jan has made is super smart but I guess this is the >> biggest test and we may need to decompile some exampes to check its working >> fully as we expect. >> >> Note while I have been testing with a fairly complex awaylite example >> which threw up loads of compile errors initially there could be classes in >> away3dlite haxe that still need mods for others specific projects to work >> correctly, ie happy to try and help test it more if we establish this is the >> right direction, and also decide what to do about the untyped. My feeling >> is that the haXe version should move towards not using namespaces, but if it >> does need namespace maybe injection is a better approach then simulated >> namespace. >> >> If the haxe community are concentrating on just away rather than sandy, I >> would like to see hsl or similar and bsp collision make it into the haxe >> build, I am sure that could be implemented on the current version while Caue >> works on molehill, well I need bsp collision anyway. >> >> Cheers >> >> ;j >> >> >> > >
