[SHOW] DisplacementMapFilters!

mmmmmm, liquid grid - http://soap.com.au/chris/geom/gridV2.html

damn those loops. I know it runs bad, 28fps here, but it just looks so juicy.

V, if you can pull an effect like this off with displacement maps, then you're the best.

http://www.birchlabs.co.uk/ForMalee.swf

:)

Press space to toggle the displacement channel overlay. You'll notice how when the ripples all clump together, it gets pretty grainy. 'Fraid I can't do anything about that.

And you call 28 fps BAD? I'm getting less than 5 fps on it IN THE STANDALONE PLAYER.

The beauty of using the displacement map is that you can keep experimenting with different ways of drawing the map. Adding a blur is a great way of keeping it smooth, but there's plenty else you can do.

malee... that grid looks awesome. Something tells me it can be optimised a lot.. the resting framerate doesn't seem much lower than when it's all over the place.

get a PC dude :D

yeah, its bad, nothing really much you can do. It needs loops, it needs maths on every iteration and it needs to draw. Can't go faster than a while loop. Maths can't be optimized any further (to my knowledge) and bitmap rendering is slower than DAPI.

while yours performs nicely, I'm not feeling the love with the effect :( have you tried two channels for displacement?

edit - I might be able to decrease the amount of lines drawn if i flag a point as drawn, or simply draw points to the right and below of the current point. Atm its going back, so you see lines with new positions and lines with old positions, meaning needless rendering.

Mr M, that's the money shot mate, looks excellent ( Only 13fps here though ).

Tell us how it works so I can steal it.

Squize.

Yeah, but it seems to be doing a lot even when it's resting....

Surely you can skip code and drawing for resting grid lines?

Squize, nothing special at all, maths is from liquid journey :D, I think you know them too. Dont have the source here now, its at work, if you can hold on for 13hrs then I'll post er up.

Lesli, yeah thought of that, but in order to do so, i have to run the maths anyway to figure out if it needs resting, then perform more to check if it is. Turns out its worse to do that. But hey, maybe you can have a crack.

its not in anyway elegant:

define grid width and height (small)
define a scale value
draw into movie clip
scale movie clip up
scale forces down
add points into a 2D and 1D array
find adjacent points to all points using 2D array
loop over all points in 1D array
run maths
loop over connections of current point
draw all connections

so like i said before, i think i can eliminate some of the drawing if i make it draw only right and down.

EDIT - actually i could be wrong about the maths, if i store the magnitude of the velocity after the points update then check that velocity next iteration, if its small enough i could stop it. To re-init a point, all i have to do is check whether the distance from the mouse is less than the required to move it. Hopefully ;)

Arse, either I didn't download the best example on there, or you've just made it a lot better :)

It's hard to compare speed wise with the version I've got up and running 'cause you've got a load more squares ( All mine are 24x24, 26 across, 18 down ).
I was all ready to stop working on this, at the end of the day it's just background eye-candy, but seeing your example has inspired me again.

Squize.

yep, even without the rendering, just pure maths and loops, with a target fps of 120, you get about 40fps, so yeah the grid size is a big factor.

I'll post the source tomorrow, then the optimization battle can begin :D

It's a date :)

Squize.

Quote:

---

Originally Posted by Squize

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.

---

Sorry to go off topic...

Talk like this (pixel by pixel manipulation) in flash makes me wonder why devs don't just move on to other languages when they want to do this kind of thing. Is it the enjoyment of pushing flash as far as it can go? I can certainly appreciate the enjoyment of a challenge.

As an authoring environment, I went to flash for my first game because of the ease of using movieclips and not having to worry about things like blitting and damage maps and such.

I applaud all the super cool work that is being done, but am curious what remains to draw higher level programmers to flash and not going off and using C++ or something instead.

Is it because you can run it in a browser? Are people too lazy these days to download and install a new game? I honestly think they just might be.

Quote:

---

Originally Posted by Alluvian

Is it because you can run it in a browser? Are people too lazy these days to download and install a new game? I honestly think they just might be.

---

In the past month, I've used six different machines. One was a mac, one was my pc at home, of the remaining four, I didn't have sufficient user rights on two of them to install software.

This is why people use web applications.

For me, it's nice to try and push Flash, and with F8/9 there's all these new toys to play with, it'd be rude not to have a bit of a fiddle under the hood.

As to why Flash and not C++, Flash is a level playing field. Anyone visiting FK could make the best game ever made in Flash. You'd be hard pressed to say the same about most other environments. It's very restrictiveness is it's strength.

Perhaps we should go back to the subject, poor V's thread has been pushed and pulled away from him quite badly.

Squize.

The latest one is looking nice, VENGEANCE MX... runs at 30fps.

Quote:

---

Originally Posted by mr_malee

I'll post the source tomorrow, then the optimization battle can begin

---

Oh boy, I can't wait! WWE DisplacementMapFilters vs. PureMath. Wednesday, Wednesday, Wednesday!
Squize, I think you should put in a word for that hijack tag.

Whatever you do, don't right-click -> Zoom in. FPS goes to < 9.

Quote:

---

Originally Posted by ImprisonedPride

Whatever you do, don't right-click -> Zoom in. FPS goes to < 9.

---

[offtopic=verymuch] Thanks for the tip my browser esplode. [/offtopic]

tada

already took the liberty of doing the gfx optimization i talked about, only draws Max two lines for every point, much better :)

If someone's got maths skills, please be my guest

here's the preview, i get 45fps, when before i got around 28fps :D

http://soap.com.au/chris/geom/gridV2.html

file is attached (CS3) format, if you need F8 let me know

EDIT -also took out the scaling, was just a silly thing which did absolutely nothing

It's always on-topic in my book if it's about making things run faster. :)

Hmmm there isn't a lot of room for loop optimisation there. It's got a lot less going on than the maths I've got running in mine ( And looks better ).

Hopefully tomorrow I'll have time to play a little with it, pulling an all nighter atm.

Squize.

ouch. Yeah, i dont see anything else apart from maybe the maths. I dont see how i could use bitmapData for the lines, as it requires more loops to draw them.