[SHOW] DisplacementMapFilters!

[Xploder]

alillm, that is odd it runs just about the same speed for me... but then I'm using Opera.

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.

Interesting I'll check that out... in the mean time I uploaded http://www.devkiwi.com/project/geowars/gridV4.html with your raster function and that added 1fps for me

[mr_malee]

awesome work Xploder, at work the last version I posted gets 85fps, your raster version gets 90-100fps, but work computer is a beast and I'm using the new player update.

As to the class question, Squize pointed it out. Classes give you the ability to data type its properties, whereas objects dont. Or i was just doing it wrong. See:

var x:Number = 10;
var y:int = 20;

var ob = {}

ob.x = x;
ob.y = y;

see here, not sure but I'd say that the data type is lost. Whereas in a class it stays.

rachil, i wasn't using arrays for the numbers, just objects, but i guess its kinda the same. All in all, OOP is better in this case.

[mr_malee]

change grid size to 200x100 and cellW 5.



scaled up a little: http://soap.com.au/chris/geom3/gridV3.html

[Xploder]

oh my god... you won't believe the next update... there is currently a slight problem but its a 10fps gain if it works out... that is in the browser. In standalone its a 20fps increase.

[Xploder]

I promised I would wow you. Well how does 80fps instead of 60fps sound? Well, now it seems feasable At least on my 2GHz core 2 duo laptop where as before it was barely 60fps. I further optimized Squize's line drawing routine. Namely using fillrect instead for horizontal/vertical lines. And for one instance using const. I will release source tomorrow morning. Today its way too late... enjoy: http://www.devkiwi.com/project/geowars/dontbelieve.html

[mr_malee]

lovely

the wobbyl grid is still there, but i'm sure its fixable somehow. Oh and I get 116 - 120fps fps now

go team

[Squize]

"Namely using fillrect instead for horizontal/vertical lines"

Fantastic, never even entered my head. That's one of those great ideas that you wish you'd thought of ( Well, Xploder, you did mate ).

Squize.

[mr_malee]

I still wanna try to stop the maths on stopped points, could add the wobble fix in there as well.

Still busy Squize

[T1ger]

"Namely using fillrect instead for horizontal/vertical lines"

Not to sound cheesy or anything, but I actually thought about that last night lying in bed.. (Yes, I dream about flash)

I suppose you dont use any sin or cos to rotate the rectangle? You just make the ends flat right?

[Squize]

Always busy mate, although I am playing with a certain grid effect atm.

T1ger, excellent idea too then

Squize.

[Squize]

This is the best I've been able to manage:

http://blog.gamingyourway.com/conten...y/GWars_v3.swf

Lot's of cheats in there, and I'm not overly happy with it, but it shouldn't be too far away from that in the game itself.
I guess in terms of benchmarks I'm kinda out of it now, 'cause I'm going off on a slight tangent to make it viable in a game rather than as eye-candy.

More later, I've really got to get some work done.

Squize.

[mr_malee]

nice. Do i see trails? or am i just really tired. Its good to see 120fps on the board and still see the effect.

anyway, hopefully tomorrow Exploder will share his great raster code and we can combine this:

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

its a version with some culling still using the DrawingAPI, Its easy to find if i point needs to stop calculating but the thing is the rendering doesn't change so it may/may not be worth it. I think its faster than before but not by much.

[Xploder]

Another slight improvement: http://www.devkiwi.com/project/geowars/gridV5.html
Souce:
http://www.devkiwi.com/project/geowars/V5.zip
Enjoy!

[Xploder]

Being rushed to release the code early to give everyone a good glance I wasn't able to properly respond to all your comment. So here it goes

lovely
the wobbyl grid is still there, but i'm sure its fixable somehow. Oh and I get 116 - 120fps fps now

Thanks Everyone! I didn't get around to worrying about the wobbyl grid. Wow 116 - 120fps you must have some beast of a machine

go team

Together strong we could make the ultimate flash game. But then again you're all probably too busy.

"Namely using fillrect instead for horizontal/vertical lines"

Fantastic, never even entered my head. That's one of those great ideas that you wish you'd thought of ( Well, Xploder, you did mate ).

Squize.

Hey, thanks a lot that means a lot coming from you

I actually thought about that last night lying in bed.. (Yes, I dream about flash)

I suppose you dont use any sin or cos to rotate the rectangle? You just make the ends flat right?

