I haven't had time to do any coding, but I did explore playfield masking while using NUSIZ1 and it looked very promising! I threw all the balloon positions for each frame into an excel sheet. Visually I found that an asynchronous playfield is the way to go as the bits used to mask each balloon never overlap each other.
As can be seen in the balloon picture:A)
There are nine balloons shown each frame. There is an exception where 10 are occasionally shown, but lets ignore it for now. Two frames are flickered to give the appearance of 18 balloons.B)
I chose to turn off balloons 2,4,6, and 8. Looking at the excel sheet pictured above, the balloon mask bits for this particular position were found in the top row of the group I labeled as 6, (the group number is on the left side of the sheet). The excel sheet shows PF0 as blue/white columns, PF1 as green/white, and PF2 as orange/white. Both sides of the playfield are shown overlapped in the excel sheet. Looking at the sheet it can be seen the masking for balloon 8 would also cover up the player graphics. So the ball will be used to mask balloon 8, and the playfield will simply be set with these values:
PF0 = $00
PF1 = $3C
PF2 = $30C)
Here the player is on top of a balloon that needs to be masked. Since the playfield has priority over the player graphics neither the playfield or ball can be used to cover up this balloon. The balloon can be hidden by storing 0 to GRP1 and then restoring the graphics afterward, but that does not work once the balloon gets shifted by 1 or more pixel to the right. Specifically you would be limited to using bits 7-3 of the graphics register. You could try to hide the balloon by making COLUP1 the same as the background (black), but that turns out to be even more limiting as the write seems to take effect after 4 pixels leaving only bits 7-4 of GRP1 available for graphics.
So finally a working solution is to update NUSIZ1 to 2 copies medium or 3 copies medium to prevent the balloon where the player is from being drawn, and then quickly switching back to 3 copies close.
The things I like about all this are:
- The playfield and ball can be set outside of the loop and left alone. Only NUSIZ1 might have to be dealt with.
- More time should be free inside of the loops, and outside of them as well.
- I might be able to just do a series of rom loops (6+ or so) for the different positions.
The things I need to work out or think about are:
- I will need to position the ball between rows of balloons. I will probably use a cycle 74 hmove with some time slicing to be able to still do stuff while the ball gets re-positioned. The player won't get covered up by a hmove line with a cycle 73/74 hmove, and I have a routine I wrote a while back where I can do the rough and fine position all it in 1 line.
- I might need a specific loop to do the 10 balloon oddball cases. This is not an extra balloon coming out of nowhere, it is where the balloon should naturally enter as it first appears, and is accounted for in the balloons that scroll across the screen.
- The very first balloon might be a headache to mask if the player is over it. It might need a specific loop as well as a extra strobe of RESP1 might be needed.