Re: How do you play jigsaw puzzles

[Matthew Woehlke-3]

Okay, I am too lazy to use blog comments ;-).

Please don't take the following long lists of gripes the wrong way. My
overall impression was quite favorable. In particular, I am very pleased
that you avoid the typical mistake that pieces snap to their final
positions, rather than each other. Real life doesn't work this way, but
many computer jigsaw games have absolute places that define a piece's
"final position", and will lock pieces into place if you can position
them correctly.

I also like the use of a background texture for the table, and most of
the textures are fairly good (see comment below).

We obviously don't have the technology to capture the exact same tactile
sensation as doing a physical jigsaw, but you've succeeded in making a
virtual version that feels comfortably similar (unlike, as above, many
computer jigsaw games I've tried).

The most important changes I would like to see (these will be covered in
more detail below) are:

- Pieces can rotate, and don't all start at the correct rotation

- Ability to quickly sort pieces into multiple "piles"/"boxes"

- Better puzzle creation (number of pieces, not per direction)

- Better default background, "softer" backgrounds in general


What I don't like:
==================

- Pieces don't rotate :-). Having all the pieces correctly rotated
reduces the challenge somewhat.

- The default background ;-). I could use something that's a similar
color, but the geometric texture doesn't say "table" to me. The others
are all very nice, though all could use a bit less contrast. I think in
general the table should have very, very low contrast (though it's good
that it does *have* texture!). In fact, you might want to consider
plugging a multi-octave perlin noise generator on top of the ability to
choose any color for the table.

- Creating puzzles by number of pieces in X,Y direction. Please just
give us approximate number of pieces, and let the slicer decide based on
that, and the input image's aspect ratio. I accidentally made a 10x10
puzzle out of a 16:5 image... and I think some slicers (see below) won't
be well defined by such dimensions.

- No smooth shading when zooming in... pixels become quite obvious.

- Puzzle pieces are raster; vector would be prettier. (Something to
maybe improve some time in the future...)

- 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.

Bugs?
=====

- Changing the table size doesn't seem to work with a puzzle in progress.

- Severely deformed pieces can have overlapping cutouts, leading to XOR
effects. Try making a puzzle with a bad aspect ratio (e.g. 3x as many
pieces horizontally as vertically on a square image) and you should be
able to reproduce this. However, other than violating some laws of
physics, this didn't seem to break anything. This can probably be
avoided by creating puzzles by total number of pieces instead (as
suggested above).

- There is still a small bit of artifacting on pieces that are put
together. (It's not bad, though.)

- Delete puzzle doesn't appear to be hooked up.

Future ideas:
=============

- 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.

- Better random slicer. First off, I hope slicers don't have to lay
pieces out in a grid (I think no?). What would really make palapeli rock
is ability to cut pieces like real puzzles where pieces can be three or
five sided, slightly offset, etc. Studying real jigsaws would be a
source of many good ideas.

- Tessellating slicers :-D. Salamanders and snowflakes, to start with,
but there are plenty of Escher shapes that can be used as well as
regular tessellations (Escher makes for better material though because
the pieces aren't just simple polygons).

- 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.


Lastly, I'm not particularly interested in building playground/games.
Any objection to the following patch?

Index: CMakeLists.txt
===================================================================
--- CMakeLists.txt      (revision 1038078)
+++ CMakeLists.txt      (working copy)
@@ -1,5 +1,14 @@
  project(palapeli)

+find_package(Qt4 REQUIRED)
+find_package(KDE4 REQUIRED)
+find_package(LibKDEGames REQUIRED)
+
+include_directories(${KDE4_INCLUDES})
+include_directories(${KDEGAMES_INCLUDE_DIRS})
+
+include(KDE4Defaults)
+
  add_subdirectory(libpala)
  add_subdirectory(cmake)
  add_subdirectory(slicers)
===================================================================

--
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...

_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

[Matthew Woehlke-3]

Matthew Woehlke wrote:
> Future ideas:
> =============

- Irregular puzzles (e.g. circles, complex shapes).

> - Tessellating slicers :-D. Salamanders and snowflakes, to start with,
> but there are plenty of Escher shapes that can be used as well as
> regular tessellations (Escher makes for better material though because
> the pieces aren't just simple polygons).

I have, in fact, made (some time ago, for palapeli in fact) a list of
Escher tessellations :-):

http://www.mcescher.com/Gallery/symmetry-bmp/E25.jpg <-- salamanders
http://www.mcescher.com/Gallery/symmetry-bmp/E66.jpg
http://www.mcescher.com/Gallery/symmetry-bmp/E96.jpg
http://www.mcescher.com/Gallery/symmetry-bmp/E78.jpg
http://www.mcescher.com/Gallery/symmetry-bmp/E70.jpg
http://www.mcescher.com/Gallery/symmetry-bmp/E22.jpg
http://www.mcescher.com/Gallery/symmetry-bmp/E28.jpg
http://www.mcescher.com/Gallery/symmetry-bmp/E105.jpg

And yes, these are all (intentionally) nasty as the pieces are all the
exact same shape ;-). (Well, in many - but not all! - of them, one of
only two shapes, so you have two sets of pieces, with all pieces in a
set being identically shaped.)

--
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...

_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

[Arturo Silva]

Wow!  I'm speechless, now THAT was a review.  @v@
Mine is a fly on a car windwhield by comparison... ^^;

Well clearly you know your stuff, as it never occurred to me that
piece rotation could be a feature -- heck, for even more gruesome
difficulty, one could even go as far as randomly "flipping" some of
the pieces to their cardboard bottom, so the user has to flip them
back into place to see what they are (just like in real life).

That, and a lot of other interesting suggestions you made, sound like
they're along the lines of professional jigsaw [puzzling?, lol ^^' ],
and a bit out of my league.

