cutting irregular pieces from image for puzzle game

[richmond62]

The FIRST thing anyone needs to do BEFORE setting out to design something like this is work out the quickest, easiest, and most effective way to do things.

As the designer of some 90 EFL (English as a Foreign Language) programs for children (7-15 years) I have found that the actual programming with LiveCode is only about 10% of the 'sweat': 90% being layout and what the thing looks like.

That jigsaw example I have supplied took about 90 minutes preparing the puzzle pieces and about 20 minutes programming the actual stack.

[richmond62]

Wow! Cowabunga!

https://puzzel.org/en/jigsaw/build?menu=content

[rcmills]

Yes, I agree about the PNG images. I don’t care what the container is, so long as they can be moved around.

As I am coding just for fun, though, I was after an app that I could drop an image into and have the app make me a puzzle, without spending time in a commercial app to prepare it.

[richmond62]

Well that website I reffed in my previous post does exactly that for you: although it offers no coding challenge, so as far as I am concerned, it is rather boring.

[richmond62]

https://jigsaw-maker.en.softonic.com/

[rcmills]

Thanks, Richmond!

Unfortunately I am a Mac user. And I only code in LC, so...I'll keep looking and trying out any technique I can find

[richmond62]

Well: I used GIMP on an Intel Mac running macOS12.

That jigsaw thing for Windows runs perfectly on my Intel Mac running macOS 15 with WINE.

My main 'problem' is that there seems to be lots of bits of software on offer that will chop pictures up into puzzle pieces: but that's about as far as things go, as none of them seem to be able to export those pieces as individual images.

As a basically lazy person I would have opted for one, had I found one, instead of the fairly tedious procedure I adopted with GIMP.

[rcmills]

tmp.jpg (24.53 KiB) Viewed 4522 times

I have been able to copy a portion of the image data with the following code, but haven't yet accounted for the tabs and voids for the puzzle piece sides. More problematic though, is that the image (the small square below the bigger image (copied from under the puzzle piece overlying the lower portion of the swimming pool) has these severe lines running horizontally through it, apparently from some problem with the color channels. Any idea how to overcome this?

Code: Select all

put 0 into mSwitch
   put 0 into n
   
   repeat with i = 1 to mHeight  -- tHeight
      repeat with j = 1 to mWidth  -- tWidth
         
         put j + item 1 of tL into x
         put i + item 2 of tL into y
         set the loc of graphic "pointer" to x,y
         
         put x - item 1 of tlPic into x1
         put y - item 2 of tlPic into y1
         
         -- Each pixel is represented by 32 bits (4 bytes) of image data
         put ((y1 - 1) * tWidth + x1 - 1) * 4 into tPixelNum
         put byte tPixelNum to tPixelNum+3 of tImageData into byte n to n+3 of newImageData
         
         add 4 to n
         set the imageData of image "newImage" to newImageData
         
         set the cursor to busy
      end repeat -- j
   end repeat -- i
   set the imageData of image "newImage" to newImageData

[bn]

Hi rcmills,

I append a stack that gets part of an image and puts it into a smaller image.

Have a look.

Kind regards
Bernd

[rcmills]

That's super, Bernd! Thanks so much!

Regards,
rcmills

[rcmills]

OK, so I used Berns's method, and got the image cut up into the rectangles approximating my piece sizes. Obviously, that doesn't get the irregular shapes I need. I figured I could use the alpha channel or byte number one of each pixel of the image data to make the image parts around the tabs and voids transparent. But, all my efforts to create transparent portions of the image have failed.

I have appended a short app showing my attempts, which included carefully checking the size of the image data vs the size of my manipulations (nData) and checking pre and post manipulation byte values. No joy..

The app (if it worked properly) should remove the portion of the image above the main rectangle of the graphic of a puzzle piece. The main core of the code is here:

Code: Select all

   
   put 0 into n
   repeat with i = 1 to tWidth
      repeat with j = 1 to tHeight
         
         if not((i,j) is within tRect)
         then
            if nIncrement = 1
            then
               put numToChar(0) into byte n+1 of tAlphaData
            else
               put numToChar(0) into byte n+1 of tImageData
            end if
         end if
         
         add nIncrement to n
      end repeat
   end repeat
   

Can anyone tell me where I'm going wrong?

Thanks!

[dunbarx]

I still think that my outlandish offering early on would work. It is the epitome of Brute Force. But I have seen nothing else that would allow one to create their own shapes. I post it again here just to elicit catcalls and insults. Pseudo:

Code: Select all

importImage  --your image here
DrawPolygonGraphicsToTasteOverTheImage --using the polygon graphic tool
nameThoseGraphics
DuplicateAllGraphicsAndSetAsideSomewhere
nameTheDuplicates
scanImagePixelByPixelFromTopLeftToBotRightUnderScriptControl
getBothTheMouseColorAndTheNameOfTheGraphicTheCursorIsWithinWhileScanning
setThe"PixelColor"OfTheAppropriateDuplicateGraphic

Craig

[dunbarx]

It just occurred to me that, "pseudo" notwithstanding, I have not tried to "set the pixelColor", that is, the reverse of getting the mouseColor. Must check that out.

OK, there does not seem to be a way to set the "pixelColor" of a pixel on screen. But one can create tiny polygon graphics, and these can be used to fill the duplicate graphics created from those that cover the image. Such a micro-graphic with a width and height of 1 and a border line size of 0 are the size of a single pixel.

That tiny graphic has a loc, a rect, etc. It therefore has everything one needs, once packed into those duplicate graphics mentioned above; it is physically a "pixel", but with all the properties of a graphic.

It is in fact more than a pixel, since it has a physical existence of its own. Pixels have a loc and color, but nothing else.

One can now change its backcolor to the mouseColor that is "read" from scanning the original graphic.

This will work. The scanning process is simple and straightforward. Packing the duplicate graphics likewise, along with the color-setting process. 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.

I never said it was a small task.

Craig

[rcmills]

I see what you mean, Craig. But the number of pixels in a single puzzle piece the size I’ve been dealing with is around 8K. And the puzzles I’m hoping to make would have 100 pieces. We’re likely to exceed the LC limits in numbers of graphics, 1x0 size though they may be.

[richmond62]

the LC limits in numbers of graphics

What is that limit?

Presumably you mean the limit in numbers of images, NOT graphics.