Printable View
Speed is proportional to how far apart the two animations are (the filter covers both animations and all pixels in between). Try it with both on top of each other. For version 5, I'll be making it calculate whether it'll be faster to render both object separately or together (all depends on how big the overlap is). Should speed it up a lot in the more extreme cases.Quote:
Originally Posted by Squize
Great work VENGEANCE MX! This is very interesting stuff you've dug into and its really fast.
Are these different form the ones I'm using?Quote:
Originally Posted by Squize
graphics.drawCircle(x, y, z);
graphics.beginFill();
graphics.endfill();
and others... Would this be a solution to an extremely fast drawing routine istead of those that I'm using? Squize if you could please provide a link or a demo of it in action that would be great.
Sorry for this turning into a slight hijack V, at least it's the same subject :)
Xploder I posted links to both the current demo, and the line drawing code on the last page.
I've been playing with it more, and the raster based approach is actually quite a lot slower than the drawingAPI version, which came as a bit of a surprise.
In saying that, I've altered the lines to dots, 4 pixels apart ( I thought I should actually look to see how GWars looks rather than doing it from memory ) and the raster version is much, much quicker than using the dashTo prototype ( Which uses the drawing API, it's on adobe's site somewhere if you're interested, it's what I used in the dot vector demo in my sig ).
So if you want to draw lines which need to be cleared every frame, stick with the normal way of doing it. If you need dotted lines, or don't need the lines removing, then use the raster version ( The full version of which is at http://www.bytearray.org/?p=67 ).
Squize.
<hijack>Ah, I see. Must of missed that link. So when it's about drawing Quads and Circles its best to stick with the drawingAPI. Thanks for the explanation.</hijack>
VENGEANCE MX, it's running at 45fps pretty constantly with the spinny thingy. Without it, it was at 60fps and above.
Now, there're so many more game ideas poping up with the use DisplacementMapFilters. Who needs 3D... when you can create an interesting game in 2D... 3D will be a piece of cake.
I hearts my hijack tag
Xploder, the speed drop (as I said) is because the bigger the displacement channel is, the more pixels need to be processed. You'll probably find that the framerate decreases as you move the cursor further away from the spinning line... because the channel will be bigger. It's a rectangle that encompasses both animations, so it'll get bigger if they're further apart (bigger = more processing, of course).
Tomorrow (because tonight I'm watching Heroes :) ) I'm going to further minimize the area which has to be processed, so that in the event of two objects being far away from each other, the pixels in between them will be ignored. If they're overlapping significantly, they'll be combined into one channel, whereas if they're separated enough, they'll be processed separately.
Yes, lots of games could use this effect (would love to see some, and once I've made the final optimization, I'll comment it again and release it), but while we're getting pretty decent framerates with it, you'd still have to be careful what you do alongside it.
Squize, dots sound like they'd look better anyway... the lines at the center of the ripple seemed to get kinda tangled.
Whoa! cool.
I was about to say I had a similar idea last year then noticed the gridwarp example I built. I'd totally forgot that I shared it... my memory must be going.
http://board.flashkit.com/board/showthread.php?t=688299
I'm glad you managed to improve it.. I actually had a similar thing in mind when I built it (a very cool looking g-wars style background) but I gave up in the end. The biggest barrier being that in g-wars the grid can warp so much that it folds over itself. I had an idea that setting multiple displacement maps might get over that... but I was wrong.
Squize, that example looks a lot closer to the technique actually used in the game, but IIRC it wasn't something that could be done fast enough in flash. Each of the points in the grid has it's own gravity and repulsion and affects every other point on the grid... Bit-101 did some experiments a while back using this principle, but with only a couple of hundred points.
I think it might be more feasable in as3 though.
Good work.
Ah, was wondering who made the original file. :)
Alright, I'll start work on the final optimization now...
Oh, btw, I made a mistake when I said that GridDisplacement4.swf was the faster version... 3 is actually the fast one, I made 4 to see how much faster 3 was. :p
lesli, yeah the original effect is really complicated, it's like a material texture effect, with ripping and warping. Looks so stunning.
This is what I finished with last night,
http://blog.gamingyourway.com/conten...y/GWars_v2.swf
Squize.
That looks very cool.
I'm still not clear on how you're doing that, you're not using a displacement filter?....just plotting a distortion for each point from variables?
I'm gonna have to have another go at this I think.
http://www.birchlabs.co.uk/GridDisplacement5.swf
This is REALLY hard to explain, so bear with me.
Version 5's optimization stems from further culling the area that has to be displaced. If we have two objects, we would originally be drawing a rectangle that encompasses both objects, and using that as our filter. However, if the objects are significantly far apart, this rectangle will become very big, with lots of grey pixels between the two objects. This means big slowdown. So in the event that they become that far apart, we use two separate displacement filters (one for each object) rather than one that encompasses both.
Here's how the 'close' routine works (ie, if the size of the encompassing rectangle would be smaller than the sum of the two objects' areas):
Make a new BitmapData (coloured #808080, the 'neutral' displacement colour), big enough to encompass both objects.
copyPixels() both animations onto it (they have alpha channels, so they'll mix rather than overlapping).
Displace the grid by this BitmapData.
Here's how the 'separate' routine works (used when the encompassing rectangle would be bigger than the sum of the two objects' areas):
Imprint both animations onto neutral grey backgrounds, this time without any alpha channel (strictly speaking I do this as part of the pre-rendering loop)
Displace the grid twice (once for each BitmapData).
All in all, it turned out to be a lot more hassle than it was worth. I only see a significant speed boost when the objects are _very_ far apart (as in, a couple of hundred pixels off-screen far apart, and realistically we wouldn't plot them in this situation anyway). However, it does mean that if we get several objects on opposite sides of the screen, we won't need to waste time plotting the area in the middle of the stage.
Next (and I'm assuming final) step is to make the engine support multiple objects more gracefully... currently it's kinda hard-coded, lots of copying and pasting. I need to put some loops and functions in there instead.
Good work V :)
I'd like to see your approach adapted to work with damage maps, which would give blitted displays a nice boost ( So the display would be double buffered in code, and only the damaged / dirty areas on each of the two pages would need updating. It would cut down the number of pixels which would need plotting ).
Squize.
:( 'fraid I've never heard of a damage map, can you elaborate?
It's a way of storing what has changed between frames.
Say you have a static background. When you go to blit a sprite on it, you store the original background away ( ie, a rectangle the size of your sprite ), and then plot the sprite. When you then have to move the sprite, you delete it by replacing it with the original image ( From your damage map, an array pointing to the stored away bitmaps ) and so on.
With the advent of everything being plotted into one bitmap rather than using Flash's own sprites / layers / etc. it may be quicker, you won't be plotting every pixel every time.
It's how things used to be done in the good ol' Amiga days. I don't know how relevant it is to Flash, but it could be worth playing with.
Squize.
Very clever... I think the speed boost in this case would be so fractional that it wouldn't matter (copyPixels() is hella fast, it's the displacement filter that's causing any slowdown).
In terms of the blitting tests... might be worth a look. :) Pretty worn out from coding at the moment, might try it later today, but maybe not.
http://www.birchlabs.co.uk/Invasion5DM.swf
^ Proof that damage maps don't help in Flash. Although admittedly it was probably foreseeable that 7,000+ extra copyPixels() calls and a pool of 7,000+ BitmapDatas would be slower than a single fillRect() call.
Here's the fillRect() version, for comparison:
http://www.birchlabs.co.uk/Invasion5CP.swf
"admittedly it was probably foreseeable..."
It was just a theory I was putting forward blue. If I put 20 ideas forward, law of averages say that 1 of them will be quite good :)
I guess your sprites are all in 1 sprite bitmap, ie the background is in it's own, so you can just run a fillRect to clear it. I'm still confident that if it was all in 1 bitmap you'd get a saving ( Although not 100% confident ;) ).
Nice work in trying it though.
Squize.
have any of you tried simply manipulating the grid without a displacement map. Just using a loop and maths
http://www.sebleedelisle.com/?p=76
I used to have some source files on a magnetic grid/wobbly grid, i reckon with AS3 you could just use that. I'll see if i can find it
nice work though
:) Actually I don't think that's the problem. The main issue is that the arrows are PACKED together (one pixel apart, each with a 13x13 boundary box), so many of the sprites will be clearing a region that's already been covered.
Let's assume we have about 7,000 arrows at all times. 7,000*13*13 = 1,183,000. That's more than 4 times the area of the stage, 700*400 = 280,000 pixels.
Now let's assume that we have one twentieth the number of arrows, so they're no longer packed together 1 pixel apart, and we don't get so much overlap... 350*13 = 4,550. That's significantly less than the stage area!
So, I guess what I'm saying is... it might save us some speed if the sprites don't overlap so much. However, you've got to consider that there's an extra copyPixels() routine being performed per sprite per frame. Might negate the speed boost given by ditching the fillRect().
However, I doubt we even lose much fps from doing a single 700x400 fillRect() per frame. Might be a different story if everything was all in one bitmap (wouldn't do that anyway, though. I like having layers :P), then we'd be doing a 700x400 copyPixels() per frame, but these tests have proven that copyPixels() is at least fairly fast. :)
In conclusion, I guess the reason damage mapping worked well in old games is that there weren't as many sprites being chucked around. There was a much higher proportion of the screen which didn't need to be redrawn and, crucially, there weren't loads of sprites packed together so that the same parts of the map would needlessly get plotted multiple times.
Had a quick go at making a psychedelic effect with the DisplacementMapFilter test (for fun, and for a friend who asked me to). If anyone in the vicinity is vulnerable to seizures, it's probably best not to click the link (doubt it'll do any harm, though):
http://www.birchlabs.co.uk/ForDuncan.swf
Enjoy. :)
how about experimenting with google earth images :p,
or skin photos ._. - like a game where you need to destroy all the insects that move under the skin of a hand before they take over he body
hehe, that reminds me of a doco i saw, some heroin addict thought that there were little mice running around under his skin and he kept trying to scratch them out. Wasn't pretty
anyway...