But the background observations are interesting especially since I
didn't particular mind the default ones, but I also love high-contrast
textures.  So perhaps a texture or two for people who do need
something a bit softer could be in order. ^^

I will be experimenting with one that's fairly soft itself -- when
finished, I'll ship it over to you and tell me what you think.  Then I
can create a few other using similar styles.  ^__^


--Arturo
_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

[Matthew Woehlke-3]

Arturo Silva wrote:
> Wow!  I'm speechless, now THAT was a review.  @v@
> Mine is a fly on a car windwhield by comparison... ^^;

I have perhaps an advantage... I don't do jigsaws very often, but I've
certainly done them in my time, and I am pretty hard-core when I do.
Certainly I am an experienced veteran of the 1000-piece genre, and so I
know exactly what I am looking for in a virtual version.

(And I have another lengthy post that will be arriving shortly ;-).)

> Well clearly you know your stuff, as it never occurred to me that
> piece rotation could be a feature -- heck, for even more gruesome
> difficulty, one could even go as far as randomly "flipping" some of
> the pieces to their cardboard bottom, so the user has to flip them
> back into place to see what they are (just like in real life).

Sure, you *could* do that, but IMO that's just saddistic. You're not
adding challenge at that point, just wasted effort...

...Almost.

There is actually one sense in which I could see doing that... double
sided puzzles :-). Either different pictures, or (even more annoying)
the same picture. But that's a long-term feature.

> That, and a lot of other interesting suggestions you made, sound like
> they're along the lines of professional jigsaw [puzzling?, lol ^^' ],
> and a bit out of my league.

I don't think there is such a thing as "professional" jigsaw puzzle
working... but yes, if there was, I could probably compete, at least at
an amateur to intermediate level.

> But the background observations are interesting especially since I
> didn't particular mind the default ones, but I also love high-contrast
> textures.  So perhaps a texture or two for people who do need
> something a bit softer could be in order. ^^

Except for the default, I like the background textures. It's just that
you don't want the background to distract from the pieces. Ideally you
want a background that contrasts strongly with /all/ the pieces, and
also has limited texture. You still /want/ some texture because it looks
better :-), but not much.

I wouldn't "replace" any of the textures (except maybe the default),
just tone them down a bit. Even better might be leave them as is but
with a 'contrast' slider to satisfy both of us. For the built-ins, do
some image processing to dynamically "soften" them.

Actually another idea would be to turn them into something that can be
applied by image processing onto any color. Basically break them into an
overlay channel, hue shift channel, and remove the base color.

Maybe I'll even look into doing this myself.

> I will be experimenting with one that's fairly soft itself -- when
> finished, I'll ship it over to you and tell me what you think.  Then I
> can create a few other using similar styles.  ^__^

That sounds awesome :-). Now... we need to teach you enough code to make
slicers also, I bet you would have some cool ideas there.

--
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...

_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

[Matthew Woehlke-3]

A few more points after playing a while longer...

- The preview is missing. A lot of times I will "solve" jigsaws by
picking up a piece and staring at the box top until I find exactly where
that piece goes. It doesn't always connect to anything, but at the least
it helps to categorize pieces.

- A function to 'unclump' pieces (mainly, to separate overlapping
pieces) would also be useful :-). I think I would do this as a tool;
select the 'unclump' function (usual function is 'move piece'), and
click somewhere, and pieces in that vicinity are 'unclumped'. Think of
it like running your fingers lightly over the pieces to push around ones
that are higher due to having other pieces underneath them.



I'm finding that 1000-piece puzzles are almost unplayable without
features to manage large numbers of pieces. The previously mentioned
'box sorting' would be really helpful, or see suggestion in next
paragraph, but I could also really use a function to select and move a
bunch of pieces at once. Think of shoving a bunch of pieces aside with
the edge of your hand.

