Advertisement
Drakim

Pastebin letter to truefire

Oct 30th, 2011
329
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 2.69 KB | None | 0 0
  1.  
  2.  
  3. I resolved all the issues. The unbreakable wall has been broken and then some more.
  4.  
  5. 1. The reason the colors were all wrong was because of endian (which direction the bytes are being read). When I switched to little endian it worked just fine. It can copy 600x600 pixels from a ByteArray to a BitmapData in 6ms or so.
  6.  
  7. 2. Since flash.memory optcodes works against a ByteArray, you can still call the regular ByteArray methods. I've had great success using ByteArray.writeBytes to do what we talked about earlier, overwriting several bytes at once. Clearing a pixmap blank was a really expensive operation for me in the past (two nestled loops with a setI32) but now with a single writeBytes it can be done in a milisecond or two.
  8.  
  9. 3. I'm also using writeBytes as a sort of CopyPixels. It only works for one horizontal line at the time, but that means that on a 100x100 large image, you call 100 writeBytes rather than 10000 setI32. It's also showing great promise for drawRect. It seems to me that although ByteArrays have some really slow aspects, you can stay away from them and just use the fast methods.
  10.  
  11.  
  12. I've added a "flip" messurement separate from "render" so you can see how long time is spent on rendering the cogs and how long time is spent flipping the buffer. Right now I'm getting 10ms for the cogs, 8 of them scaled and spinning with transparency (you can see stuff behind them), and about 15ms for the flip action. The flip is a little more expensive than I would want but at least it doesn't grow as you keep adding cogs.
  13.  
  14. I've eliminated the possibility of BitmapData backends for Pixmaps entirely, it's now all in flash.memory. That means that a Pixmap can never be deleted once it's been constructed, but I feel that it's for the best. Doing this allows me to do some awesome optimizaions. I'll problaby make a slower separate class for temporary images.
  15.  
  16. The renderer is pretty much now at a usable level. If you made a full game in my renderer right now you'd get better performance than most timeline games at kong (especially the AS2 ones) but I don't think I have stuff like Flixel beaten just yet. But really, look at the demo linked bellow, the performance I have is fucking insane.
  17.  
  18. So, to sum up. The golden methods are these: flash.memory.setI32, flash.memory.getI32, ByteArray.writeBytes, bitmapData.setPixels. I recommend using them if you are making your own renderer (but you can see my code when it's done also). Oh, btw, I don't have anti alising on the cogwheels, I just changed the source image to pretty them up somewhat.
  19.  
  20. http://drakim.net/demo5/
  21.  
  22. Behold and weep. You said I should wait for Adobe to fix their shit :p, but I did it somehow. Now I need to go to bed and let my brain rest.
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement