[SHOW] DisplacementMapFilters!

[Squize]

rachil, yeah it is, I got it from here:
http://lab.polygonal.de/2007/05/10/b...-integer-math/

I can't even pretend that I could work something like that out myself ( btw, lot's of excellent little speed ups on that page ).

I've realised I've got 2 vars defined in the above code I don't need, but I've got another cheeky special case test that I want to try out, and if it works I'll post the whole thing again ( Out of interest, the y2 and x2 vars don't need defining, it can just use y1/x1 ).

Squize.

[Xploder]

Squize, you didn't take into account that a 'width of a rectangle cannot be negative ' taken directly out of my source code commenting This tormented me for a while but I don't think it makes a huge difference in terms of speed. Otherwise the other part inserted into my code seems to make it 1fps slower . And about that part... maybe its better to post it here as a question my comment was:
// TO DO: See if there is any way to check when a few pixels
// in a row need to be drawn and use fillRect thus further reducing the for loop.
// Or: Check to see if a Matrix transformation works better to rotate the fillRect if that's possible.

[Squize]

Sorry mate, like I said, I've not had chance to look at your last version, this was just built on the version I posted on the blog.

The rectangle used in the fill can't be negative though can it ? The width is converted to a positive before the fill occurs and because it's only ever used on straight lines then the starting points will always be less or equal to the end points.
I should check your code out, 'cause I'm missing the point there somewhere.

Also surprised it's running slower when the loops are halved. That's very weird, loop unrolling should always be quicker.

Squize.

[Xploder]

The width cannot be negative so the lines that should go to the left will go to the right. Same for the vertical lines. Maybe if that is changed in mr_malee's grid plotting...

[Squize]

I tried dropping my line plotter into your code, and I see what you mean, it did break.
I've not used any of M's math optimisations yet, so that's why I'm not getting any negative widths ( I guess ).

I think this is me done with the line plotter, maths next.

		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;
			} else {
//Horizontal line ?
				if(dyL==0){
					bitmap.fillRect(new Rectangle(x0,y0,dxL,1),c)
					return;
				} else {
//Vertical line with just one step ?			
					if(dxL==1){
						var halfHeight:int=dyL>>1;
						bitmap.fillRect(new Rectangle(x0,y0,1,halfHeight),c);
						bitmap.fillRect(new Rectangle(x1,y1-halfHeight,1,halfHeight),c);
						return;
					} else {
//Horizontal line with just one step ?			
						if(dyL==1){
							var halfWidth:int=dxL>>1;
							bitmap.fillRect(new Rectangle(x0,y0,halfWidth,1),c);
							bitmap.fillRect(new Rectangle(x1-halfWidth,y1,halfWidth,1),c);
							return;
						}					
					}
				}
			}
			
//None of the above, so let's check which is the major axis and do our thing
			if ( dxL > dyL ){
				i = cumul = dxL >> 1;
				while(--i>-1){
					x0 += xinc;
					x1 -= xinc;
					cumul += dyL;
					if (cumul >= dxL){
			  			cumul -= dxL;
			  			y0 += yinc;
						y1 -= yinc;
					}
					bitmap.setPixel32(x0,y0,c);
					bitmap.setPixel32(x1,y1,c);
				}
			}else{
				i = cumul = dyL >> 1;
				while(--i>-1){
					y0 += yinc;
					y1 -= yinc;
					cumul += dxL;
					if ( cumul >= dyL ){
			  			cumul -= dyL;
			  			x0 += xinc ;
			  			x1 -= xinc ;
					}
					bitmap.setPixel32(x0,y0,c);
					bitmap.setPixel32(x1,y1,c);
				}
			}
		}

The two new "special case" checks may seem overkill, but in the example they happen a fair bit.
I think from here the only things I can think of is some tests for diagonal lines, and ordering the conditionals differently ( So the normal line plotter routines are tested first, then if it's not one of them try the special cases ).

Squize.

[Captain_404]

I'm gonna drop in here really quick just to say, this is some really great work you guys are doing and here's my clunky, slow attempt at the same kind of thing in AS2 (use the scroll wheel to change force...you may need to click to get the focus)

I'm jealous of all you people and your CS3...

[VENGEANCE MX]

Captain, does that use Clumping by any chance?

If not, I think it might be worth giving this a go

http://www.krazydad.com/bestiary/bestiary_clumping.html

[Captain_404]

It doesn't...right now it's very poorly optimized, there's an onEnterFrame for each of those little dots calculating it's particular force in relation solely to the current position of the mouse and then applying that force to it's acceleration.

But I'll look into that, thanks for the link.

[Xploder]

Hey, I think I came up with another raster optimization approach. It involves precalculating all the possible angles of lines and storing them into a bitmap or it could just load a spritesheet for a set line size. I'll check that possibility out further tomorrow.

[mr_malee]

Xploder, I've tried that already and it seemed to run slower than the drawingAPI version, but you might have better luck.

[realMakc]

there were no updates using displacement map since page 3, so I thought I will jump in, just for fun... clicky (~300kb no preloader)

[realMakc]

...btw, there seem to be relevant threads here aleady (like this one)

[realMakc]

I hit another beer and changed it to support multiple ripples:



that kills FPS if you click it too much

[realMakc]

that kills FPS if you click it too much

not any more

[mr_malee]

very nice.

[Xploder]

Xploder, I've tried that already and it seemed to run slower than the drawingAPI version, but you might have better luck.

Ok, I see... that's unfurtunate can't say that I won't try anyway though
Does anyone know wheater there actually is an improvement if BitmapData.lock() and BitmapData.unlock() is used? I cannot tell wheather there's a difference or not. What is its use anyway?

[VENGEANCE MX]

Found a general graphical speed boost in AS3 which I don't think has been mentioned on FK before... the opaqueBackground property.

Basically, it goes hand-in-hand with cacheAsBitmap. It's faster to cache bitmaps without using an alpha channel, so setting the movie clip's opaqueBackground to a colour value means that it will drop the alpha channel and use a colour instead. Obviously this is only really applicable for alpha backgrounds in front of a flat colour, and in a lot of cases you'll need the alpha channel (parallax, for example). Still, worth knowing.