[Kde-games-devel] Here comes Kubrick

[Ian Wadham]

Just committed a version of Kubrick with improved mouse-control,
both for slice-moves and whole-cube rotations.  More details below.

On Tue, 19 Feb 2008 07:33 am, Parker Coates wrote:
> Here's a (rather large) list of issues/potential improvements ... <snip>
>
> - The toolbar is huge. 13 is a lot of buttons. I  had to maximise the
> window to 1152 pixels just so see all items. Fortunately, I think a
> lot of them could easily be removed.
>
Removed two actions (re Tumbling) and will probably make the
toolbar default be icons-only.

> - The "Next View"/"Previous View" interface is awkward. If there are
> only three different views, why not give them names and let me jump
> directly to them.
>
Good idea.

> - As Mauricio pointed out, the initial flood of "You're doing it
> wrong!" dialogues is a bit frustrating.
>
No messages now.  And mouse-control is more forgiving now.

> - If my drag and drop stops on the same sticker it started on, I
> shouldn't get a warning dialogue. The move should just be ignored.
>
Message removed.

> - It be pretty neat if when starting a move by dragging from a
> sticker, arrows appeared on the four adjacent stickers to indicate
> "drop points" for the four possible rotations.
>
No arrows, but the slice that will move when you release the left
mouse button now tilts slightly, in the direction it will turn.  Try
clicking on a sticker and dragging into neighbouring stickers.
You can abandon the move by just moving the mouse back to
where you started.

> - Watch your moves in progress should definitely be enabled by
> default. In fact, I don't really see why one would ever want to turn
> it off.
>
A rapid watch-move animation (about 0.1 sec) is always on now.

> - "Clear tumbling to zero" might make more sense if it were name
> "Reset orientation" or something similar.
>
Tumbling has gone, except in the main demo.  I am working on a
"sync" operation of some kind to set an arbitrarily rotated cube to
a "standard" position consisting of 90 degree rotations.  This is
to make keyboard-controlled slice-moves more clearly meaningful.

Mouse-controlled slice-moves work fine, no matter how the cube as
a whole is rotated.

> - The right button drag interface is convenient when one wants to
> re-orient the cube, but I think sometimes a less discrete way of
> rotating the cube would be convenient.
>
The right mouse-button now grabs a "handle" anywhere on the
cube and then you can rotate the cube every which way, just like
having a finger on a tracking ball.

> - The text "DEMO - Click anywhere to stop" would probably make more
> sense as "Demo - Click anywhere to begin."
>
Done, but Qt 4.4 has made my QLabels disappear.  To be investigated.

> - I'm not that familiar with Qt/OpenGL internals, but if possible,
> anti-aliasing would be a nice option.
>
Hmmm ... I've read up on it a bit, but none of the proposed methods
look to be simultaneously jaggy-removing, easy and cheap in hardware
consumption, if you have a picture of the Rubik Cube type.  The Gnubik
program has an effective method, but it is quite complex to code and
works by rendering each frame eight times at slightly different ("jittered")
positions then merging the results.  Performance on cube-rotations is awful.

I might put anti-aliasing on the back-burner, maybe for KDE 4.2 ...

> - I'm also curious if an option to remove perspective could be useful.
> Sometimes I find the skewing of the faces to be a little bit
> distracting. But then again, who knows; maybe I would find a lack of
> skewing just as distracting.
>
Perspective has been made less obtrusive.

> - The "Go" menu should probably be renamed "View".
>
Will do something.  The "Go" menu appears by default when you use
standard KDE Forward and Back actions.

Cheers everyone, Ian W.