I enjoyed reading the discussion about sprite tearing in the diary. Using the palette as a timer is a nice trick, it has to be said.

I'm not sure that Jungle Journey has any tricks you can use to avoid tearing. Instead of unplotting sprites, moving them and plotting them again, I used a buffer to record where sprites need to be (un)plotted and just try to blast through them all as soon as possible after the vertical refresh. You can still see cases of flicker near the top of the screen. I arguably overcomplicated things with that approach.

Yep, another possibility is to sort by y position and unplot/replot each one in order starting from the moment that the CRT raster reaches the bottom edge of your playing area. That works as long as your sprite routine goes fast enough that the raster beam doesn't catch up with you.

Exile has a nice trick. Its sprite routine is very complicated - the sprite data is only 2 bits-per-pixel (4 colours), but it is plotted to a MODE 2 screen, where each colour from the sprite data can be rendered in any screen colour, and the sprite can be plotted at any horizontal pixel position. This is not the fastest routine, and would ordinarily lead to huge amounts of flicker, but what Exile does is unplots the old sprite and plots the new one simultaneously, byte-by-byte. Clever, but very tricky to get working properly, particularly when the old frame and the new frame don't match, e.g. if one of them is clipped off the side of the screen.

Yeah I think I made it as fast as possible by not using masking or XORing but blatting the new sprite directly over the old one and then drawing a small rectangle in the background colour if you had moved up, down, left or right. Of course with the hardware scroll moving you are effectively moving all the time. That way I was getting the rainbow for free as it sat at the end of the sprite.

I'm surprised how long it took to draw the sprite - it was large at 18x42 bytes - but not that large I thought - I tried Steve O'Learys self poking routine to start
http://www.retrosoftware.co.uk/wiki/index.php/Basic_Sprite_plotter
and then tried another like:

with the loops unrolled. Which was surprising a little faster. I figured the self poking method would take too many fixups if I unrolled it.

It's a real shame the video hardware can't double up the lines - that would have saved me cycles and memory!
And the screen BBCs screen arrangement is a total pig - I remember it putting me off back in the day. The Atari800 on the other hand is nice and linear...

- PJ

for Jeltron, http://www.retrosoftware.co.uk/wiki/index.php/Jeltron most of the sprites have a blank area around them, allowing them to just be blatted - this works except where they touch the slower paralax layer (which they would not do if we had designed proper alien paths).

We also use a timer to start drawing at the bottom of the play area - just after switching the palette to draw the scoring area.

We have no tearing or flicker except where the blanking area of a sprite syncs with a star behind it.

If you can put up with mode 5+4 and 128x128+256x32 for a play area + UI, you can draw quite a lot - about 2/3 the play area.

We also did a few bit twiddling tricks to ld/st or ld/or/st per char to reduce rendering times and remove flicker.

Richard

Hey that's really cool - source code as well - for some reason I'd missed it the first time... have to study it now.
-PJ