[Xbubble-users] Version 0.5.8: Hello Debian, optimizations needed for (future) chain reactions

[Martin Quinson]

Hello,

I just made a new version of xbubble. It took me two version numbers to get it
right, since the �0.5.7 introduced a stupid bug, which is fixed in 0.5.8.

The main change is not visible in the tar ball: I did completely repackage
xbubble to split out the data in another package (making the overall archive
size smaller) as requested by the debian maintainer. In the meanwhile, I did
change the packaging to use the wonderfull cdbs (common debian build system).

But, in order to make non-debian user happy also, I did also speed a bit
more the game (by caching a new stuff instead of recomputing it "3215352
time per second). It is kind of useless right now, but I needed it for the
chain reactions which I'm currently trying to implement. 

I also tryied to fix properly the overflow problem: when your board is
lowered and you get malus balls at the same time, some bubbles may be placed
on the "deadline-2" line, which is not part of the board. Their look is thus
not changed to DEAD, and it looks bad. I did it wrong in 0.5.7, but it
should be ok now.


A few words about chain reactions for the ones wondering why I need so long
to do it. The point is that I do not want to reproduce the bugs of
frozen-buble. First of all, a free position having two neighbors of the same
color *is* a valid position. But the more problematic is that we shouldn't
let falling balls run to react with stuck balls if those stuck balls will
themselves be unhooked by another reaction. 

Example:

 R R R R
  B W B
   Y Y
   
If a R ball falls, it goes reacting with the above ones and that's good. 
But then, we should forbid any Y ball to go reacting with the ones below.

That's a bit tricky to achieve, and frozen-bubble almost achieve that. The
exception is when the R ball fall from a first reaction, and the Y from a
second one. Ie, when we have 3 reactions. a first reaction creating two
ones, the first of them letting the R ball fall while the second reaction let
a Y ball fall. 

In that case, in fb, the Y ball will go to react anyway. If you're out of
luck the Y balls it wanted to react with will be gone in the time it comes.
Then, your Y ball stay where it is, maybe even unhooked.

That's what I want to avoid, but I'�mnot quite sure about how to do it
efficiently. 

In case I managed to create a bit of curiosity in you, there is a
count_reacting_bubble in cell.c (commented for now) which is my current try
about it. It is very far from working for now, and your help is welcome ;)


Have fun, in coding this if you like, 
or even in playing the game if you prefer (you strange people ;)

Thanks for attention, Mt.

signature.asc
Description: Digital signature