Something that emulates picking up a bunch of pieces in your hand and
putting them down again would be extremely helpful. This plus unclump
would reduce the importance of 'box sorting'.



I'm also getting really frustrated with the inconsistency of clicking.
Half the time when I try to move a piece, I end up dragging the table
instead. Sometimes I want to drag the table and get a piece instead. But
most annoying is when I need to drag a piece past the visible table.

I think this should be solved by dropping the right-click background
chooser, and instead using only right click to drag the table. This way
there is no ambiguity what you want to do, and you can combine moving a
piece with panning around on the table.



You've already got something that works well for small (100-piece)
puzzles, and feels like it will be an excellent base for future
development. I can't say I've come across a computer jigsaw puzzle game
(CJPG) before that tries to tackle the four-digits-worth-of-pieces
puzzle genre, but from what I've seen, palapeli could do it. First off,
you're on the right track for getting the "feel" right; you haven't made
the mistakes that I usually see that give CJPGs a 'wrong' feel compared
to physical jigsaws. The performance is also there; palapeli *shines* on
a 1200-piece, 4096x1536 image puzzle. What's missing is just a few
features to make that many pieces manageable without causing major
repetitive stress injury ;-).

Add mis-rotated pieces to bring that extra bit of real world challenge,
fix the 'what do I want to move' ambiguity, fix not being able to deal
with multiple pieces at once, and I think you're really going to have
something great.

I'm looking forward to 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...

_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

[Arturo Silva]

===================================
Matthew Woehlke wrote:
===================================
>
> Sure, you *could* do that, but IMO that's just saddistic.

Haha!  Understatement of the century!  :D


> You're not
> adding challenge at that point, just wasted effort...
>
> ...Almost.
>
> There is actually one sense in which I could see doing that... double
> sided puzzles :-). Either different pictures, or (even more annoying)
> the same picture. But that's a long-term feature.

Well if the game ever comes with multi-part difficulty in the future
(or just puzzles listed as "challenging" that have extra features
built in), then yeah that sounds like a great plan to make this fun
for seasoned players. ^^

>
> Except for the default, I like the background textures. It's just that
> you don't want the background to distract from the pieces. Ideally you
> want a background that contrasts strongly with /all/ the pieces, and
> also has limited texture. You still /want/ some texture because it looks
> better :-), but not much.
>
> I wouldn't "replace" any of the textures (except maybe the default),
> just tone them down a bit. Even better might be leave them as is but
> with a 'contrast' slider to satisfy both of us. For the built-ins, do
> some image processing to dynamically "soften" them.
>
> Actually another idea would be to turn them into something that can be
> applied by image processing onto any color. Basically break them into an
> overlay channel, hue shift channel, and remove the base color.
>
> Maybe I'll even look into doing this myself.

More great ideas, I see. ^^
I wonder if the same right-click texture change menu couldn't also
house a contrast and hue slider as well.  Maybe not by default, but
similar to a "More>" button that displays additional options that can
be applied to that texture (and an accompanying "Less>" button to hide
the sliders once more).


>
> That sounds awesome :-). Now... we need to teach you enough code to make
> slicers also, I bet you would have some cool ideas there.

Thank you! ^^
I'm always all-ears for coding lessons, and I enjoy contributing
non-drawn things [once in a while].  ;)

But beware my so-called bastion of ideas, as the only thing I can
think of at the moment is a Soma-cube (=tetris-like) inspired puzzle
slicer, thematic mosaics, and other sadistic designs.  ^^;


--Art
_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

[Matthew Woehlke-3]

Arturo Silva wrote:
> Matthew Woehlke wrote:
>> There is actually one sense in which I could see doing that... double
>> sided puzzles :-). Either different pictures, or (even more annoying)
>> the same picture. But that's a long-term feature.
>
> Well if the game ever comes with multi-part difficulty in the future
> (or just puzzles listed as "challenging" that have extra features
> built in), then yeah that sounds like a great plan to make this fun
> for seasoned players. ^^

You don't really have much 'level of difficulty' within a single jigsaw
puzzle (maybe piece rotation on/off). Rather, your alternative
suggestion is IMO more in line with physical jigsaws; different puzzles
have different levels of difficulty. The simplest of course is number of
pieces, but there are other features such as double-sided, or all pieces
(except edges) are the exact same shape.

