3 ms·

Changing a single pixel at a time wasn't a common operation in the 80s when the Amiga was popular. The main class of application that would have used single-pi

by phire 5y ago

Changing a single pixel at a time wasn't a common operation in the 80s when the Amiga was popular. The main class of application that would have used single-pixel modifications would be paint-style programs, and the cpu was generally fast enough to keep up with user input. There are advantages to planar graphics that can help applications too. Being able to dynamically change the number of bitplanes based on an application's color requirements both saves ram and increases cpu performance. It wasn't really until about 1992 that the lack of chunky graphics really became a liability, with the rise of 3D games like Doom and various multimedia applications, like streaming video off CD-ROM and more advanced productivity apps. If Amiga had actually delivered the AAA chipset in 1993 with it's various chunky graphics modes, maybe the platform would have survived.

rbanffy 5y ago
> single-pixel modifications would be paint-style programs Any app that draws a pixel as a single operation does that. In order to make this faster, you'll need to keep a bitmap to hold the image and then, maybe, use the blitter to render it to the screen. Bitplanes allow some tricks with games, when you split the planes into more than one playfield, or could even use it for windowing, putting the active window on one group of bitplanes above the rest so that you wouldn't bother to redraw windows because oclusion isn't destructive.
- phire 5y ago
  Yes, but I'm having a hard time thinking of many applications from the late 80s and very early 90s that required per-pixel control of the frame buffer. Text rendering is not done per-pixel, it's done in character sized blocks. Most UI elements at the time were tiled-based. You can do a lot with just blocks of pixels. And with anything that's done in large block (especially blocks that are multiples of 8 pixels wide), the per-pixel cost is atomized and becomes much less of an overhead.
  - rbanffy 5y ago
    If you are predominantly working with bitmaps, there aren't many reasons to operate on a pixel basis, but, take, for instance, drawing a line of n pixels. For a linear 8-bit frame buffer, you'll need up to n reads and n writes (because the 68000 had a 16-bit bus). For an 8-plane buffer (for the sake of simplicity), you'll need 8 times as many operations, one for each plane. If you know you'll be setting or unsetting a pixel in the same 16 pixel region, you can collapse those in-plane ops into a single write, but that requires some cleverness (like off-screen rendering to fast RAM).

by phire 5y ago

rbanffy 5y ago

> single-pixel modifications would be paint-style programs Any app that draws a pixel as a single operation does that. In order to make this faster, you'll need to keep a bitmap to hold the image and then, maybe, use the blitter to render it to the screen. Bitplanes allow some tricks with games, when you split the planes into more than one playfield, or could even use it for windowing, putting the active window on one group of bitplanes above the rest so that you wouldn't bother to redraw windows because oclusion isn't destructive.

phire 5y ago
Yes, but I'm having a hard time thinking of many applications from the late 80s and very early 90s that required per-pixel control of the frame buffer. Text rendering is not done per-pixel, it's done in character sized blocks. Most UI elements at the time were tiled-based. You can do a lot with just blocks of pixels. And with anything that's done in large block (especially blocks that are multiples of 8 pixels wide), the per-pixel cost is atomized and becomes much less of an overhead.
- rbanffy 5y ago
  If you are predominantly working with bitmaps, there aren't many reasons to operate on a pixel basis, but, take, for instance, drawing a line of n pixels. For a linear 8-bit frame buffer, you'll need up to n reads and n writes (because the 68000 had a 16-bit bus). For an 8-plane buffer (for the sake of simplicity), you'll need 8 times as many operations, one for each plane. If you know you'll be setting or unsetting a pixel in the same 16 pixel region, you can collapse those in-plane ops into a single write, but that requires some cleverness (like off-screen rendering to fast RAM).