cutting irregular pieces from image for puzzle game

[dunbarx]

I assume the number of images is one. The number of controls supported on a single card is "unlimited".

If anything is pertinent in this discussion, it ought to be the time it takes to scan an image. As per my hardToRead pseudo recipe, an image might be covered by a couple of dozen polygon, freeform or other graphics. Each of those would be filled with those pesky tiny square graphics, likely many thousands in total, depending on the image size.

Craig

[dunbarx]

This silly though fun exercise was started because it seemed that there is no way to set the "pattern" of a graphic to the portion of an image that it overlies. Such a gadget is not present in LC, perhaps not anywhere. Taking multiple screenshots would work, but doing so is tedious and limited to rectangles.

A stack could easily be developed that could thereafter be used as a tool for any image. One would have to draw the puzzle "pieces" by hand. But then a single handler could name those pieces, duplicate them and then fill the duplicates with tiny square graphics, each with their backColor set to the mouseColor of the pixel being scanned. Group the pieces with their child tiny graphics and you end up with perfect puzzle pieces of the image.

I believe the method will work. You only need one stack. How badly does anyone want such a tool?

Craig

[rcmills]

Group each duplicate graphic along with its child pixel graphics. Put them together or take them apart, you can build a perfect copy of the original image.

Perhaps both?

[rcmills]

As an amatuer, I'm doing it for fun, and hopefully to please (impress?) my wife, who is tired of the endless ads on the puzzle apps available on the App Store

[rcmills]

So, is there no way to remove (turn transparent) portions of an image, pixel by pixel?

In my attempt in the app I attached several replies ago, looking at the imageData of the image, it seems that the zeros I put in the first of the four bytes (the alpha channel) for each pixel immediately return to 255 on their own, although the tImageData container keeps the zeroes. Does that make sense?

[dunbarx]

Hi.

I don't really know what can be achieved by processing the imageData. There are many here far more knowledgable on that topic than I. If one could do so, constrained by the outlines of the hand-drawn graphics, then that might be a much simpler way forward. I do not know how one would describe the regions of interest, that is, the graphics that together enclose the image.

What is missing is a way to capture the pixels underlying a prescribed area of the screen. Everything I proposed was due to the lack of that capability.That is what led me to exploit the "mouseColor" a property of any given pixel provided the hop spot of the cursor overlies it. Scanning the image, and knowing when the cursor is within the rect of each graphic.

AND JUST NOW I realized that a freeform, or any hand-drawn graphic is bounded by a rectangle that encloses that shape. This kills the idea. I do remember a discussion about this, though, where a way to capture only the "interior" portion of a graphic was possible. I will try to find that, unless someone here remembers.

Otherwise, sorry, my idea will not work at all, apart from using rectangles.

Craig

[dunbarx]

I checked back, and do not see any way to isolate the interior of a graphic that ignores the enclosing rectangle.

Rats. Again, without that ability, everything I proposed is unobtanium.

Craig

[bn]

So, is there no way to remove (turn transparent) portions of an image, pixel by pixel?

In my attempt in the app I attached several replies ago, looking at the imageData of the image, it seems that the zeros I put in the first of the four bytes (the alpha channel) for each pixel immediately return to 255 on their own, although the tImageData container keeps the zeroes. Does that make sense?

The first byte of imageData is the so called alpha byte in ARGB as LC uses it. However it does not control the transparency in LC.

There are 2 "datas" in addition to imageData of an image in LC.

1. MaskData.
Maskdata is one byte per pixel (as opposed to 4 bytes for imageData). That byte is either numToByte(0) for transparent or numToByte(255) for opaque.
MaskData transparency is on or off.

2. AlphaData.
Alphadata is also one byte per pixel and has the fullrange of values from numToByte(0) to numToByte(255) to control transparency of a pixel for the full range of transparencies.

You could set up the alphaData of an image by creating a binary variable using (width of image * height of image) bytes that you vary between numToByte(0) to numToByte(255).
Then you set the alphaData of an image to your variable with the binary data to see the effect.

Code: Select all

set the alphaData of image "myImage" to tMyAlphaData

Kind regards
Bernd

[dunbarx]

Bernd and possibly others may find a way forward using imageData.

But I like finding ways backward.

There is a way to use the drawn-graphic ("puzzle piece") method I proposed. The only change is that once all the hand-drawn "pieces" are finalized, the scanning process can start, but with each piece placed into its position not all at once, but rather one at a time. This requires as many scans as there are pieces, but in each iteration, since only one "piece" is under scrutiny, the enclosing rectangle can be ignored in the following way:

The opaque property of, say, a freeForm graphic overlying the image is set, and its backColor is set to a particular RGB value, say "0.255.255". The scanning process proceeds as before over the entire image. Whenever it encounters a mouseColor of that value, it hides that graphic and records the mouseColor of the pixel on the underlying image. This sets the corresponding backColor of the associated tiny graphic on the duplicate. The freeform is shown again, and the next pixel is scanned. Tedious for the computer, but that is why we love them.

Back in business; the overlap issue goes away. The scanning process will take longer is all.

HA. I am SO tempted to build this...

Craig

[dunbarx]

AHA, it is possible to scan only once. Just set the opaque and backColor of all puzzle pieces to known values, as in the screenshot attached. Each piece has to have a unique RGB.

The really hard part would be drawing the adjacent shapes reasonably accurately, not creating the handler that does all the work.

Craig

Screenshot 2025-06-19 at 3.15.54 PM.png.zip

(24.56 KiB) Downloaded 123 times

[Klaus]

Craig,

no need to ZIP images, just attach them to your posting!
This eliminates the need to download and unzip them before being able to see them.


Best

Klaus

[dunbarx]

Klaus.

OK, did not know that.

Craig

[dunbarx]

rcmills.

Are you intrigued enough to try to build this? I am an amateur as well, and would be happy to work with you all the way, but this has to be your project.

This assumes that the line of inquiry using the imagedata does not pan out. I am not sure how that would work, but Bernd is pretty handy with this sort of thing.

Craig

[rcmills]

Thanks so much, Craig! Yes, I am up to my elbows in the app already, and would appreciate all the help I can get

The puzzle pieces are already designed by the app, using the points in polygon graphics (Grok helped me with that), and the UI of dragging the pieces and checking for positioning too.

How can I share my app with you?

[rcmills]

1. MaskData.
Maskdata is one byte per pixel (as opposed to 4 bytes for imageData). That byte is either numToByte(0) for transparent or numToByte(255) for opaque.
MaskData transparency is on or off

Thanks again, Bernd. That works! It does what I was trying to do with the alphaData.

I think I’m (hopefully) reaching the last lap of the race, now