@aros-sg
Thanks, I'll try to remember that - eventually
It's not just annoying to code, unfortunately it's counterproductive too.
Consider the most simple case which is one player partially occluding the ball. Even for this case you'd first have to fetch the correct mask from the set of animations and zoom levels, then calculate the correct offset in relation to the ball, maybe do some extra stuff like clipping, then, with all that info, create a ball picture out of the original ball-data and the mask.
As you can imagine all this won't improve performance compared to the current BOB solution. Even worse, in reality you can easily have situations where multiple players are partially occluding the ball, so either you have to simplify and lose quality or lose even more performance. In contrast the current pretty trivial solution delivers best quality at low cost already.
No, that good old "mask sprite-date to simulate occlusion" trick really doesn't work here.
Also, the ball is only a very small BOB, so it doesn't really matter that much anyway. If I reliably get the info "ball is not occluded at all" during the quick (wip) occlusion-check then avoiding the BOB in such a case is a nice free extra-gain because I have that ball-sprite support anyway for the reasons explained
before. Anything else is not worth it and will have a very hard time beating the simple BOB in terms of performance and qualiy.