For a project, I try to add some shading in textures in away3D lite. It basically works like a scanline renderer. My code was probably not the most optimized code possible, but it worked rather fast, that is about 200 or 300ms on a 512x512 texture. The bottleneck was clearly ByteArray access which are really slow (a function call at each access :( ). You could probably do something faster which Alchemy, but I doubt you can do anything 'usable' with scanline rendering in AS3.
As a matter of fact, as triangle is not hardware accelerated in Flash player, triangles are rendered with a scanline renderer. As good an AS3 implementation may be, I don't see how it could be faster than Adobe's native implementation ;) Pascal Revillet On 13 août, 18:37, Ken Railey <[email protected]> wrote: > So even assuming fill rate could be just as quick using the fast memory copy > from Alchemy, it still seems like the per pixel tests/writes will be a net > performance loss, potential depth buffer notwithstanding :) > > -Ken > > On Fri, Aug 13, 2010 at 11:15 AM, David Lenaerts > <[email protected]>wrote: > > > A custom rasterizer has most chances using Alchemy so you can access fast > > memory, and copy that from the ByteArray to BitmapData. That way, you could > > also create a software depth-buffer or G-buffer at acceptable-ish extra > > cost. It'd be an interesting exercise for sure, but I'm not entirely > > convinced it'd be more than that :) > > > On Fri, Aug 13, 2010 at 6:08 PM, Ken Railey <[email protected]> wrote: > > >> I don't see why this type of rasterizer would be inherently faster than > >> the current one. In most cases fill rate is the bottleneck, meaning that > >> you want to get your pixels onto the screen as fast as possible. I would > >> be > >> very surprised if someone can find a way to do this faster manually in as3 > >> bytecode one pixel at a time than by using the internal flash bitmap > >> drawing > >> routines (written in somewhat optimized assembly, IIRC), no matter the > >> window size. > > >> The window size is probably not even all that relevant, since *both* > >> methods get faster as the rending surface dimensions decrease. > > >> Of course, I would be pleased to be proven wrong :) > > >> -Ken > > >> On Fri, Aug 13, 2010 at 5:38 AM, Nooop <[email protected]> wrote: > > >>> On Aug 12, 10:18 am, Peter Kapelyan <[email protected]> wrote: > >>> > Sorry, what I meant to say is "you can try if you have the courage". > > >>> > From any other rendering methods thus far (experimental or not), there > >>> has > >>> > not been any increase in rendering speeds. There have been some tries > >>> with > >>> > Pixel Bender, I would love to see a PB solution that's even a tad bit > >>> > faster. > > >>> As I understand, scanline rendering would not be faster in a > >>> larger window, but in a very small window it could have a faster frame > >>> rate. I think it is limited by the number of pixel. > > >>> Quake Flash probably using scanline rendering with a good frame > >>> rate: > >>>http://www.silvergames.com/game/quake-flash/ > > >>> "Wire Engine 3d" has a scanline rendering option. > >>>http://www.3key.at/we3d/forum/ > > >>> 2600 polygon flat shaded model in a tiny window and a smooth > >>> frame rate: > >>>http://www.3key.at/we3d/w3sample.html > > >>> 15,000 triangles with scanline rendering: > >>>http://3key.at/we3d/forum/demos/demo1/index.html > > >>> Flat shaded helicopter model: > >>>http://3key.at/we3d/src/samples/1.html > > > -- > > David Lenaerts > > Flash platform developer > >http://www.derschmale.com
