Jump to content


Circular blitmask?

Moderator Tag

Recommended Posts

Hello ... again.


I read about the blitmask now, and it is (mostly) clear to me, that and why it's a rectangular sprite.


Now...I am pretty sure, that it is possible to create a Bitmap Data object, that is built a little bit differently. I am not good enough to do it in AS though, and so I just like to discuss my idea with you guys.


So, my theory is that the bitmap data object is a bit like a matrix filled with pixeldata. If there was a circular algorithm built in, one could - row after row - check out the needed pixels (opaque), and the ones we dont need (transparent) and thus build a circular blitmask.


The same would then even work with elliptical shapes - divisionwise...on one of the x or y axis. Yeah...you know what I mean, eh?


Well..yeah. That's it for now.


Are you on that already? Is there some error in my idea? Is it already achievable with some of your great stuff? Is it silly implementing what AS3 can do (well...you do that all the time dont you? ;) )


Let me know..I'm pretty darn curious.




EDIT: I rethought and...is it a good thing to mask the blit-masked MC with a cirular shape. It doesnt seem that clean actually, hmm.....but the "normal" mask only masks a single and shrunk Bitmap then, and it could be performant. But I still think, that this is a rather dirty workaround, right?

Link to comment
Share on other sites

Sure, it's possible to walk through a BitmapData pixel-by-pixel and manipulate each one (toggling them to transparent, for example, to make whatever shape we want). The challenge is doing so in a way that performs really well. The whole concept behind BlitMask is to speed things up. It's pretty simple (and FAST) to tell Flash to take a rectangular section of pixels from one BitmapData and dump them into another one. However, if we start having to walk through millions of individual pixels and toggle each one on EVERY frame (which is what would have to happen during animation), it gets much...MUCH slower. In that case, you'd probably be better off just using a regular circular mask rather than trying to do fancy stuff with BitmapData objects.


See what I mean?


You certainly could wrap your BlitMask and its target inside another Sprite and mask that container Sprite with a circle (a standard mask). I suspect that would indeed be faster than merely masking the original target with a circle because Flash doesn't have to worry about as many overspill pixels when it's calculating the mask.

Link to comment
Share on other sites

Yes. I understand you. But my feeling told me that there is a way to just require the circular matrix calculation once.


Like I said, I am not that deep into your classes or even as3, as I am more of a designer. I just think of creating kind of an object that gets "prepared" to only get the necessary data. Like an array, that doesnt have the possibility to receive data to certain indices, not because they were blocked, rather because they just dont exist, and thus dont need to be checked in every frame.


I checked out arduino and processing lately and maybe thats why I think that way. You got a setup and then a loop where stuff is being executed.


Even IF I get the point that bitmapData needs to be drawn every frame, I nevertheless dont understand why my thought is maybe wrong. Thats why I will try to look deeper into BitmapData when I got time. I am no TOTAL noob, so... Its just a feeling that it must work somehow.

Link to comment
Share on other sites

Sure, we'd love to hear back from you if you discover a way to very quickly copy pixels from one BitmapData into another in non-rectangular ways that match the current performance of BlitMask. That'd be fantastic.

Link to comment
Share on other sites



I was moving too fast without proper knowledge (esp. about matrices). I'm now getting closer to your point. My brain formed another question, though.


I need to know, if I get the way you are doing things here. Let's take blitmask without the updating option for this example.


Creating the BitmapData would only be needed once, correct?

You then cache the pixel data and give the possibility to move/scale it by using the matrix transformation rules/data, still correct?

If I am right until here, what if you just "die-cut" the former final BitmapData with a circular algorithm once, too? Right after. Then you cache THAT object, and leave everything else as is.


Would that be a good approach for a well performing way?


EDIT: Maybe one could create another reference BitmapObject with pixels shaping a circle in it and only 2 kinds of pixels. Like I said before, some transparent, some not. (Or black/white, or whatever is fastest to query). Then one could create a temporary array of all rows of pixels, check out in a loop which ones are interesting, and then plot the new BitmapData object. That change in my idea is only important, if the cicular algorithm takes longer than this operation.


The most important thing to keep up performace is to kill the repetition of this process in every frame, right? My feeling that this could work somehow still doesnt die.


Gimme hope, Joanna.

Link to comment
Share on other sites

It doesn't bother me at all that you're asking this stuff, just to be clear.


None of the approaches you described sound to me like they'd work well in terms of performance, no. You can't "die-cut" the original BitmapData because the whole point is that the image should be able to move inside the masked area, thus the transparent pixels would constantly be shifting.


Any time you have to loop through each pixel, it's gonna really hurt performance. BitmapData's copyPixels() is very fast, partially because it doesn't have to think much - it just grabs a bunch of rows/columns of pixels from one BitmapData and dumps them into the other without having to think about each pixel or run a matrix transformation, etc.


If you're able to put together a solution that works really fast and allows circular (or custom shaped) masks, definitely let us know. I'd love to see it.

Link to comment
Share on other sites

Okay. Cool.


You use 3 parameters in the copyPixels() function:

_bd.copyPixels(bd, _sliceRect, _destPoint);


I really only glanced through some info quickly, but the optional fourth param "alphaBitmapData" seems to be very interesting. Can you eliminate my thought, or could that be a progress?


I need to sleep, it's 2 am. I'll post you some conclusions tomorrow, hopefully.


Good night.

Link to comment
Share on other sites

It's just not as fast as a straight copyPixels().


Okay, but that doesn't mean "slow" already, does it? If an irregular shape can be used for a lot faster masking operation than the flash internal masking does, there still was achieved a little optimization.


I will try something out today. I want to play a bit with the shape masking of a blitmasked MovieClip/Bitmap. As we discussed before, this could already be a lot faster than only using flash's masking. Even if this is not exactly what I initially wanted, I need to move on with my game and this could be very helpful already.


But I will stick to this over the holidays.

Link to comment
Share on other sites

Well, I seem to be at the point of no further possible progression. My feeling still survives after the brainmelting holidays, but I think the problem lies too deep in memory processing and bitshifting/copying the pixels. So whatever, my knowledge isnt sufficient at this point of time, which you probably agree with ;)


But to achieve any progression at all, I used your blitmask and afterwards set the mask property of it to a circle shape. In my first example I used a 3000x3000px png and had a wonderful performance, BUT my PC is equipped quite well, so I'll check it on a lame machine soon.


...I still believe.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.