Hi Bas, Thanks a great lot for all your effort on this nasty bug, despite my lack of responsiveness.
I took a few hours to investigate what exactly happens (adding a few code comments in the process), and I see that in your testcase dmod, the warp is an invisible sprite which is merged in the background and thus never found by find_sprite(). If spr[0] is clean, the warp continues despite not finding the warp sprite; if spr[0] is modified, then we hit the bug, as the code assumes the warp animation is not finished. I'm not sure in what way an unclean spr[0] will affect the game, but it might, and cleaning it would affect compatibility with the original Dink. Consequently I used and documented your original fix from http://www.dinknetwork.com/forum.cgi?MID=168476#168476 http://git.savannah.gnu.org/cgit/freedink.git/commit/?id=fff4b7cb8d6d2bf84482fdc83c2a21fd9d0379e1 http://git.savannah.gnu.org/cgit/freedink.git/commit/?id=402bf38f69cd7e5c47322b8087ba535d6f823283 http://git.savannah.gnu.org/cgit/freedink.git/commit/?id=5d692b447eb7a8b3c0f1128390641992a4dff484 WDYT? (Btw, I don't have the same line numbers in my source files, possibly you added test code around? ;)) - Sylvain On Sat, Oct 13, 2012 at 01:11:19AM +0200, Bas Wijnen wrote: > I found another way to trigger this: again with max sprites on screen, > hit a duck. The attempt to create the flying head will again fill up > spr[0] and trigger the bug on warp. > > The problem in this case is in duck_brain in freedink.c. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
