collision enumeration quirk
msliczniak opened this issue · 3 comments
It'd be nice if collision enumeration into vf could be enabled for schip. I expected it to work that way in octo but vf is only 0 or 1.
As far as I'm aware, no software currently makes use of this behavior, and like most of SCHIP's bizarre probably-unintentional misfeatures I'd rather not encourage any new software to depend upon it.
Okay, I thought it would be nice in octo programs, especially if it worked as expected with wrapping. I ran into a situation where I would not have to keep track of piece type if vf recorded the rows. If I did it by bitplane too, I would not need to record color either:
. . .
x x x
x x x
x x x
. . .
. . .
. . .
. x .
x x x
x x x
x x x
. x .
. . .
. . .
. . .
x x x
x x x
x x x
. x .
. x .
. x .
If I blit with
. x .
x x x
x x x
x x x
. x .
. x .
. x .
then I know the type and which sprite to blit with again to finish clearing or restore the original after different code paths.
But if you don't want octo to use vf here, that's fine it's your thing after all. I was just surprised cause I expected it would work. I'll close this, cheers.
I can't seem to close it, sorry. But your rationale is fine.