[Kde-games-devel] Kollision

[Parker Coates]

2009/2/2 Clemens Werther:
> cleaner_timer.diff
> - Don't set same interval, whenever the timer is started with
> start(interval). Use setInterval(interval) once and start() instead.

A trivial enough change, but it makes sense to me.

> dont_allow_negative_time.diff
> -Negative score doens't make much sense ( a player would take a better
> decision on simply restarting the game).

Makes sense to me.

> pause_on_lost_focus.diff
> -pause the game, if it looses focus

This one needs work. You're calling togglePause() every time the play
area loses focus. This works great for automatically pausing the game,
but does exactly the wrong thing when the game is manually paused. The
game restarts as soon as another window is focused. To make this work,
you're going to need to change it to

if (!m_paused)
    togglePause();

> show_time.diff
> -When a new game is started, the achieved time is only displayed, if
> it is unequal to zero. this doesn't make sense. When a player starts a
> new game, he always wants to see the time (until now, the player
> thinks: "oh, nothing is displayed, so it has to be zero").

I like this change too. It makes the text in the statusbar less "jumpy".

> update_blue_ball_as_needed.diff
> -The blue ball's position is now updated, whenever the red balls
> positions are updated. Also, when the mouse pointer leaves the window,
> the blue balls position still gets updated. This way the blue ball
> can't  "teleport" anymore.

This change is more controversial, in my eyes. For starters, I'm not
sure if this change really reduces the number of updates performed, as
the position is now updated even when the ball is stationary, but
that's a minor concern.

My bigger concern is that it has a fairly large effect on game play.
It removes the frustration of a stuck ball near the edge and as you
mention it removes the "glitch" that allowed the ball to teleport from
one edge to another. Personally, I quite like both those changes. But
this change also makes it quite a lot easier to zip along the edge of
the play area in a perfectly straight, generally safe line. After
applying the patch I find myself playing a lot closer to the edges to
take advantage of this.

Ideally in a situation like this it would be the maintainer's call,
but it seems that Paulo has been AWOL for quite sometime. Provided no
one objects, I will commit the first four patches, but I'm not
comfortable applying the fifth patch without some feedback from
others.

> These are my first patches for KDE, so I am not that experienced with
> it yet and have some questions:
>
> Why is <math.h> included instead of <cmath> ?

Old habit? ;)

> Is there a special reason why kollision uses srand and rand instead of
> qsrand and qrand ?

The q*rand functions are just threadsafe wrappers for the standard C++
functions. Kollision isn't threaded, so there's no need for them.

> Why does kollision use its own collision detection, although QGraphicScene
> provides its own?

My guess would be that Kollision's own detection is specialised for
circles and is therefore probably much, much faster than the generic
implementation in QGraphicsScene.

Parker