>> I wouldn't "replace" any of the textures (except maybe the default),
>> just tone them down a bit. Even better might be leave them as is but
>> with a 'contrast' slider to satisfy both of us. For the built-ins, do
>> some image processing to dynamically "soften" them.
>>
>> Actually another idea would be to turn them into something that can be
>> applied by image processing onto any color. Basically break them into an
>> overlay channel, hue shift channel, and remove the base color.
>>
>> Maybe I'll even look into doing this myself.
>
> More great ideas, I see. ^^
> I wonder if the same right-click texture change menu couldn't also
> house a contrast and hue slider as well.  Maybe not by default, but
> similar to a "More>" button that displays additional options that can
> be applied to that texture (and an accompanying "Less>" button to hide
> the sliders once more).

That's almost exactly what I was thinking...

--
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...

_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

Am Dienstag 20 Oktober 2009 19:16:33 schrieb Matthew Woehlke:
> > - Tessellating slicers :-D. Salamanders and snowflakes, to start with,
> > but there are plenty of Escher shapes that can be used as well as
> > regular tessellations (Escher makes for better material though because
> > the pieces aren't just simple polygons).

This is your chance to get into Palapeli hacking. ;-) Palapeli puzzles are
created by slicer plugins. Documentation is available on api.kde.org and
Techbase [1], and the code for the tutorial [1] is available from [2].

Greetings
Stefan

[1] http://techbase.kde.org/Development/Tutorials/Games/Palapeli_Patterns
[2] svn://svn.kde.org/home/kde/trunk/playground/games/palapeli/libpala-example


_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

[Parker Coates]

On Tue, Oct 20, 2009 at 13:04, Matthew Woehlke wrote:
> In particular, I am very pleased
> that you avoid the typical mistake that pieces snap to their final
> positions, rather than each other. Real life doesn't work this way, but
> many computer jigsaw games have absolute places that define a piece's
> "final position", and will lock pieces into place if you can position
> them correctly.

It's funny that you mention this, because I was just about to suggest
it as a feature, but not exactly in the sense you mean. I thought it
might be interesting to have a puzzle option for creating "framed"
children's puzzles. In case anyone isn't familiar, these are puzzle
with a low number of large (usually wooden or plastic) pieces that fit
into a frame that usually shows the completed image and the pieces are
then placed on top of this. Generally each piece will only physically
fit in one particular spot.

These are great for young children as they greatly simplify the
puzzling solution by making it more linear. Instead of searching the
entire set of pieces to find a pair that mate, one need only pick up a
piece, examine it, find the corresponding spot on the board, and move
on to the next piece.

The implementation would "just" require painting the final image
(probably half transparent or washed out) on the table, disable pieces
snapping to one another, enable snapping to final position instead. I
say "just" as I have no idea if this is even remotely doable with the
Palapeli framework. I also have no idea if there's any real demand for
such a play mode. It was just the first thing that came to mind when
Stefan asked for suggestions.

> - Pieces don't rotate :-). Having all the pieces correctly rotated
> reduces the challenge somewhat.

I think the option to rotate the pieces is a good idea, but I think it
should definitely be an option and probably an opt-in one, at that.

> - Creating puzzles by number of pieces in X,Y direction. Please just
> give us approximate number of pieces, and let the slicer decide based on
> that, and the input image's aspect ratio. I accidentally made a 10x10
> puzzle out of a 16:5 image.

I think it would make sense for the puzzle creation UI to only ask for
the total piece count, but to internally store and use an X by Y
system. This keeps things simple for the basic user,  but allows one
to manually tweak the puzzle file if one wants tall skinny pieces.

One other suggestion. Don't add highscores. I've already seen one
person suggest it at your blog and I have to say I'm strongly opposed.
The concepts of jigsaw puzzling and time pressure are so intrinsically
opposite that the idea of adding highscores to a puzzling game seems
downright blasphemous.  In my experience, the success of a puzzling
session is best assessed by the quality of conversation and the volume
of tea consumed in the process, not by a stopwatch. (Unfortunately,
curiosity got the better of me and I did some research. It turns out
there is such a thing as a speed puzzling competition. Sigh.)

Parker
_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

Am Dienstag 20 Oktober 2009 21:20:13 schrieb Matthew Woehlke:
> - A function to 'unclump' pieces (mainly, to separate overlapping
> pieces) would also be useful :-). I think I would do this as a tool;
> select the 'unclump' function (usual function is 'move piece'), and
> click somewhere, and pieces in that vicinity are 'unclumped'. Think of
> it like running your fingers lightly over the pieces to push around ones
> that are higher due to having other pieces underneath them.

Moved to mid-term todolist. I think this can be combined with some other
requested feature: having one piece push other pieces out of its way while
dragging it. The unclumping is the same action, just without a piece attached
to the cursor. It would be toggled by some modifier, e.g. Ctrl.

> I'm finding that 1000-piece puzzles are almost unplayable without
> features to manage large numbers of pieces. The previously mentioned
> 'box sorting' would be really helpful, or see suggestion in next
> paragraph, but I could also really use a function to select and move a
> bunch of pieces at once. Think of shoving a bunch of pieces aside with
> the edge of your hand.

