Hello

Anyone have any nice tips for preventing the dreaded sprite flicker?

'Forcing' to two frames?
Alternate update on frames? (eg update player one frame, enemies the next, and so on)

I seem to have forgot how little time you actually have on the BBC to do your thing

Can't find the article now but there was some discussion on STH forums about best time and way to do your graphics for least flicker.

i.e. plotting by Y pos on screen. So plot the ones near the top first. Also perhaps setting a timer to trigger plotting at the top when the raster has just started slightly below top might give you even more time.

I don't know how feasible it is to do it on a BBC B, but on a Master you can double buffer the screens to reduce the flicker. In other words, do your sprite plotting on a logical (non-displayed) screen and then swap it with the physical (displayed) one.

Kind regards,

Francis.

Not possible on a standard beeb I think, as (may stand corrected here) but the screen must always end at address $7FFF, as that's how the hardware works to start wrapping around to the start of the screen again. So even if you used a 10K (or less) screen you couldn't make it swap between one that ends at &7FFF and one that doesn't.

On the Master and Beebs with shadow screen ram the circuits are designed so that when swapped in they inhabit the right part of memory and can never co-exist with the normal screen ram in main ram at the same time.

Hmm sadly not applicable on the BBC, I can barely afford the memory for one framebuffer, let alone two

Well... it's perfectly possible to do double-buffering, but of course the proviso is that you don't do any hardware scrolling. Onslaught (the game I never finished, over on Lost & Found in STH) uses two 8k Mode 5 screen buffers - one at &4000 and one at &6000 - to allow me to do a software scroll of a window and move a large number of sprites and particles with no flicker. There are other games which also do this, e.g. Repton Infinity, Bonecruncher, Predator.

All these games redraw their entire playing area each time (to account for the new scrolled position) which is an easier approach than trying to keep track of where the old sprites were two frames ago and erasing only them, but it's at the expense of speed - which is why the frame rate of these software scrolled games is normally not as good as their hardware-scrolled counterparts!

Ahh, stand corrected Strange as it may seem I've only ever done hardware scrolled code and knew when the 6845 hit &8000 it went back to the start. Thought that would apply elsewhere

Sorvad: Cheers for that STH tip, I found it and got rid of my flicker. I used the method of IRQ timers to set my 'vsync' just after I'd drawn the last bit of my game area, rather than at the end of the total frame.

Thanks really should go to Rich of course, since he posted the article!

Linkage here

Rather than linking code like this to various posts they should really be added to the "Sample Code" section of this site for easier reference.

Kind regards,

Francis.