Yes, this is why recreating Doom on the Amiga was so difficult. I remember wanting to play a Doom-like first person shooter back in my youth and being completely frustrated because the performance just wasn't there. It took several years before anything even close became available and by that time the world had moved on. I really think this limitation was one of the reasons that the Amiga faltered; it was a terrific platform in almost every single way, but it couldn't do first person shooters worth a damn. :(
Re:The Amiga Boing Ball Explained
by elektropionir on Sunday August 21, 2016 @12:47PM
(#12331553)
This also let you make "memory peekers". It was just a simple assembly program that would offset the pointer to a bitplane based on the mouse vertical movement. You could "look" at the RAM and it was one way to rip images since you would see the bitmaps of images from the game still in RAM after the reset.
Yeah, that was a great way to "visualize" chip RAM contents.
Curiously, on some later A500 OCS models, you could also see that into "slow RAM" expansion module range! Just needed to point bitplane pointers above 0x80000.
It appeared at 0xc00000 for the CPU and 0x80000 for chipset.
The offsets were measured in bits rather than bytes? That must have been a lot of engineering work.
If I remember correctly, the offsets were measured in words (16 bits on the M68k), and then you had scroll registers where you could offset with 0-15 pixels.
This was complicated a bit since you only had two scroll registers, one for even and one for odd bitplanes.
No idea how this was implemented in hardware.
Not particularly. Think of the display as a "stack" of monochrome one-bit-per-pixel images. Then bit offsets become completely natural.
You can have different offsets into each bitplane, which is why the grid could stay in the same place while the ball bounced.
The Amiga only supported bitplanes and not "chunky" modes like VGA where you have one byte per pixel. This made graphics with 256 colors (supported by the later AGA chipset) really slow as you had to do eight writes per pixel.
For a while there was a lot of competition between coders to write the best chunky to planar routine. This enabled you to write graphics effects with a chunky graphics buffer and then convert every frame on the fly to planar. One of the fastest was written by Kalms:
http://www.lysator.liu.se/~mikaelk/doc/c2ptut/