jms@tardis.Tymnet.COM (Joe Smith) (08/11/90)
In article <35188@ut-emx.UUCP> mjl@emx.UUCP (Maurice LeBrun) writes: >The only thing I'm less than happy about is that there is a lot of >flicker when scrolling multi-color text (say, blue mixed in with >black, using the standard 2.0 colors) on a 7xx by 4xx screen through >the de-interlacer (can't really say 'interlaced' any more, I guess). >I have a feeling this has more to do with limitations of the blitter >performance than anything else (is this right?). Right. If you have a bunch of blue text on a gray background (such as from the 'ls' program), the text changes colors temporarily as the blitter processes the two bit planes one at a time. After the first blit, the text has moved up one line, but is black on gray. Where the text used to be is white on gray. This mishmash stays visible until the blitter finishes with the 2nd bit plane, changing the white to gray. I made a suggestion to get around this problem, and Jim Mackras seemed to get excited about it. (What is jimm doing, these days?) It would require a change in the way that the console device allocates its bitmaps, and needs the ECS Agnus (for blits wider than 1024 bits). Instead of allocating two 32,000 byte bitplanes for a 640x400 window, allocate a single 64,000 byte chunk, arranged as 1280x400 bits. Define the modulo of the rastport to by 80, so that the first line of the first bitplane is in bytes 0 thru 79, the second line is 160 thru 239, etc. Define the second bitplane so that its first line is bytes 80 thru 159, etc. But when it comes to scrolling the rastport, pretend that it is a single bitplane, 1280 pixels wide. Instead of scrolling all the bytes for the first bitplane before starting the second, the blitter would scroll all the bytes for the first 8 lines of both bitplanes, then all the bytes for the next 8 lines of both bitplanes, etc. Doing this on a custom screen should be trivial. Doing it on the Workbench screen requires that both Workbench and the console.device use this single double-wide (or triple-wide) bitmap. -- Joe Smith (408)922-6220 | SMTP: jms@tardis.tymnet.com or jms@gemini.tymnet.com BT Tymnet Tech Services | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms PO Box 49019, MS-C41 | BIX: smithjoe | 12 PDP-10s still running! "POPJ P," San Jose, CA 95161-9019 | humorous dislaimer: "My Amiga speaks for me."
lshaw@walt.cc.utexas.edu (logan shaw) (08/12/90)
In article <1180@tardis.Tymnet.COM> jms@tardis.Tymnet.COM (Joe Smith) writes: [stuff about color freaking as >1 bitplane things are scrolled] >It would require a change in the way that the console device allocates >its bitmaps, and needs the ECS Agnus (for blits wider than 1024 bits). >Instead of allocating two 32,000 byte bitplanes for a 640x400 window, >allocate a single 64,000 byte chunk, arranged as 1280x400 bits. >Define the modulo of the rastport to by 80, so that the first line of the >first bitplane is in bytes 0 thru 79, the second line is 160 thru 239, >etc. Define the second bitplane so that its first line is bytes 80 thru >159, etc. But when it comes to scrolling the rastport, pretend that it >is a single bitplane, 1280 pixels wide. >Instead of scrolling all the bytes for the first bitplane before starting >the second, the blitter would scroll all the bytes for the first 8 lines >of both bitplanes, then all the bytes for the next 8 lines of both >bitplanes, etc. What? Why not just do it like this: for scanline = 1 to however_many_scanlines_there_are { for bitplane = 1 to however_many_bitplans_there_are { blit_a_single_scanline (); } } That would _not_ require the neato Agnus, and would not take any longer, and would make that neat effect where the top of the screen has scrolled already a little bit and the bottom hasn't yet and it's scrunched a little, which is certainly better than messed up colors. In other words, do it in bitplane major order instead of scanline major order. Actually, it might be slight more efficient to scroll as much as you can of the first bitplan (depending on the Agnus), as much as you can of the next bitplane, and then go back to the first bitplane. However, this may be what they already do, but since the new Agnus can blit so much, it causes color mess ups. So, you could limit the size of the areas it blits to 1/number_of_bitplanes*some_constant, so it won't get confused. >Joe Smith (408)922-6220 | SMTP: jms@tardis.tymnet.com or jms@gemini.tymnet.com >BT Tymnet Tech Services | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms >PO Box 49019, MS-C41 | BIX: smithjoe | 12 PDP-10s still running! "POPJ P," >San Jose, CA 95161-9019 | humorous dislaimer: "My Amiga speaks for me." ============================================================================ "The beauty queen, clevely clad, Logan Shaw admires herself in a cigarette ad. lshaw@ccwf.cc.utexas.edu Will she admit that all was in vain ======================== when the face in her mirror cracks like a windowpane?" -Elim Hall, _Things_Break_
jms@tardis.Tymnet.COM (Joe Smith) (08/26/90)
In article <35790@ut-emx.UUCP> lshaw@walt.cc.utexas.edu (logan shaw) writes: >What? Why not just do it like this: > >for scanline = 1 to however_many_scanlines_there_are > for bitplane = 1 to however_many_bitplans_there_are > blit_a_single_scanline (); > >That would _not_ require the neato Agnus, and would not take any longer. Blitting 400 lines one line at a time takes a lot longer than doing all 400 in a single blit. My guess is that it would take at least 10 times longer. One of the arguments for not using the blitter (as opposed to a tight loop running on a 68020) is that it takes several milliseconds to wait for the blitter to finish its previous operation and then set up all the parameters for a new blit. -- Joe Smith (408)922-6220 | SMTP: jms@tardis.tymnet.com or jms@gemini.tymnet.com BT Tymnet Tech Services | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms PO Box 49019, MS-C51 | BIX: smithjoe | 12 PDP-10s still running! "POPJ P," San Jose, CA 95161-9019 | humorous dislaimer: "My Amiga speaks for me."