Timeline for Why was OCS low resolution limited to 6 bitplanes?
Current License: CC BY-SA 4.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 19, 2018 at 1:55 | comment | added | Sagan Android | I don't care if the term CLUT has spread throughput the field. It's really not accurate. These were registers, whose contents were selectively gated out. There is no "looking up"; the effect happens in a single clock cycle. But fine, use Wintel terminology, or Atari terminology like "software sprite". And yes, the PC world thinks everything is a sprite now. Much like javascript programmers. | |
| Nov 19, 2018 at 1:47 | comment | added | Sagan Android | > "768×566 pixel “adds up to 54,336 bytes”— for a single bitplane. If you wanted 256 colors for that, you’d need >400kiB," I thought my meaning was obvious. The claim that there's some 32K limit is absurd, since even a single planar screen can be almost twice that alleged 32K limit. If you look at the original question, it's about 8 planes in Low_Res. The target is low-res. > "but that would be the maximum that no one would exploit in practice." I can think of several applications where "overscan" (a bad euphemism) was used with both NTSC and PAL laced modes. | |
| Nov 17, 2018 at 8:21 | comment | added | Valentino Miazzo | I don't really like answers like this directed against another answer/user | |
| Nov 12, 2018 at 8:12 | comment | added | Holger | 768×566 pixel “adds up to 54,336 bytes”— for a single bitplane. If you wanted 256 colors for that, you’d need >400kiB, but that would be the maximum that no one would exploit in practice. Let’s start with a conservative approach instead: 320×200×6 need 48kB, raising it to 8 planes would need 64kB. You are right in that four planes in Hires mode need the same amount as 8 planes in Lores (640×200×4 is 64k too), but that only allows the conclusion that this Hires mode was not really planned in the original 32kiB design. But of course, it was easier to add when the memory restriction was lifted. | |
| Nov 12, 2018 at 4:30 | comment | added | Tommy | @Jules if he didn't mean sprites as a hardware feature (as I'd assumed because the Amiga hardware is so much more capable than the reductive sprite/tile stuff of that era of consoles) then I'm at a greater loss: if a sprite is anything that may move, and modelling everything as a sprite is "crass" then the complaint is... foregoing optimisation of static objects? That would be the exact opposite mindset to those likely to use a software lookup table, those being usually about precomputation. I'm just going to conclude that the complaint is ill-defined. | |
| Nov 11, 2018 at 21:52 | comment | added | Jules | @Tommy - I believe the "everything is a sprite" line is a dig at the many game-oriented graphics libraries starting from the mid-80s and onwards that use the word "sprite" to refer to anything that is designed to move around the screen rather than be static (a tendency I first encountered along with this Forth implementation) rather than something that the hardware provides an ability to automatically move. | |
| Nov 11, 2018 at 14:58 | comment | added | Tommy | Besides lookup table clearly being correct in context — it exactly is one extra level of indirection, e.g. where RGB values are looked up — I'd be surprised if many of your imagined people "who think that everything is a sprite" come from the world of the PC, being notably a platform that doesn't provide sprites. | |
| Nov 11, 2018 at 9:00 | comment | added | Jules | Also, note that you're looking at the publicised information from 1984 -- but the development of the Amiga began back in 1982. Decisions were made before there was any public knowledge, and there were substantial changes in the market in the interim -- DRAM prices were much lower in 1984 than 1982, and more importantly the target market had changed substantially: something that could only function as a games machine was considered a viable product in 1982, but in 1984 being a useful desktop computer was absolutely essential. Original target resolution was 320x240, not full-res NTSC/PAL. | |
| Nov 11, 2018 at 8:34 | comment | added | Jules | "lookup table" is a common phrase used to indicate a memory block used to translate an input (used as the address) to an output (the value stored in the memory), which seems to be exactly the context that it's being used in here. CF "LUT" (an abbreviation of lookup table) as used in FPGAs. I don't see how this is any different to the technique used in PC graphics hardware that supported modifiable pallets, e.g. EGA, so I'm not sure what exactly you're getting at here. | |
| Nov 11, 2018 at 6:00 | review | Late answers | |||
| Nov 11, 2018 at 10:22 | |||||
| Nov 11, 2018 at 5:45 | review | First posts | |||
| Nov 11, 2018 at 7:16 | |||||
| Nov 11, 2018 at 5:42 | history | answered | Sagan Android | CC BY-SA 4.0 |