Reply to Re: Warp-bug found and fixed
If you don't have an account, just leave the password field blank.
September 21st 2012, 05:16 AM
shevek
(E.g. a type zero sprite will disappear if it's placed on top of an animated tile)
That's a different thing. Type 0 sprites aren't really sprites. They are just a way of defining the background, namely as the tiles with the type 0 sprites on top. For performance, the background is drawn during draw_screen. After that, the type 0 sprites are forgotten. This means they cannot have hardness, have a script, do damage, have a warp connected, etc.
The proper way to do animated tiles would be to prepare two layers: one for the tiles, and one for the sprites, and draw both of them each time the screen is drawn (and all the type 1 sprites, of course), or at least create a new "real" background from them each time the tiles are animated. This also costs more time and memory, which may have made a significant difference when Dink was first released. So for performance, the type 0 sprites are part of the background.
Animated tiles draw their new image onto the background. They overwrite the existing background, which is assumed to be the old tile, but can contain type 0 sprites (including dead bodies). If it does, those sprites are simply overwritten and thus lost.
I think Seth must have known this, but he chose to implement it this way because of performance. So that's a feature, not a bug.
Type 2 sprites are identical to type 1, except that they aren't drawn to the screen. The problem here is a type 2 sprite (but I'm not sure if it can happen with type 1 as well) with a warp attached, which is somehow missing in the list of "currently active sprites" (this may actually be intended behaviour for type 2 sprites). In that case, find_sprite will return 0. That wouldn't be a problem, because it will simply look up spr[0].seq, which should be empty, and start warping only when it is 0 (meaning the animation is finished). spr[0].seq starts as 0, so all is well. But if it somehow becomes non-0, there is a problem. It is never used, so its animation doesn't actually run, and it will never become 0 if it isn't. Which means the game will hang.
The problem really is that spr[0].seq somehow becomes non-0. I think this happens when too many (non-background) sprites are simultaneously active. The bug should be fixed by not using spr[0] in that case, but this workaround has the same effect.
That's a different thing. Type 0 sprites aren't really sprites. They are just a way of defining the background, namely as the tiles with the type 0 sprites on top. For performance, the background is drawn during draw_screen. After that, the type 0 sprites are forgotten. This means they cannot have hardness, have a script, do damage, have a warp connected, etc.
The proper way to do animated tiles would be to prepare two layers: one for the tiles, and one for the sprites, and draw both of them each time the screen is drawn (and all the type 1 sprites, of course), or at least create a new "real" background from them each time the tiles are animated. This also costs more time and memory, which may have made a significant difference when Dink was first released. So for performance, the type 0 sprites are part of the background.
Animated tiles draw their new image onto the background. They overwrite the existing background, which is assumed to be the old tile, but can contain type 0 sprites (including dead bodies). If it does, those sprites are simply overwritten and thus lost.
I think Seth must have known this, but he chose to implement it this way because of performance. So that's a feature, not a bug.
Type 2 sprites are identical to type 1, except that they aren't drawn to the screen. The problem here is a type 2 sprite (but I'm not sure if it can happen with type 1 as well) with a warp attached, which is somehow missing in the list of "currently active sprites" (this may actually be intended behaviour for type 2 sprites). In that case, find_sprite will return 0. That wouldn't be a problem, because it will simply look up spr[0].seq, which should be empty, and start warping only when it is 0 (meaning the animation is finished). spr[0].seq starts as 0, so all is well. But if it somehow becomes non-0, there is a problem. It is never used, so its animation doesn't actually run, and it will never become 0 if it isn't. Which means the game will hang.
The problem really is that spr[0].seq somehow becomes non-0. I think this happens when too many (non-background) sprites are simultaneously active. The bug should be fixed by not using spr[0] in that case, but this workaround has the same effect.
