[Kde-games-devel] How do you play jigsaw puzzles

[Matthew Woehlke]

Stefan Majewsky wrote:
> Apart from these explanations, my hands are tied when it comes to creating 
> softer backgrounds, 'cause I'm not a graphics designer.

Dynamic backgrounds (as suggested elsewhere in this thread) would solve 
this handily. For example, I'd use the 'beige marble', but it is too light.

> Am Dienstag 20 Oktober 2009 19:04:20 schrieb Matthew Woehlke:
>> - No smooth shading when zooming in... pixels become quite obvious.
> 
> Has been selled for performance. I'm not sure whether QGraphicsView does 
> smooth shading for QGraphicsPixmapItems at all.

Makes sense. If it's possible, it should probably be optional. I'd make 
this low priority though. (It's especially bad on very small images, and 
not really noticeable on big ones. If I'm making a puzzle of a 12 MP 
photo from my digital camera, smooth scaling isn't really needed. Maybe 
it would be useful to have an option to smooth-resize small images 
before making the puzzle.)

>> - Puzzle pieces are raster; vector would be prettier. (Something to
>> maybe improve some time in the future...)
> 
> Palapeli's puzzle files contain pre-rendered raster images. That's a design 
> decision: I want puzzle files to be easy, portable and self-contained.

Why couldn't this be done with some form of vector graphics? Anyway, 
this is certainly a long-term wish.

>> - Puzzle author is mandatory. Am I the author because I picked an image,
>> slicer, and number of pieces? That doesn't seem right. And if I get an
>> image off the internet, there is a very good chance I don't know who
>> produced that image.
> 
> It says "image author" on purpose. Putting the image into a Palapeli slicer is 
> not really an action that deserves attribution (at least when compared to 
> creating the image).

Right. But... if I pick something from /usr/local/share/wallpapers, I 
can guarantee you the change I know who is the image author is virtually 
nil in many cases. (Some of my massive collection is sorted by artist, 
but a large portion isn't, and has no artist information recorded.)

>> - Changing the table size doesn't seem to work with a puzzle in progress.
> 
> Yes, bug. This problem will disappear when I rewrite the zooming and arranging 
> stuff.

Okay, just seeing if it is known. Thanks.

>> - There is still a small bit of artifacting on pieces that are put
>> together. (It's not bad, though.)
> 
> You mean the thin lines between them? I cannot reduce them more, and have 
> started to think of them as a feature: It allows you to distinguish assembled 
> pieces just as you can in real life, because normal piece edges are rounded.

Right. I guess this goes at what Arturo was saying, I'd prefer they are 
either obvious, or invisible (preferably as an option). I guess the only 
way to solve this is to repaint assembled sections as one object. It's 
certainly no show-stopper, but it would still be nice to see it "fixed" 
eventually.

>> - Delete puzzle doesn't appear to be hooked up.
> 
> Are you trying to delete one of the default puzzles? If no, how did you create 
> the puzzle? And do you have write access to the puzzle file?

I didn't get any default puzzles, so I had to make my own in program. 
Presumably that means I have write access to them. (I guess there are 
instructions somewhere for how to make the default puzzles work, but I 
didn't know where they are. And since creating new puzzles worked fine, 
I wasn't too worried about it.)

>> - One technique I've often seen for doing puzzles is to separate the
>> table from one or more boxes of pieces. This helps to categorize; you
>> can toss all pieces that are, for example, a similar color into one box.
>>   I think it would be helpful to have a feature that would configure one
>> or more "boxes", or even just piece groups, and a way to quickly move
>> pieces (e.g. just by clicking on them) to a group. Anything sent to that
>> group should then be clustered in close proximity, but not overlapping.
> 
> Already on the list: "baskets". Whenever you want to separate a bunch of 
> pieces from the rest, you create a basket and throw the pieces into it. Then 
> you can either continue with the rest, or look into the basket and put the 
> pieces in there together. (As you see, "baskets" is a bad name. It's highly 
> non-obvious to play a jigsaw puzzle in a basket.)

Hehe, just rename them 'boxes', as in, the box the jigsaw came in. 
That's what I'm used to using (when doing physical puzzles), anyway :-).

Oh, regarding this comment (from the blog)...

Daniel said:
> [...] what disturbs me a bit is that I first have to clear a part of 
> the puzzle table to be able to assemble the puzzle, because otherwise
> I just have no space. [...]
> It’d be nice if the were two table parts, one with the distributed
> pieces and an empty one to instantely start puzzling on.

This is easy, just start all pieces in one "basket"/"box" :-).

> The current slicing is good enough for the start [...]

Oh, sure, and in fact I would keep the current slicer. Actually I 
believe the current slicer is more historically accurate (i.e. to 
puzzles cut with an actual jigsaw). I suspect the more 'random' style 
didn't come into existence until automated machinery (and now I guess, 
lasers) to cut the pieces.

>> - Get new images from kde-look.org. Seriously, a large percentage of
>> wallpapers would make decent puzzles as well, and kde-look is a ready
>> source of such.
> 
> Palapeli has infrastructure for "puzzle feeds", which provide a similar (yet 
> better integrated) functionality. Unfortunately, there will not be enough time 
> left for an interface to these. This gives me time to think about how to 
> generate puzzles from images on the fly.

Well there is a reason I put this one in 'future ideas' :-). Puzzle 
feeds are good too, obviously they have their own benefits. And it is 
really easy to make your own puzzles from your own images, so having 
multiple sources for new puzzles is probably not needed.

>> Lastly, I'm not particularly interested in building playground/games.
>> Any objection to the following patch?
>>
>> Index: CMakeLists.txt
>> [...]
> 
> I'm afraid that some build-system guy would complain about this kind of stuff, 
> because it's not how it is supposed to be done,

Really? Says who?

Okay, I see there should be a check if we need to look for KDE. (I took 
the 'if (NOT KDE4_FOUND)' one from kigo, it's close enough for now.) But 
if someone is saying it should /not/ be buildable on its own, um... 
that's just wrong. Usually playground and kdereview should be buildable 
outside their modules, and ALWAYS kdesupport should be. And there is no 
rule against anything even in main modules being buildable on its own 
(e.g. I hear ksysguard is).

(Also, no other part of KDE requires putting a CMakeLists.txt in a build 
dir - the one in the source dir should always be used. Do you not build 
your own KDE? Or is there some other reason your build method looks 
nothing like http://techbase.kde.org/Getting_Started/Build/KDE4?)

Also... reading your instructions, I now see the thing about making the 
default puzzles. Any reason that isn't part of the build system? (If 
not, that might need to be fixed before we can ship it.)

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
So, an astrophysicist, a quantum physicist, and an astrologer walk into 
a bar...