Vertical blank and Bobs

[geldo79]

Hi,

Up to now, I used a wait for vertical blank like

wait:

cmpi.b #$ff,dff006
bne.s wait

which worked just fine if i only used sprites. When using bobs, the bobs disappear somewhere near the bottom of the screen. I tried different methods which now work for the Bobs, but movements of the Sprites are not that smooth anymore. E.g. I use

wait:

move.l $dff004,d0
and.l #1ff00,d0
cmp.l #303<<8,d0
bne.s wait

Can someone explain this?

Greetings Christian

[Antiriad_UK]

Your first test was testing for vertical position 255. On a pal screen starting at the usual 44 ($2c) address in DIWSTRT that means you were waiting for a line that was actually about line 211 (in visible pixel terms) so still quite a way from the bottom of the screen. So would expect weirdness and disappearing BOBs, especially if you are clearing the screen.

The 2nd test is similar to one I've used and waits for 303 which is 259 pixel line which should work ok unless something else is amiss (your code could have passed line 303 before you make the test for example).

Edit: lots of variations here: http://eab.abime.net/showthread.php?t=51928

[a/b]

BNE generally works OK, but you have to be sure you won't miss the sync raster line. If you are using interrupts that can happen around sync line, or your code is very tight and also takes some variable amount of time and can leak out of a frame for a few raster lines, you might miss the sync and you will drop from 50fps to 25fps. So perhaps BLO/BLT would work better.
About the sprites, it depends what you are doing with them... Assuming auto-DMA mode, maybe in some frames, due to variable nature of your code, you are updating them too late, since your sync is now delayed by 303-255=48 raster lines, and the sprites best work when updated before the end of vertical blanking. Again, just speculating, depends on the rest of the code.

[geldo79]

But why do the sprites work perfectly using the wait for line 211? They do not disappear below line 211 as the bobs do.

[roondar]

Originally Posted by geldo79

But why do the sprites work perfectly using the wait for line 211? They do not disappear below line 211 as the bobs do.

What might help is understanding how sprites are drawn vs how bobs are drawn.

The main difference is that sprites are (normally) drawn automatically. That is, you simply tell the sprite hardware where you want to draw a sprite and what it has to contain and it will automatically get the correct parts of the sprite image from memory at the correct time to display it. Sprites are also never cleared on the screen, they simply show only at the position they are programmed (as if they're tiny movable layers on top of the screen). This means that changing a sprite's position or contents will (normally) never cause the sprite to not display or only display partially*.

Bobs meanwhile, are always drawn at whatever time during the screen update (beam position) the program says they need to be drawn. They also, unlike sprites, require you to clear/restore the old part of the screen first. These two things combined mean that drawing bobs is much more time sensitive. When you wait for the screen to hit a certain raster position and then start drawing you'll probably clear/restore the old bobs first. If this is done to a bob that overlaps the raster position you are waiting for, you can see the update process happen in real time. I.E. you might see the bob disappear because the clear/restore is (partly) done, but the drawing of the new bobs hasn't started yet. You might also see the bob display (partly) in the wrong colours if this happens to occur while the new bob is partly drawn.

Hope this helps explain it

*) Note that there are exceptions here: if you change a sprite's position or image data while the screen update is at the exact time part of the sprite is showing you will get part of the sprite at the old postion/with the old data and part of the sprite at the new position/with the new data. However, even then you won't remove the sprite, merely cause it to display in a glitched way.