I've noticed the best ideas come at night after some intense coding. The fillrect is just a one pixel wide rectangle.
It was actually surprising to find that it works quicker though. Because behind the scenes flash has to render each pixel anyway. Which leads me to believe that setPixel32 is just a 1x1 fillrect and a for loop of fillrect would take more time than just fillrect.
And... thanks for the rotation idea... as I'm not using fillrect for slanted lines. I'll check if using matrix tranformations for slanted drawn by fillrect will improve the speed. The other solution is to reduce the for loop on the slanted lines by using segments of fillrect.

http://blog.gamingyourway.com/conten...y/GWars_v3.swf

Its looking quite nice. I'm getting a 100fps average.

anyway, hopefully tomorrow Xploder will share his great raster code and we can combine this:

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

its a version with some culling still using the DrawingAPI, Its easy to find if i point needs to stop calculating but the thing is the rendering doesn't change so it may/may not be worth it. I think its faster than before but not by much.

Can't wait to see the result! Next Goal 90fps on my lappy.

[VENGEANCE MX]

Xploder, did I just hear 'setPixel32'? Change any setPixel32 calls to setPixel in the Raster.as file... I have a hunch it could be faster. ^_^

[Squize]

Funnily enough that's twice I've read that today ( Tom posted the same thing on the blog ).

It's true, but I left it in there 'cause without it you can't have a transparent bitmap, which means no background. Fine in this example, but a bit limiting.

Squize.

[Xploder]

Xploder, did I just hear 'setPixel32'? Change any setPixel32 calls to setPixel in the Raster.as file... I have a hunch it could be faster. ^_^

Oh... I did check to see if it is faster but it turned out to be about the same speed. Unless if it changes inside the browser. Didn't check it there.

[Squize]

I've let the side down a little in this thread, so here's a bit of an update to the raster line plotter.
It assumes you're running it from the GridPoint class, so it doesn't need that point's x/y passing to it as it's already there.

//-------------------------------------------------------------------------
          private function quickLine(x1:int,y1:int):void{
		var i:int;
		var cumul:int;
		var x0:int=x;
		var y0:int=y;

		var dxL:int= x1 - x0;
		var dyL:int= y1 - y0;
		var xinc:int = ( dxL > 0 ) ? 1 : -1;
		var yinc:int = ( dyL > 0 ) ? 1 : -1;

		dxL = (dxL ^ (dxL >> 31)) - (dxL >> 31);	//Math.abs
		dyL = (dyL ^ (dyL >> 31)) - (dyL >> 31);
		var c:Number=0xDD073C89;

//Test for a straight vertical line
		if(dxL==0){
			bitmap.fillRect(new Rectangle(x0,y0,1,dyL),c)
			return;
		}
//Horizontal line ?
		if(dyL==0){
			bitmap.fillRect(new Rectangle(x0,y0,dxL,1),c)
			return;
		}

//Neither of the above, so let's check which is the major axis and do our thing
		if ( dxL > dyL ){
			i = cumul = dxL >> 1;
			var x2:int=x1;
			while(--i>-1){
				x0 += xinc;
				x2 -= xinc;
				cumul += dyL;
				if (cumul >= dxL){
		  			cumul -= dxL;
		  			y0 += yinc;
					y1 -= yinc;
				}
				bitmap.setPixel32(x0,y0,c);
				bitmap.setPixel32(x2,y1,c);
			}
		}else{
			i = cumul = dyL >> 1;
			var y2:int=y1;
			while(--i>-1){
				y0 += yinc;
				y2 -= yinc;
				cumul += dxL;
				if ( cumul >= dyL ){
		  			cumul -= dyL;
		  			x0 += xinc ;
		  			x1 -= xinc ;
				}
				bitmap.setPixel32(x0,y0,c);
				bitmap.setPixel32(x1,y2,c);
			}
		}
	}

Bascially the improvement ( Aside from some very minor cosmetics ) is due to plotting from both ends of the line, so it meets in the middle. This in turn halves the number of times we have to run the loop, which is cool 'cause a conditional in a loop is just nasty.

I've not tested it to death, so it may not always draw a perfect line, but it's working pretty well in the grid ( Oh and Xploder I've not checked your last build mate, so there may be some cross over. Feel free to merge them up to make one beautiful method ).

Squize.

[rachil0]

dxL = (dxL ^ (dxL >> 31)) - (dxL >> 31); //Math.abs

Never seen that before... it can't possibly be faster than conditional assignment, can it?

dxL = (dxL < 0) ? -dxL : dxL

[mr_malee]

noice, got some free time so i'll do some cutting and pasting and we'll see what happens