Very cool stuff. Trying to figure out how various classic (mostly Sega Genesis, in my case) games pulled off their graphical effects was endlessly entertaining as a teenager. It's a shame that the art of cycle-accurate raster techniques had to die, but it's probably for the best that it no longer takes a savant to make games with rotating sprites ;)
Here's a relevant explanation of some of the techniques that classic "pseudo-3D" racers used:
Indeed. But it wasn't that difficult. Actually I found it way easier with the "fake 3D" and rotating sprite and even "full screen rotating" (but it's only vertical columns of 8-pixels wide that are slightly shifted up and down) than doing "real" 3D using OpenGL or DirectX ; )
Applied on the PC in the nineties, in "World Rally Fever", published by Team 17:
Its amazing how much knowledge and skill was needed to do even simple computer graphics in the 90ties.
Even today if you create a game, you will need to work alot more with Math and complicated algorithms than in your typical web/mobile app where its much more about architecture/design, getting data from X to Y and presenting it in a good way instead of the complex algorithms needed in game development.
Its fascinating, but sadly doesnt pay the bills for most people.
The "copper" is the graphics coprocessor. The "copper list" is the machine code executed by this processor. On the Atari 800 this was called the display list.
When you made a game for these systems, you wrote two programs in two different assembly languages: one for the CPU and one for the graphics processor.
The two chips would sort of run in parallel, interleaving their access to main memory. Programming them was a lot fun.
I'm not as knowledgeable about the Amiga as I am about other classic systems, but the Copper was (according to Wikipedia) a component of the Amiga's graphics coprocessor that took very simple commands that one could make "programs" out of that would update video registers at times synchronized to the rendering of the display.
Back in the day, most cool graphical effects were done by using the CPU to update video memory at the precisely timed moments during the rendering of a frame. For example, if you changed the "scrolling speed" of a background between the drawing of every line, you could get a nifty "parallax scrolling" effect out of a machine with only 1 background layer. Or, you could change a color palette halfway through the screen to make it look like that part was underwater.
Some systems had interrupts that would fire in-between the drawing of lines to facilitate this. Other, simpler ones, like the NES and the C64, basically required the programmer to write perfectly timed, cycle accurate code that would poke the right values into video registers within a very small timing window.
The Amiga had a number of custom chipsets to make it easier to produce effects like this, and free the CPU from spinning idly and poking registers all the time. Looking at the wikipedia summary of its capabilities, I imagine console game programmers of the time would have killed for the ability to say "please write this value here at this exact moment, thank you."
It reminds me a bit of the SNES's HDMA (horizontal interrupt DMA) function, which allowed programmers to specify tables of data to be copied to certain VRAM registers in between the rendering of scanlines. Pretty much every SNES game with cool "mode 7" effects relied heavily on it.
There is a reason that classic game developers don't become front-end web developers. We've already dealt with bitchy little machines that demand precise instructions to get the flashy results we want out of them, why do we want to do that all over again for a web browser? :)
Before most of us had an idea what a coprocessor was, or independent GPUs, we approached the copper (blew my mind when a month after deving for the Amiga I figured out that copper was being used as a diminutive of co-processor) as a brain-dead but stupidly fast CPU with only three instructions.
NES does not have a true scanline interrupt, but it had this weird sprite #0 hit flag. The flag is set if the sprite #0 contains non-transparent pixels, and it overlaps something on the background. When the PPU hits the first pixel where those conditions are true, it sets a bit and fires an non-maskable interrupt. This way you could do once per frame scanline detection for split screen effects, but you still have to time your code correctly, as NMI handling is not clock accurate, and neither is the actual sprite #0 hit detection.
For more advanced effects, Nintendo developed mappers for their cartridges, calles memory management controllers, which increased cartridge memory with banking, and also added custom interrupts and features. MMC3 contained a scanline counter which makes it possible to do fun effects with NES. Megaman 3 to 6 used MMC3.
I'm really just a beginner with NES programming, so I hope there is no significant factual errors in that.
The copper was a video-sequencing co-processor that lived as part of the Agnus chip. A copperlist is a sequence of copper instructions that would execute in parallel with the main processor. Please see:
Well it was a dedicated coprocessor which was synched with the "VBL" (vertical blank line).
So you could do all kind of nifty tricks, like changing the colors of your 5-bitplanes (32 colors) between lines, creating an image with much more than 32 colors.
Using 32 colors per line was easy : you could even change in the middle of a line but that was getting complicated.
One easy trick with the copper was to change the background color at each vertical line. Because the background color did extend to the far left and the far right of the screen, you could create a "copper line" and several copper lines (typically containing a gradient) would create a "copper list".
People don't realize just how smooth these 2D games running at 50 or 60 frames per second and synched with the vertical blank lines were.... 25 years ago!
The Atari ST was quite a beast too but it didn't have these great coprocessors the Amiga had.
(You may know some of this already, but for the benefit of everyone else...)
The original Amiga chipset only had 12-bit colour, so instead of 8 bits per channel there were 4, and you had 4096 colours, not 16.7M. One thing I did was create a copper bar (the "copper line" gradient you mention) where every second line flickered between the colour above it and the colour below it. This let me create 31 blues instead of 16. It looked pretty good at 60Hz.
The Amiga hardware was designed for 32 display colors - which doesn't seem like much today, but at the time was up against Herculese monocrome, CGA, and B&W Macs.
The system could be hacked to display 64 colors fairly easily. Getting all 4096 was a bit more complicated and required using HAM mode (hold and modify).
The technique allowed the 32 display colors to be reset for each scan line. With careful attention an artist could create a better image by adjusting the pallet scan line by scan line. IIRC one lost the ability to use the hardware sprites and HAM mode was never used for games, just static images.
No, that's just a normal 5 bitplane display mode with a copper trick. Real original 6 bpl HAM didn't need copper, it depended on current beam position left side pixel. For each pixel right side you could either set all RGB to one of 16 color palette OR modify red, green or blue value, but otherwise 'copy' left side pixel color.
So say you had white (15,15,15) pixel left side. Current pixel 'color'-data is "modify red 7", thus pixel becomes (7, 15, 15). Green and blue color components were held from left side pixel.
It was important to select those 16 paletted reset colors carefully for maximal effect. Otherwise you'd get a lot of ugly 2 pixel horizontal streaks when multiple color components changed from horizontal pixel to another quickly. You could of course use copper to change that 16 color palette for each scanline, too.
The big problem for Amiga programmers was that the Amiga was sold in NTSC and PAL versions, which ran at different framerates (50 and 60hz) with different resolutions. While PAL Amigas could play NTSC games (and most TVs could render the screen properly) I don't remember it working the other way around (although I could be wrong - any American miggy owners care to correct?).
Anyway, consequently things like funky horizontal copper manipulation relied on the Amiga either running in NTSC or PAL mode, but not both. This is why a lot of people would use the copper for gradients on the earlier Amiga 500 games, that and the fact that a lot of earlier Amiga 500 games were ports of ST code.
NTSC Amigas could play PAL games, but the bottom of the screen was overscanned/truncated off the bottom of the screen, and the gameplay and music was usually 20% faster.
Here's a relevant explanation of some of the techniques that classic "pseudo-3D" racers used:
http://www.extentofthejam.com/pseudo/
https://news.ycombinator.com/item?id=5045756