[F8] scrollRect viewport, desaturation filter ??

[Q__Hybrid]

Hello again,

I am once again submitting my ideas before I get heavily trenched in dead-end development.

Is it more efficient to offset a scrollRect on a container clip than it is to move the entire container beneath a mask, or are they synonymous?
My levels will be layed out verbatum in a container, then the scrollRect will be translated according to player position. I hope to cut render time to a minimum by updating the viewport rectangle's location rather than updating the position of everything in the terrain.

As a side topic, is there a way to retain a more or less constant refresh rate despite changes in memory allocation?
I hope to set _visible to false for all clips that rest beyond a certain perimeter outside the boundary of the viewport's rectangle, such that the memory can be freed up temporarily until those elements are needed again. I don't want alot of speed-up and slow-down based on allocation changes.

How would I go about caching the viewport itself, or do I even need to?
I want to cache the viewport rectangle's visible contents during pause so nothing is being redrawn. If the engine is paused, redrawing should be forced to quit.

I'm curious if cached bitmaps can be rotated while preserving proper pixel orthography? In other words, will each "square" of a pixel be rotated per Flash's usual rotation technique or will it use a more "nearest neighbor" approach?

Last but not least, is there a way to parametrically desaturate a cached bitmap?
I want to make the frame of action in my viewport fade to grayscale during pause while the menus remain in color.

Thanks for your patience.

[Squize]

Wow, you're wordy mate.

So much to chose from here,

"Last but not least, is there a way to parametrically desaturate a cached bitmap?"

Yes, I've done exactly the same thing in a soon to be released game. You just use draw() to copy what you want to a new bitmap, grey it up, and then attach it to a mc over the main screen ( So the new bitmap covers your viewport ), and then increase the alpha on that mc ( You could just alter the colour values of the duplicate bitmap every frame, but I've got a feeling it's quicker to just increase the _alpha on a mc. Could be wrong, but feels better to me ).
So alpha starts at 0, and is then incremented.

"I hope to set _visible to false for all clips that rest beyond a certain perimeter outside the boundary of the viewport's rectangle"

If you're making a tile based game, look into using a gotoAndStop engine, it only used the mcs you need, so you don't have to turn _visible on/off on unseen mcs.

I'll let someone else cover the other stuff

Squize.

[mr_malee]

i agree with Dad on those points he mentioned.

as with your viewport. You cannot move the scrollRect and still want to see contents of your movieclip if the scrollRect leaves the dimenions of the Stage. The scrollRect should stay at 0, 0 and the contents should move (that is the point of scrollRect) defining a visible area of a large movieclip. But this causes the contents movieclip to be cached, so if anything moves inside it, bad news bettsy. The movie will drop frames quicker than my jokes.

i think cached bitmaps retain pixel orthography, unless they are not allowed to be smoothed (i could be wrong though)

basically i find the scrollRect usefull when applying filters to a large movieclip. In every case i've used it, it slows down the player unless its contents dont move.

And setting the _visible property of movieclips outside the stage is unnecessary, the renderer doesn't render them. Try it out and see, make 3000 gradient movieclips off stage. Move their parent movieclip around ("offstage") then bring it back on stage, you'll see the difference immediatly.

[Q__Hybrid]

"You cannot move the scrollRect and still want to see contents of your movieclip if the scrollRect leaves the dimenions of the Stage. The scrollRect should stay at 0, 0 and the contents should move"

I just performed a crude test that disproved this.
I don't fully understand scrollRect, but if you update the x and y properties of the rectangle instance you're using, then re-apply it to the scrollRect property of your container movieclip every frame, it can travel beyond the boundaries of the stage and still display the contents of the container. Interestingly enough, the displayed rectangle always snaps to 0,0 in the player.

As I said, I don't know all the internal workings of this method, so I'm almost entirely certain that there's a self-contained method of doing the same thing through some simple method such as offset() or offsetPoint(), etc.

Couldn't I just have everything animate within the container, then cache the container automatically by applying scrollRect per frame? All of my graphics are going to be cached, then animated using scrollRect. By that I mean I'm going to slide the rectangle through a grid of frames that are all on a single bitmap in order to simulate timeline frames.

You're saying the whole viewport approach is infeasible? Moving an entire container clip is actually faster than only moving the viewport rectangle? I need to push through a few more tests.

[mentuat]

further to mr_malee about scrollrect - it doesn't work the same way as a mask, trying showing redraw regions when testing with both. I have much more of an improvement using scrollrect and cacheAsBitmap as a 'view-port' than simply masking a container - paricularly when scaling large bitmaps.

you can turn smoothing on: in the properties of a bitmap in the library, when you bitmap.draw or set the document quality to _best (haven't used it myself as it's a bit of a hog). Be aware I'm pretty sure that applying a filter might remove smoothing but you could simply take a snapshot with draw and attachBitmap to switch it back on.

Keep track of bitmap.dispose and/or fillRect when creating/reusing bitmaps as memory usage can shoot up when dealing with large/many bitmaps and the garbage collector doesn't clean things up for you as well as you might expect.

I use something like this to desaturate:

	private static var r_lum:Number = 0.212671;
	private static var g_lum:Number = 0.715160;
	private static var b_lum:Number = 0.072169;
	
	
	// desaturate
	static public function desaturate(mc:MovieClip):Void{
		var aCol:Array = 
			[r_lum, g_lum, b_lum, 0, 0,
			r_lum, g_lum, b_lum, 0, 0,
			r_lum, g_lum, b_lum, 0, 0,
			0, 0, 0, 1, 0];
					
		mc.filters = [new ColorMatrixFilter(aCol)];
	}

combining it with a bitmap snapshot layer and deleting the filter is probably is a more economical way of fading it as squize mentioned. Works effectively for bluring too.

[Q__Hybrid]

Something I've noticed is that viewing movies that use scrollRect with the "Show All" option is a major problem in terms of framerate, but only if cacheAsBitmap is set to true. If it isn't set at all or is set to false, everything runs noticably faster.

Right now I'm using 63 fps with ten render cycles per frame using a for loop. So far, despite using a large bitmap with an alpha channel and a vector overlay, everything is blistering along at intense speed. I won't know how well things hold up until I build some assets and construct the first level test. That's a bit far away for now.

Thank you for the demonstration of the ColorMatrixFilter desaturation, mentuat. I appreciate code snips.

[mr_malee]

here's a littel test i did. I didn't realise you could move the scrollRect, but it makes sense now, because you have to reapply the rectangle to the movieclip. However the coordinates mess with my head, i was unable to get mouse movement working when using scrollRect, i couldn't use the parent's _xmouse and _ymouse because the rectangle would fly of into oblivion. The stage _xmouse and _ymouse seemed to work a little, the rectangle was offset at a weird position though. I didn't see a speed idfference from re-applying a scrollRect rather than moving the contents, so i guess go with what you know, for me thats the container method.

here's the test. Right click to see the different options.

http://img181.imageshack.us/my.php?i...fxspeedem9.swf

Stage {

parent { //scrollRect applied

container { //movement

circle1
circle2
circle3...

}
}
}

cache the container to see a big speed boost, notice that when the circles play this really slows the player.