Palapeli is starting out as a platform for small puzzles, and aims to increase
the possible puzzle size slowly, but steadily. I want a solid puzzling engine
for now, advanced management and convenience features to cope with big puzzles
will be added later (i.e. KDE 4.5).

> Something that emulates picking up a bunch of pieces in your hand and
> putting them down again would be extremely helpful. This plus unclump
> would reduce the importance of 'box sorting'.

Rubberband selection is already on the midterm todolist.

> I'm also getting really frustrated with the inconsistency of clicking.
> Half the time when I try to move a piece, I end up dragging the table
> instead. Sometimes I want to drag the table and get a piece instead. But
> most annoying is when I need to drag a piece past the visible table.

Expect a solution to these problems to appear very soon.

> I think this should be solved by dropping the right-click background
> chooser, and instead using only right click to drag the table.

Both streamlining the texture selection (which includes making it more
visible) and assigning rightclick to table dragging are on the todolist.

> You've already got something that works well for small (100-piece)
> puzzles, and feels like it will be an excellent base for future
> development. I can't say I've come across a computer jigsaw puzzle game
> (CJPG) before that tries to tackle the four-digits-worth-of-pieces
> puzzle genre, but from what I've seen, palapeli could do it. First off,
> you're on the right track for getting the "feel" right; you haven't made
> the mistakes that I usually see that give CJPGs a 'wrong' feel compared
> to physical jigsaws. The performance is also there; palapeli *shines* on
> a 1200-piece, 4096x1536 image puzzle. What's missing is just a few
> features to make that many pieces manageable without causing major
> repetitive stress injury ;-).

I appreciate your kind words. I expect a performance bottleneck in the drop
shadow renderer (although, in the process of creating it, I've already found a
way to speed up the QGraphicsDropShadowEffect by 75%). Apart from that, it all
hinges with QGraphicsView's rendering speed (which seems to have greatly
improved in 4.6 again).

> Add mis-rotated pieces to bring that extra bit of real world challenge,
> fix the 'what do I want to move' ambiguity, fix not being able to deal
> with multiple pieces at once, and I think you're really going to have
> something great.

Moved to long-term todolist (requires investigation on what input methods are
intuitive for this).

Greetings
Stefan


_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

Am Dienstag 20 Oktober 2009 23:29:26 schrieb Parker Coates:
> It's funny that you mention this, because I was just about to suggest
> it as a feature, but not exactly in the sense you mean. I thought it
> might be interesting to have a puzzle option for creating "framed"
> children's puzzles. In case anyone isn't familiar, these are puzzle
> with a low number of large (usually wooden or plastic) pieces that fit
> into a frame that usually shows the completed image and the pieces are
> then placed on top of this. Generally each piece will only physically
> fit in one particular spot.

I think you can accomplish this without altering Palapeli. You can write a
slicer plugin which generates such puzzles. This type of puzzles is actually
one of the reasons for why slicing is so generic in Palapeli (the other reason
is Escher's tesselation patterns).

> > - Pieces don't rotate :-). Having all the pieces correctly rotated
> > reduces the challenge somewhat.
>
> I think the option to rotate the pieces is a good idea, but I think it
> should definitely be an option and probably an opt-in one, at that.

Agreed. This option seems to be the only way to vary the difficulty of a given
puzzle.

Greetings
Stefan


_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

On Wed, 21 Oct 2009 8:33:02 am Stefan Majewsky wrote:
> Rubberband selection is already on the midterm todolist.
>
May I suggest some kind of lasso selection to outline a group of pieces?

Cheers, Ian W.
_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

[Matthew Woehlke-3]

Stefan Majewsky wrote:
> I appreciate your kind words.

Thanks :-).

> I expect a performance bottleneck in the drop shadow renderer
> (although, in the process of creating it, I've already found a way to
> speed up the QGraphicsDropShadowEffect by 75%).

Well, as I said, there is no performance issue right now on 1200-piece,
4096x1536 puzzle. If it's even the tiniest bit sluggish, I haven't
noticed yet :-D.

> Apart from that, it all hinges with QGraphicsView's rendering speed
> (which seems to have greatly improved in 4.6 again).

Hmm, it's true I am using Qt 4.6 though :-). (I'm also using today's svn
of palapeli, if it matters.)

--
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...

_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

Am Dienstag 20 Oktober 2009 19:04:20 schrieb Matthew Woehlke:
> Okay, I am too lazy to use blog comments ;-).

I sympathize with you, esp. for such long texts. ;-)

> Please don't take the following long lists of gripes the wrong way. My
> overall impression was quite favorable.

