Mask sheets

Solar2D Advanced Graphics
#1

I’ve been doing something analogous to sprite sheets, using mask textures, but obviously without engine support. This works well at certain scales, whereas with others I get cracks, much like a tiled map might have. I’m wondering if it’s possible to do this right, given more information.

The first question is more of a sanity-check (I’ve not had a lot of luck finding a “standard” example): assuming a scale of (1, 1), should a mask image have the same dimensions as its corresponding object, or those values plus the black pixel borders?

Secondly, what is the impetus behind the three black pixels on the border? Is this a common technique, or particular to Corona? (I ask, since I had little luck with Google here.) My best guess at the moment is that it simplifies some behavior outside the graphics card (fetching pixels for hit tests?), but I’d like to be sure.

My motivation is to apply marching squares to various tile-based things (so far, I use a “mask things out” approach, to carve paths, and “preserve these pixels” to smooth articulated shapes). The frames in the mask sheet correspond to the different contour lookup entries. Unfortunately, a lot of tile sizes are getting ruled out right now as cracks show up.  :frowning:

The current sheet logic is here (I called them “reels” because the output looked like film reels, but I’m warming up to mask sheet… reel won’t even make sense if they become 2D grids) and the marching squares generator is here (at present, there’s no interpolation, and the “obvious” way is a lot of work :P).

With respect to the second question in particular, do I also need three black pixels between “frames”, for correctness? Or is that meaningless, off-border? And if the former, is it fine that two side-by-side frames share the border?

Any help is appreciated. Thanks for reading!

#2

From my personal testing, keeping mask dimensions in powers of 2 is important, otherwise there will be bugs on certain devices. On the other hand, I haven’t encountered any erroneous behavior by ignoring the 3 black pixel rule. Hope someone from Corona Labs can fill in here.

It’s hard to tell, but as far as I can see the 3 pixels are included in the mask, i.e. if you apply a mask that is completely white except for a 3px black border, the image it’s applied to will have a 3 pixel border cut away. If this observation is correct, it means that if you want to include the border of your image, the image would either have to be slightly smaller than the mask, or the maskScale would have to be >1. But I haven’t tested this extensively, so it’s quite possible I’m mistaken.

Interesting idea, by the way, hope you get it figured out!

#3

Thanks _memo, and these “from my personal testing” and “It’s hard to tell” parts are why I’d like to get official word.  :smiley:

Incidentally, I’m going to set aside the marching squares approach for now (it was experimental), since I think it needs interpolation to not be ugly, and I’m unsure how to put some of my data into a form amenable to that. I do also have code I’ve been using to generate a bunch of carved versions of an image, with some steps taken to keep the number of possibilities reasonable, and I finally realized I could just generate masks instead… never occurred to me until this morning. :unsure:

Anyhow, this would still be a mask sheet. Some of the same techniques will probably get rolled back into a better marching squares down the road.

(Assuming Corona is doing normal OpenGL stuff, the mask “sheet” is an attempt to minimize texture switches, given lots of tiles. In the “mask things out” use case mentioned above, the tiles come from a 256-frame image sheet, so baking the masks into the tiles themselves won’t really be reasonable.)

#4

From my personal testing, keeping mask dimensions in powers of 2 is important, otherwise there will be bugs on certain devices. On the other hand, I haven’t encountered any erroneous behavior by ignoring the 3 black pixel rule. Hope someone from Corona Labs can fill in here.

It’s hard to tell, but as far as I can see the 3 pixels are included in the mask, i.e. if you apply a mask that is completely white except for a 3px black border, the image it’s applied to will have a 3 pixel border cut away. If this observation is correct, it means that if you want to include the border of your image, the image would either have to be slightly smaller than the mask, or the maskScale would have to be >1. But I haven’t tested this extensively, so it’s quite possible I’m mistaken.

Interesting idea, by the way, hope you get it figured out!

#5

Thanks _memo, and these “from my personal testing” and “It’s hard to tell” parts are why I’d like to get official word.  :smiley:

Incidentally, I’m going to set aside the marching squares approach for now (it was experimental), since I think it needs interpolation to not be ugly, and I’m unsure how to put some of my data into a form amenable to that. I do also have code I’ve been using to generate a bunch of carved versions of an image, with some steps taken to keep the number of possibilities reasonable, and I finally realized I could just generate masks instead… never occurred to me until this morning. :unsure:

Anyhow, this would still be a mask sheet. Some of the same techniques will probably get rolled back into a better marching squares down the road.

(Assuming Corona is doing normal OpenGL stuff, the mask “sheet” is an attempt to minimize texture switches, given lots of tiles. In the “mask things out” use case mentioned above, the tiles come from a 256-frame image sheet, so baking the masks into the tiles themselves won’t really be reasonable.)