[Kde-games-devel] Review Request 128556: KBreakout: Fix brick count.

[Julian Helfferich]

> On July 30, 2016, 11:02 a.m., Albert Astals Cid wrote:
> > You say
> > **
> > when an invisible or indestructable brick explodes, the remaining brick counter is decreased even though these bricks did not contribute to the number of remaining bricks.
> > **
> > 
> > But the only place i see remainingBricks being decremented is handleDeletion and it seems it already accounts for this issue, no? What am i mising?
> 
> Julian Helfferich wrote:
>     Thank you for looking into it. Yes this is true in most cases. However, the brick type of exploding bricks is set to "BurningBrick" before handleDeletion is called. Thus, handleDeletion does not cover this issue.
>     
>     Typically, when an invisible brick becomes visible or an indestructable brick becomes destructable, the remainingBricks counter is increased. This, however, did not happen in burn() when the brick type was set to "BurningBrick" (which are both visible and destructable) and is exactly what I have added.
> 
> Albert Astals Cid wrote:
>     Then wouldn't it make more sense to handle BurningBrick in handleDeletion so that it is centralized where we do this kind of handling of deleting but not really a brick?

I agree with you. However, as the brick type is set to "BurningBrick" before handleDeletion is called (in case of an explosion), the function has no way of knowing whether the brick to be deleted was invisible or indestructible before. It could have been just an ordinary brick.

There  are several places in the code where the remainingBrick counter is increased. For example, when an invisible brick becomes visible after being hit by a ball, or when indestructible bricks become destructible with the magic wand gift. Thus, it doesn't feel wrong to me to increase the counter in burn().

The simplest way I can think of to use your approach, would be to add a new parameter bool reduceBrickCounter to handleDeletion so that the calling function can decide whether or not to reduce the brick counter.


- Julian


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128556/#review97928
-----------------------------------------------------------


On July 29, 2016, 9:21 p.m., Julian Helfferich wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128556/
> -----------------------------------------------------------
> 
> (Updated July 29, 2016, 9:21 p.m.)
> 
> 
> Review request for KDE Games.
> 
> 
> Bugs: 328811
>     http://bugs.kde.org/show_bug.cgi?id=328811
> 
> 
> Repository: kbreakout
> 
> 
> Description
> -------
> 
> As described in bug 328811, some levels clear before all bricks have been destroyed. This happes for example in Level 6, when invisible bricks are destroyed by the "Burning Ball". KBreakout keeps count of the remaining bricks. Indestructable and invisible bricks do not contribute to the remaining bricks. When bricks are destroyed, the remaining brick counter is decreased accordingly. However, when an invisible or indestructable brick explodes, the remaining brick counter is decreased even though these bricks did not contribute to the number of remaining bricks.
> 
> In the patch, the remaining brick counter is increased if an invisible or indestructible brick is set to explode.
> 
> 
> Diffs
> -----
> 
>   src/qml/logic.js dc6a2d3 
> 
> Diff: https://git.reviewboard.kde.org/r/128556/diff/
> 
> 
> Testing
> -------
> 
> Print out number of remaining bricks.
> 
> a) Before the patch: Confirm that number of remaining bricks is wrong.
> b) After the patch: Confirm that number of remaining bricks is correct. Confirm that levels no longer clear prematurely.
> 
> 
> Thanks,
> 
> Julian Helfferich
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-games-devel/attachments/20160802/c3311303/attachment.html>