As long as the gripes are constructive (which yours definitely are), I'm fine.
(Even if grapes would be more desirable... Hmm... grapes.)

> In particular, I am very pleased
> that you avoid the typical mistake that pieces snap to their final
> positions, rather than each other. Real life doesn't work this way, but
> many computer jigsaw games have absolute places that define a piece's
> "final position", and will lock pieces into place if you can position
> them correctly.

Hm, I never had the idea to _not_ make it behave in the way it does now,
although I might add an "easy mode" in which a faint impression of the final
image appears at the bottom of the puzzle table, with pieces snapping to their
position in this preview.

> - The default background ;-). I could use something that's a similar
> color, but the geometric texture doesn't say "table" to me. The others
> are all very nice, though all could use a bit less contrast. I think in
> general the table should have very, very low contrast (though it's good
> that it does *have* texture!). In fact, you might want to consider
> plugging a multi-octave perlin noise generator on top of the ability to
> choose any color for the table.

The default background is the default because it was the only one when I added
background textures. Also, it is the only one created by a KDE artist: Eugene,
who drew it at a time when Palapeli did not support background textures yet,
so he had no chance of testing it. My friends and I usually call this texture
the "80s wallpaper", and I consider it an integral part of the Palapeli
experience. ;-)

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

> - Creating puzzles by number of pieces in X,Y direction. Please just
> give us approximate number of pieces, and let the slicer decide based on
> that, and the input image's aspect ratio. I accidentally made a 10x10
> puzzle out of a 16:5 image... and I think some slicers (see below) won't
> be well defined by such dimensions.

Good idea. The X-Y selection is there because it's more straight-forward.

> - 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.

> - 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.

> - 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).

> Bugs?
> =====
>
> - 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.

> - Severely deformed pieces can have overlapping cutouts, leading to XOR
> effects. Try making a puzzle with a bad aspect ratio (e.g. 3x as many
> pieces horizontally as vertically on a square image) and you should be
> able to reproduce this. However, other than violating some laws of
> physics, this didn't seem to break anything. This can probably be
> avoided by creating puzzles by total number of pieces instead (as
> suggested above).

Hm, this shouldn't happen, but I have an idea why the algorithm could fail.
Could you please test whether the jigsaw slicer generates better results with
the attached patch applied? (You will have to rebuild the puzzles. Puzzles
that have already been built won't change anymore.)

> - 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.

> - 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?

> Future ideas:
> =============
>
> - 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.)

> - Better random slicer. First off, I hope slicers don't have to lay
> pieces out in a grid (I think no?). What would really make palapeli rock
> is ability to cut pieces like real puzzles where pieces can be three or
> five sided, slightly offset, etc. Studying real jigsaws would be a
> source of many good ideas.

Grid: Of course not. More reality in slicing: I'm focussing on other things
currently. The current slicing is good enough for the start, though more
reality is desirable.

> - 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.

> 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, so for now I kindly ask you to
keep this in your working copy. Alternatively, you can use a setup similar to
mine, which is described on my blog (http://majewsky.wordpress.com, then the
link at the very top right).

Greetings
Stefan

--
Die Zukunft wird nicht gemeistert von denen, die an der Vergangenheit kleben.

[jigsawslicer-better-scale-behavior-on-nonsquare-pieces.diff]

---

Index: slicers/slicer-jigsaw.cpp
===================================================================
--- slicers/slicer-jigsaw.cpp (Revision 1038041)
+++ slicers/slicer-jigsaw.cpp (Arbeitskopie)
@@ -170,22 +170,22 @@
  if (y == 0)
  path.lineTo(maskBaseRect.topRight());
  else
- addPlugToPath(path, topSide(maskBaseRect), QPointF(0, verticalPlugDirections[x][y - 1]), verticalPlugParams[x][y - 1]);
+ addPlugToPath(path, maskBaseRect.height(), topSide(maskBaseRect), QPointF(0, verticalPlugDirections[x][y - 1]), verticalPlugParams[x][y - 1]);
  //right plug
  if (x == xCount - 1)
  path.lineTo(maskBaseRect.bottomRight());
  else
- addPlugToPath(path, rightSide(maskBaseRect), QPointF(horizontalPlugDirections[x][y], 0), horizontalPlugParams[x][y].mirrored());
+ addPlugToPath(path, maskBaseRect.width(), rightSide(maskBaseRect), QPointF(horizontalPlugDirections[x][y], 0), horizontalPlugParams[x][y].mirrored());
  //bottom plug
  if (y == yCount - 1)
  path.lineTo(maskBaseRect.bottomLeft());
  else
