[SHOW] DisplacementMapFilters!

I've squeezed out 1 more fps just by doing minor bits and bobs ( And yeah I wasn't go to play with it and finish my current nightmare project ).

I think putting the point objects into their own class will help quite a bit. The version I've got isn't a million miles away from this code, and I did it in there and it helped. So if the flex function is only called on data within the p object, then that can become a method of that and it'll save some look-ups.
Same with anything like that, any calculations which can be done within the point class. I know you get a cost calling the actual method, but it's less than a load of look-ups.

As to bitmap drawing, I'll be using dots rather than lines, which is quicker. As a test I altered mine to be 50 across, 40 down and each tile being 10x10px ( The same as yours ) and I was getting 50/60 fps, that's with a lot more maths going on ( Although I do use a flip flop for the plotting, so it's not every frame ).

I really want to hit this hard, damn proper work, damn you to hell.

Squize.

oooh nice. I am also doing proper work, when the "man" isn't looking i'll load er up ;)

Oops also forgot to say, the other perk of having a class with all the goodness in is that you get to data type it, so

private var px:Number;

Will be nice and quicker than

obj.px

Oh, and if your boss is giving you grief, just stand up and say "I go now", spit in his face and run out the room laughing like a big mental. Honestly, nothing bad will come of it, if anything he'll respect you all the more.

Squize.

haha, your forgetting the Delete button on the HDD :)

Malee, I've had a quick play with it. It's tightly coded.

If you double the cell width it runs at a silly speed.

So... how about cheating and plotting four squares instead of one, I can't get it to work, I don't have too much time unfortunately.

not sure i follow

wont those "fake" squares need maths performed on them too, or do you mean divide up the space between points (subdivide) and only draw lines to those points?

it may work, not sure how it'll look though.

I absolutely love playing with your example!

For example changing these lines (89, 90):
for(py = 0; py<gy; py++){
for(px = 0; px<gx; px++){

to:
for(py = 0; py<gy; py=py+2){
for(px = 0; px<gx; px=px+2){

makes it look like embossed squares. Ooo the fun to be had! You legends!

yeah, interpolate the points with fake points, so one square becomes four squares. Just interested to see how it'd look...

lets see what 1 hour can do before gym time :)

people I present success (well kinda) by subdividing and converting code into classes, well the numbers speak for themselves:

before subdivision and no class, cellW 10: 23 - 24

after subdivision and no class, cellW 20: 36 - 40

after subdivision and class, cellW 20: 46 - 58

and the results seem the same.

if you open up the source, open GridPoint and find the method "getCenter" you can see that its possible to use some bit shifting here, now i have tried it, bu the grid stays ever so slightly wobbly because of the conversion to int. So if someone can port a fast bitmap version then i'd say we could see 70fps on the board. Also, one of you could probably do a better job a subdividing too.

With no rendering i get a flat 120fps.

Without rendering (but still computing) subdivision, i get 85-90fps.

the sponge may be dry but it can be rung once more ;)

http://soap.com.au/chris/geom2

here's the source y'all

EDIT - you might notice that the effect is now inverted ;) change the power sign.

Wow, it's running pretty well now. Looks better than mine, and it's a lot closer to the original Geometry Wars effect. Mind if I use it in Polygon? :)

Excellent work.

Getting around 38/42 fps with the latest beta ( High 20's with the stinky old FP ).

If it weren't for debugging ghosts I'd be all over this like a free bar.

Squize.

PS. Anyone else having to use IE to view FK today ? That new header seems to be badly broken in FF.

thanks Squize and V

Squize, nah, looks ok to me.

V, do whatever you wish, but i'd say as soon as anything else enters that stage you'll be catching the express to chug town.

Wow..

That works better than I thought.... I had to look really carefully to see that the cells were doubled up.

you might even get away with 30px cells and dividing into 3 squares...

Though I don't understand how dividing it up into classes speeds it up?

I'm gonna have another play with the code tonight. Another optimisation idea I had was to alter the resolution for the more active parts of the grid dynamically... so the cells are 100 - 50 px for the slow moving parts of the grid, and more detailed for the more active parts of the grid.

Not sure if that's even feasable, it may take too much processing to be worth doing.

Quote:

---

Originally Posted by lesli_felix

Wow..
Though I don't understand how dividing it up into classes speeds it up?

---

I'd like to know this too.

Great work mr_malee! I'm gonna see if the rasterized version turns out faster. Oddly enough it runs slower in the standalone player than before but runs faster in the browser. How do you check to see that its faster? Do you publish it every time? Guys OOP always prevails, one way or the other! Hail king OOP. :p

Quote:

---

Originally Posted by Cortana

Though I don't understand how dividing it up into classes speeds it up?.

---

Quote:

---

Originally Posted by Cortana

I'd like to know this too.

---

I haven't looked at either code, but my guess is that one implementation uses parallel arrays of Numbers, and the other uses a single array of classes:

// Code 1
var x_array : Array;
var y_array : Array;
var dx_array : Array;
var dy_array : Array;
for i=1:N
x_array[i] += dx_array[i];
y_array[i] += dy_array[i];

// Code 2
class Point {
var x,y,dx,dy : Number; f
function update() :void { x+=dx; y+=dy }
}
var pointArray : Array;
for i=1:N
var p : Point = pointArray[i];
p.update();

I think the latter is faster because it only performs one array lookup [] per point update, instead of 4. That lookup operation is probably slower than the . access operator (which is implicit in the update function, this.x += this.dx, etc).

I'd like to know the whole story myself.

Well if anyone's interested here is the raster version: http://www.devkiwi.com/project/geowars/gridV4.html
Source: http://www.devkiwi.com/project/geowars/V4.zip
If there would be a way to clear only the affected areas that would probably improve the speed but currently there is no speed improvement. And I wasn't able to stop the cage from shaking. It's probably due to the fact that the raster fields are defined as int.

Runs about 15 fps faster for me.

Malee’s version gets an average of about 50 fps, yours about 65. Im sure you could fix the shaking by setting values to 0 if they are below a certain number?

Ali

At the top of the page I made a couple of posts about why using a class for an object is quicker.

"If there would be a way to clear only the affected areas"

I was thinking of playing with getColorBounds. If you're using the bitmap line code I posted on the blog you'll notice there are special cases for straight lines.
What I was planning on trying is altering the colour slightly when it's not a straight line and then using getColorBounds on that colour to return the size of the changed rect., which would be the size to use the fillRect on.

Squize.