Printable View
I spent the evening to see what I can get out of the new BitmapData handling and is suprised myself over the result with this 3 layer-platform-engine.
* 640x480x100fps
* 3 Layers:
- Static background (640x480)
- Scrolling wrapped background (640x480)
- Scrolling 256x256 map tiles with optimization (blocksize 64x64)
http://www.onemotion.com/flash8
My results 3Ghz/Intel GFX: 64 fps, 1-4% CPU
(check first that its 0% CPU before testing)
Nothing happens. I load a blank page.
same here...Quote:
Originally Posted by d3s_inc
Is that huge file?
I tested it before adding the post. You have Flash 8? It works fine here with IE.
Its ehm 4kb swf :D
it works great here!!
nice work erixon....I wonder when will flash 8 be realeased...
the potential is really great :-)
paul.
got it to work.. sorry, my FP8 was acting up on me.
Had to restart.
Hehe, i'm so dumb. I have'nt f8 plugin :DQuote:
Originally Posted by erixon
There was some kind of problem when updating, i remember now :p
Nice one! One thing I've noticed with a lot of swfs in fp8 is that high/low quality doesn't seem to have any/little impact on the fps. It was clearly the case in your example too.
In this case more or less everything is done on BitmapData level and just the output is attached in a movieclip. Otherwise quality have quite big impact because antialias take extra time. Pixel copying without varying alpha/fading and stuff is a lot faster. Flash 8 isn't fast on everything, but classic games gonna be nice to do.
Oh sorry, I missed the bitmapData stuff. So that's why!
Yep, cacheAsBitmap too should be great for tilesbased games.
65fps on amd 64 3ghz. Works pretty good.
Awesome! Nice work
It really looks like we're going to see larger game areas and faster scrolling in the near future! :cool:
Lapo
p.s. = I tested with similar hardware (3ghz P4) and got the same results...
erixon,
Is it possible to get an explanation of the technique you used? I haven't exactly been following the latest FP8 hax0r techniques, so if you can, don't assume I have knowledge of anything but FP7 and related performance hacks and tweaks.
Thanks much.
Instead of old Flash slow movieclip handling where it know all objects all the time you can copy/compose/scroll bitmap data with a lot faster speed.
I'm sorry, I don't quite understand. Bitmap datas are totally separate from movie clips? Like some sort of parallel display structure?
bitmapData is pixel storage in memory with some few fast functions and can be displayed in a movieclip or copied from a movieclip.
So.. copied from movie clip or displayed in one.. If it ends up going back to a movie clip, why is it suddenly faster?
nice example erixon =) i get constant 24 fps on 1.33 ghz box with 384 mb (ddr) ram.
from several tests with F8 stuff i noticed that it at least allows to achieve higher fps counts in the browser in case you have a faster machine (with more ram);on f7 content (/with f7 player) you were limited more regarding achieving really high fps in browser even with faster machines.
i´ve worked on a bmpData driven engine,too; as you know you can use bmpData.draw(clipInstanceName) to draw clip with instanceName as bmp into bmpData Object.
Do you know if you can pass linkageIdOfClipInLibrary as argument to bmpData.draw method?
I couldn´t get that to work (drawing bmpdata of clips in the lib into bmpData without attaching the clips to a timeline first) and thought its quite a bottleneck.
Would be way cooler to draw the bmpdata into bmpData Object without having to attach the clips first. (in terms of performance, aswell as ease of use and genral cheesyness ;) )
sand858: its the bitmap handling that is a lot faster before displaying, doing complex things you often end up with many movieclips otherwise, which scale/rotate/vectors etc and has not the speed as in just copy pixels. Its though a lost of simplicity sometimes.
Ah, so the general idea is you're combining more movie clips into a single one to speed things up, so the performance gains come from a fewer number of clips to manage?