- addPlugToPath(path, bottomSide(maskBaseRect), QPointF(0, verticalPlugDirections[x][y]), verticalPlugParams[x][y].mirrored());
+ addPlugToPath(path, maskBaseRect.height(), bottomSide(maskBaseRect), QPointF(0, verticalPlugDirections[x][y]), verticalPlugParams[x][y].mirrored());
  //left plug
  if (x == 0)
  path.lineTo(maskBaseRect.topLeft());
  else
- addPlugToPath(path, leftSide(maskBaseRect), QPointF(horizontalPlugDirections[x - 1][y], 0), horizontalPlugParams[x - 1][y]);
+ addPlugToPath(path, maskBaseRect.width(), leftSide(maskBaseRect), QPointF(horizontalPlugDirections[x - 1][y], 0), horizontalPlugParams[x - 1][y]);
  //determine the required size of the mask
  path.closeSubpath();
  const QRect newMaskRect = path.boundingRect().toAlignedRect();
@@ -236,7 +236,7 @@
  return true;
 }
 
-void JigsawSlicer::addPlugToPath(QPainterPath& path, const QLineF& line, const QPointF& plugDirection, const JigsawPlugParams& params)
+void JigsawSlicer::addPlugToPath(QPainterPath& path, qreal plugNormLength, const QLineF& line, const QPointF& plugDirection, const JigsawPlugParams& params)
 {
  //Naming convention: The path runs through five points (p1 through p5).
  //pNbase is the projection of pN to the line between p1 and p5.
@@ -247,7 +247,7 @@
  const QPointF growthDirection = plugDirection / sqrt(plugDirection * plugDirection);
  const qreal sizeFactor = line.length();
  const QPointF growthVector = growthDirection * sizeFactor;
- const QPointF plugVector = params.plugLength * growthVector;
+ const QPointF plugVector = params.plugLength * plugNormLength * growthDirection;
  //calculate points p2, p3, p4
  const qreal t3 = params.plugPosition;
  const QPointF p3base = (1.0 - t3) * p1 + t3 * p5;
Index: slicers/slicer-jigsaw.h
===================================================================
--- slicers/slicer-jigsaw.h (Revision 1034879)
+++ slicers/slicer-jigsaw.h (Arbeitskopie)
@@ -40,7 +40,7 @@
  explicit JigsawSlicer(QObject* parent = 0, const QVariantList& args = QVariantList());
  virtual bool run(Pala::SlicerJob* job);
  protected:
- void addPlugToPath(QPainterPath& path, const QLineF& line, const QPointF& plugDirection, const JigsawPlugParams& parameters);
+ void addPlugToPath(QPainterPath& path, qreal plugNormLength, const QLineF& line, const QPointF& plugDirection, const JigsawPlugParams& parameters);
 };
 
 #endif // PALAPELISLICERS_JIGSAW_SLICER_H

---

_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

[Parker Coates]

On Tue, Oct 20, 2009 at 17:59, Ian Wadham wrote:
> On Wed, 21 Oct 2009 8:33:02 am Stefan Majewsky wrote:
>> Rubberband selection is already on the midterm todolist.
>>
> May I suggest some kind of lasso selection to outline a group of pieces?

I just had the exact same though upon reading the word "rubber band". :)

Parker
_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

[Matthew Woehlke-3]

Parker Coates wrote:
> On Tue, Oct 20, 2009 at 13:04, Matthew Woehlke wrote:
>> - Pieces don't rotate :-). Having all the pieces correctly rotated
>> reduces the challenge somewhat.
>
> I think the option to rotate the pieces is a good idea, but I think it
> should definitely be an option and probably an opt-in one, at that.

Hehe, as a jigsaw enthusiast, I disagree (about opt-in) :-). Optional is
fine, though.

As far as altering the difficulty, another way would be to add a
'handicap', i.e. so many pieces that are already put together in small
groups. (Especially as in real jigsaw puzzles there are often at least a
few stuck together in a brand new puzzle ;-).) Effectively you are
dynamically reducing the piece count.

Of course, if double-sided puzzles ever get added, you can also reduce
the difficulty by disabling the back side (or increase it by /adding/ a
back side).

>> - Creating puzzles by number of pieces in X,Y direction. Please just
>> give us approximate number of pieces, and let the slicer decide based on
>> that, and the input image's aspect ratio. I accidentally made a 10x10
>> puzzle out of a 16:5 image.
>
> I think it would make sense for the puzzle creation UI to only ask for
> the total piece count, but to internally store and use an X by Y
> system. This keeps things simple for the basic user,  but allows one
> to manually tweak the puzzle file if one wants tall skinny pieces.

Personally I would leave it up to the slicer. Maybe slicers should have
a way to add options for that slicer; you could add 'aspect' as an option.

