Were there any Amiga games that were "racing the beam" the Atari2600 way?

[Dr.Venom]

The Atari2600 was known to "race the beam", because it had no memory for a video frame buffer (see for a nice explanation here: https://www.wired.com/2009/03/racing-the-beam/ )

It makes me wonder whether there were any Amiga games known to "race the beam" the Atari 2600 way, or did all Amiga games make use of a video frame buffer?

Hopefully someone with knowledge in this topic can share some insight?

I sort of came interested in this question after reading the Codetapper interview with Martin Pedersen (here: http://codetapper.com/amiga/interviews/martin-pedersen/). In the Battle Squadron section it is said:

Are there any technical tricks you were especially proud of in this game over Hybris?
It was still necessary to be clever about the time required to print the bobs, so when the raster was about 1/3 down the CRT, enemies in the top part of the screen stared being erased and reprinted. Then when the raster was 2/3 down, more enemies could be erased/printed. When the raster was below the bottom of the screen all enemies could be deleted/printed.
This avoids having to use double buffering, while still having about 1.5 frames to delete/print the bobs. Overall this saves a lot of processor time... that in turn could be used to have more enemies on the screen :-)

Is there anyone who can explain in plain English what is going on technically? I'm a bit confused, does it make use of a buffer while also (still) writing to that buffer while it is scanned out by the CRT, or what is really going on

[idrougge]

In case you mean "racing the beam" in the strictest Atari 2600 sense (only using sprites and copper), I know of no such cases. It doesn't make technical sense, even less so since the CPU speed is very variable on the Amiga.

What you see on every copper rainbow background is a similar phenomenon, though. The copper is tightly bound to screen positions and can do much the same things the 2600 could do by locking itself to the raster.

In case you mean locking screen updates (blitting) to various raster positions, that's not unusual, as stated by Martin Pedersen.

[Toni Wilen]

I only know some demos that "race the beam", for example vertical "copper" bar effect.

[Dr.Venom]

OK, thanks for the insights.

[Master484]

Is there anyone who can explain in plain English what is going on technically? I'm a bit confused, does it make use of a buffer while also (still) writing to that buffer while it is scanned out by the CRT, or what is really going on

It means that the screen is divided into 3 parts, and it draws new enemies to one part at a time, and does this immediately AFTER the raster beam has progressed past that part. Because the beam has already drawn the previous ( = current frame ) graphics to that part of the screen, it's now safe to erase those graphics and start drawing the gfx of the next frame. The changes only become visible during the next frame, when the beam passes that screen part again.

So this method doesn't "race the beam" but rather waits for it in ambush in three different points of the screen, and when the beam passes those points, it then starts making screen changes behind it, hoping to finish those changes before the beam reaches that part of the screen again.

If the changes were made fast enough, then good, but if not then you would see graphics flickering becasue the Unbuffering/Redraw process was "caught on tape". It's like a train on a circular track, where you replace the tracks behind the train, rather than in front of it, so in a way it does "race the beam", but in a more relaxed way.

[lordofchaos]

Originally Posted by Master484

If the changes were made fast enough, then good, but if not then you would see graphics flickering becasue the Unbuffering/Redraw process was "caught on tape". It's like a train on a circular track, where you replace the tracks behind the train, rather than in front of it, so in a way it does "race the beam", but in a more relaxed way.

Awesome analogy

[Tigerskunk]

@Master484: Nice explanation of this trick. Thanks. Will maybe use it in future...

[Dr.Venom]

Originally Posted by Master484

It means that the screen is divided into 3 parts, and it draws new enemies to one part at a time, and does this immediately AFTER the raster beam has progressed past that part. Because the beam has already drawn the previous ( = current frame ) graphics to that part of the screen, it's now safe to erase those graphics and start drawing the gfx of the next frame. The changes only become visible during the next frame, when the beam passes that screen part again.

So this method doesn't "race the beam" but rather waits for it in ambush in three different points of the screen, and when the beam passes those points, it then starts making screen changes behind it, hoping to finish those changes before the beam reaches that part of the screen again.

If the changes were made fast enough, then good, but if not then you would see graphics flickering becasue the Unbuffering/Redraw process was "caught on tape". It's like a train on a circular track, where you replace the tracks behind the train, rather than in front of it, so in a way it does "race the beam", but in a more relaxed way.

This what I was looking for, thanks for the great explanation.