Yup, very possible. Although not really if you're doing it on a per-object basis (one real-time distortion you can just about pull off, but several will slow it down).
Printable View
Yup, very possible. Although not really if you're doing it on a per-object basis (one real-time distortion you can just about pull off, but several will slow it down).
AS3 looks cool and I know you have to do it for all the speed but I really don't like the idea of sprite sheeting a whole arrows rotation. I preferred the simple days when good old _rotation was all you needed ;)
What do you mean by a per-object basis? I was thinking of stamping all the sprites onto the big bmp with copypixel(), and then apllying filters to the big bmp. Rinse and repeat. That shouldn't be That much more processor intensive.Quote:
Originally Posted by VENGEANCE MX
You could always prerender a spritesheet, by using draw() and a transformation matrix. The function is quite re-usable, and can probably also be used to prerender several alpha values.Quote:
Originally Posted by tidenburg
I got a prototype here: but it uses a movieclip to attach a bitmapdata.
http://home.planet.nl/~bogaa096/Starfight/PrerenderBeta.swf
TOdorus, it could be done like that (that's what I had in mind when saying it was possible).
Again, spritesheets could be pre-rendered, but using a transformation matrix to rotate what were originally vectors? No thank you. Granted, you could just use draw() on a movieclip, rotating it several times, but I feel more happy working with spritesheets.
Admittedly, it does start to get out-of-hand when your spritesheets end up looking like this:
http://www.birchlabs.co.uk/InfTeam1.png
;)
Would gladly make spritesheets manually for every troop, but my computer slows down working with so many vectors on-screen (about 10 seconds between my input and any on-screen feedback. Madness).
Aah, my situation was creating a tool for an artist, so he could just create a png, and immediatly see how it would look ingame. No vectors at all.Quote:
Originally Posted by VENGEANCE MX
@ V:
I havent looked through your last iteration of your copypixels() engine yet, but I think you're using scrollrect or something similar to just show one frame of your sprite sheet at the time as it flies through the air.....if that's the case, and say I wanted to use a the bitmapdata.hitTest method between an arrow and another object (say soldiers or whatever)....that wouldnt work, would it?.....
because the bmpdata.hitTest method would actually test against the entire bmp spritesheet, not just the one frame of the arrow that's shown when the game is running...am I right?.....just curious how one could use the bmp hitTest method w/ your setup, since it is actually using the whole spritesheet bmp even though showing one frame....if I understand it correctly...
hope I was clear in what I was saying....
paul..
With the scrollRect engine, I think hitTests would work fine (haven't checked, though); I remember checking the width of a scrollRect'ed sprite and it returned the width of the sprite rather than the spritesheet.
With copyPixels(), however, one of the main speed boosts is that there is only one DisplayObject used. As such, the individual arrows don't have any width or height properties; you have to add those yourself. hitTest wouldn't work, you'd need to write your own coordinate-based collision detection.
Using hittest is bad in any case, your collision detection should be independent from screen graphics.
I am making a game that requires 500 plus simultaneous objects, and I had been going nuts trying to figure out how to make the game run fast enough.
I had tried so many things...
1) obviously...separate layered symbols.
2) bmp.draw mothod of separate symbols to one layer.
3) bmp.draw mothod of a single symbol stamp for all symbols.
etc etc. I found no method significantly faster than the original layered symbols, and nothing that was faster than or as fast as 30 frames a second for 500+ overlapping clips.
I tried 32 bit pngs, 8 bit pngs, symbols,... you name it. I did tests on the draw size vs the bmp size(which was interesting because a 16x16 png drew exactly as fast as a 128x128 png at 1/8 scale) etc. ect. I found no way to speed up my game.
That was until I found this thread and the wonder that is the copyPixels method. My test program which displayed 800 semi-overlapping animated symbols across a 600x300 region went from 5 fps to 66fps, and my game in worst-case-scenario mode (max objects/ creatures) went from 10fps to 30fps.
Right on target ;)
Thanks to all for being smart.
Hah, that's what the forum is for. There are other great posts people have created that might give you even more speed. Look for some of VengenceMX's posts for more.
I had missed this thread too. As far as I'm concerned, this will save me a lot of time. Thanks so much to all contributors.