Computer design: Bitplanes, Playfields, Sprites
From a purely algorithmical point of view these are things of the past, and as far as the bitplane concept is concerned, I'd say that choosing palettes of 1024 or more colours is a job that nobody would like to do.
Of course, one might consider different kinds of automatic assignments building up on a basic set of 256 manually chosen colours or so, but the merits of this approach are doubtful at best.
Sprites and playfields on the other hand, if not necessary and introducing arbitrary limitations, are still great fun, especially if every each of their pixels would contain 8 bits for setting the transparency level.
The things you could do almost effortlessly, like airplanes seen through a layer of clouds etc.
So, for fun's sake, why not allow 5 playfields, 4 of which would have transparency levels, and 60 sprites of maximal size of half (half the width) of the screen, each with variable transparency?
Of course you'd need to define their position on the z-axis. The easiest way to do it is by simply writing their position in a byte reserved for each object, however, possibly even more fun would be to define the position for every pixel separately, assuming that RAM and data flow capacities are no object, after all 6 extra bits would suffice.
Assuming we did that, 6 bits for position, 8 bits for transparency, that would leave 18 bits for RGB in a 32 bit word, so 6 bits or 64 degrees for red, green and blue, a total of 262144 colours. In my opinion good enough. The background playfield would of course simply have 24 bits for RGB. (It might also have an alpha channel for external applications.)
The graphic memory should be at fixed positions, only in case of the sprites it should be allowed to choose the memory for each sprite from the list of sprite memory areas, i.e. allow that several sprites show the same graphic. In order to allow hardware scrolling, though this isn't particularly important, simply let every playfield have an x-offset and y-offset register, from where it starts being read and wrapped accordingly.
Of course, one might consider different kinds of automatic assignments building up on a basic set of 256 manually chosen colours or so, but the merits of this approach are doubtful at best.
Sprites and playfields on the other hand, if not necessary and introducing arbitrary limitations, are still great fun, especially if every each of their pixels would contain 8 bits for setting the transparency level.
The things you could do almost effortlessly, like airplanes seen through a layer of clouds etc.
So, for fun's sake, why not allow 5 playfields, 4 of which would have transparency levels, and 60 sprites of maximal size of half (half the width) of the screen, each with variable transparency?
Of course you'd need to define their position on the z-axis. The easiest way to do it is by simply writing their position in a byte reserved for each object, however, possibly even more fun would be to define the position for every pixel separately, assuming that RAM and data flow capacities are no object, after all 6 extra bits would suffice.
Assuming we did that, 6 bits for position, 8 bits for transparency, that would leave 18 bits for RGB in a 32 bit word, so 6 bits or 64 degrees for red, green and blue, a total of 262144 colours. In my opinion good enough. The background playfield would of course simply have 24 bits for RGB. (It might also have an alpha channel for external applications.)
The graphic memory should be at fixed positions, only in case of the sprites it should be allowed to choose the memory for each sprite from the list of sprite memory areas, i.e. allow that several sprites show the same graphic. In order to allow hardware scrolling, though this isn't particularly important, simply let every playfield have an x-offset and y-offset register, from where it starts being read and wrapped accordingly.
Labels: 04, computer design
Eingetragen Am/um
14:13
