boing wrote:
This is another example where engineers need to be working on implemention MORE sprites and playfields, not less. Fancy blitter engines are great, but not's let put all our graphics eggs in one basket.
Not TRUE transparency (gradient controls) as requested here but it is cool:
I like "drag with window contents in realtime" but was unhappy with the programs out there that added this to the Amiga. They used the Blitter and I wasn't happy with the chipmem usage but most of all I was appalled at the number of bus cycles wasted. That's where the idea came from for this...
I had planned on writing a program that would allow you to move/render public windows/screens to another playfield, which you could then overlay anywhere onscreen. Or underlay. For OCS, ECS, and AGA. Some color limitations apply- mostly on OCS/ECS. I had planned options to render it's contents to the main screen (wherever you drop the window), and only use the playfield for dragging the window [so as not to suck bandwidth on older OCS/ECS machines]. In other words, the playfield would optionally only be in use during a drage or move. This can reduce chipmem bus sage under many circumstances.
Anyway the cool thing is that you also get real-time window dragging along with it, virtually for free, sans the usual blitter/cpu bus load. Mind you, a large Shell on an A1000 in Hi-Res mode can mean you'd start to feel a bit sluggish (but not as bad as the current ways of creating "drag with content" windows for pre-AGA Amigas).
I never got to it, and have no IP or patent on the idea (software patents are evil) so if any of you want to build on it, go ahead.
Sprites and Playfields rule. Adding tranparency in hardware is fairly easy if you already have genlock/sprite/playfield circuitry. And... that ain't gonna happen. We'll all be using off the shelf cards that lack sprites.
The reason sprites aren't used in PC-style graphics chipsets is that there is no left border available for the graphics chipset to load in oodles of sprites. Most graphics chipsets support ONE sprite for the mouse pointer and not more for that reason.
I do agree, though, that blitter-based solutions waste bus cycles by writing everything to the framebuffer instead of piping the results of the blits straight to a queue on the video DAC.