Ah... especially since some slicers (e.g. 'perfect hexagons') may not be
able to adhere to a requested pieces-per-row, pieces-per-column sort of
input. (Why not? Because the pieces *must* have perfect 1:1 aspect ratio
or you break rotation working as it is supposed to, which is you can
only tell right correct rotation from the image.)

> One other suggestion. Don't add highscores. I've already seen one
> person suggest it at your blog and I have to say I'm strongly opposed.
> The concepts of jigsaw puzzling and time pressure are so intrinsically
> opposite that the idea of adding highscores to a puzzling game seems
> downright blasphemous.  In my experience, the success of a puzzling
> session is best assessed by the quality of conversation and the volume
> of tea consumed in the process, not by a stopwatch. (Unfortunately,
> curiosity got the better of me and I did some research. It turns out
> there is such a thing as a speed puzzling competition. Sigh.)

...or at least make them optional. But I agree, jigsaw puzzles should be
relaxing. Timing them tends to break that (and then you need a 'pause'
also).

--
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...

_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

[Parker Coates]

On Tue, Oct 20, 2009 at 18:11, Stefan Majewsky wrote:

> Am Dienstag 20 Oktober 2009 19:04:20 schrieb Matthew Woehlke:
>> 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, so for now I kindly ask you to
> keep this in your working copy. Alternatively, you can use a setup similar to
> mine, which is described on my blog (http://majewsky.wordpress.com, then the
> link at the very top right).

I think a solution as was mentioned here would make sense for games in
playground:

http://markmail.org/message/s7bd2eaaqnm46vbv

If Matthew's additions were surrounded by a guard as shown there, you
could drop the dependence on the module while still doing the right
thing when being built as part of the module. Of course if you'd
rather keep your CMakeLists.txt clean, than I can understand that too.

Parker
_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

Am Mittwoch 21 Oktober 2009 00:15:29 schrieb Matthew Woehlke:
> > I think it would make sense for the puzzle creation UI to only ask for
> > the total piece count, but to internally store and use an X by Y
> > system. This keeps things simple for the basic user,  but allows one
> > to manually tweak the puzzle file if one wants tall skinny pieces.
>
> Personally I would leave it up to the slicer. Maybe slicers should have
> a way to add options for that slicer; you could add 'aspect' as an option.

You should really have a look at the libpala API. Slicers already have a way
to add options (even if the X-Y scheme is the only set of properties that is
in use currently). Here's how the basic workflow is:
1. When the plugin is loaded, it creates an instance of a subclass of
Pala::Slicer.
2. The Pala::Slicer creates Pala::SlicerProperty instances to describe its
parameters. Possible types are string, integer, boolean; more types can be
added to libpala.
3. Palapeli's create-puzzle dialog reads the property list of the slicer, and
creates widgets to configure the property values.
4. When you click on "Create puzzle", the image and the property values are
read from the dialog and packed into a Pala::SlicerJob instance, which is then
passed to Pala::Slicer.
5. The slicer reads the input from the SlicerJob, creates the pieces and
defines relations between them. This output is written into the SlicerJob.
6. Palapeli reads the output of the slicer from the SlicerJob, and creates a
new puzzle file.

> > One other suggestion. Don't add highscores. I've already seen one
> > person suggest it at your blog and I have to say I'm strongly opposed.
> > The concepts of jigsaw puzzling and time pressure are so intrinsically
> > opposite that the idea of adding highscores to a puzzling game seems
> > downright blasphemous.  In my experience, the success of a puzzling
> > session is best assessed by the quality of conversation and the volume
> > of tea consumed in the process, not by a stopwatch. (Unfortunately,
> > curiosity got the better of me and I did some research. It turns out
> > there is such a thing as a speed puzzling competition. Sigh.)
>
> ...or at least make them optional. But I agree, jigsaw puzzles should be
> relaxing. Timing them tends to break that (and then you need a 'pause'
> also).

Of course, timing will be optional. I think that other stuff is more important
than puzzling against the clock and hunting for highscores.

Greetings
Stefan

--
Die Zukunft wird nicht gemeistert von denen, die an der Vergangenheit kleben.


_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

Am Mittwoch 21 Oktober 2009 00:28:25 schrieb Parker Coates:
> I think a solution as was mentioned here would make sense for games in
> playground:
>
> http://markmail.org/message/s7bd2eaaqnm46vbv
>
> If Matthew's additions were surrounded by a guard as shown there, you
> could drop the dependence on the module while still doing the right
> thing when being built as part of the module. Of course if you'd
> rather keep your CMakeLists.txt clean, than I can understand that too.

If the buildsystem guys agree with that solution (and they do apparently), I'm
fine with it too. Just one note on the patch: You can remove the libkdegames
stuff. I'm not depending on it.

Greetings
Stefan


_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

[Matthew Woehlke-3]

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...

_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel