eraps2@aspvax.UUCP (09/17/87)
Hi all,
Could someone post a summary of overscan to the net. I looked through
the RKM manuals, the hardware reference, and intuition manuals and was
unable to ascertain how to use it. Also, is there some special way to
code so that my programs will be compatable with overscan screens? If
this is described somewhere, please tell me where.
Also, I have been trying to think of an elegant way to handle blinking
text in a program. The best way I can think of to do this is to use
and extra bit plane and have a periodic function (hooked into VBLANK
maybe) that alters the color map for the screen. Any suggestions?
- Thanks
"We want information ... information" Rob Ginn
- No. 2 ...burdvax!jtids!aspvax!eraps2
eraps1@nadc.arpahobie@sq.uucp (Hobie Orris) (09/22/87)
eraps2@aspvax.UUCP writes: > >Hi all, >Could someone post a summary of overscan to the net. I looked through >the RKM manuals, the hardware reference, and intuition manuals and was >unable to ascertain how to use it. Also, is there some special way to >code so that my programs will be compatable with overscan screens? If >this is described somewhere, please tell me where. > >"We want information ... information" Rob Ginn > - No. 2 "You'll not get it!" - No. 6 Overscan cannot be summed up, since it is unofficial and its usage is varied. DPaint 2 uses 672x444 for hi-res overscan because Dan Silva devel- oped it on a buggy Workbench that crashed if he tried anything bigger. Aegis uses 704x480 (?) which works, but is wasteful. I find that the best dimensions for overscan (as used in PageFlipper 1.0) are 352x222 for lo-res and 704x444 for hi-res. Other resolutions use combinations of these values. These have been confirmed by my testing to be the best combinations for filling the screen with a minimum of wasted memory. So first you want to open a screen with these dimensions and then you want to push it up and to the left so there are no unsightly borders on the left (as in DPaint 2 "full video") and on the top. This is the trick: BigScreen->ViewPort.DxOffset = -16; /* push 1 word left */ BigScreen->ViewPort.DyOffset = -12; /* yank it up a little */ MakeScreen(BigScreen); RethinkDisplay(); This works great if you use Intuition. If you don't, then you're on your own. When you do this your pixels are still numbered from zero (don't need negative offsets!) so that's no sweat, but your menus will be off the screen, and the pointer will not point to them like it did in the good old days, so it might be a good idea to re-do your pointer so it's offset too. I would like to see some overscan standard thrashed out and observed by developers, and blessed by the Commodore (you know the one!). I submit this as a starting point. So let's argue :-) Hobie Orris | Jesus was a leprechaun guest of SoftQuad Inc., Toronto, Ont. | A twinkle in his eye {ihnp4 | decvax | ? }!utzoo!sq!hobie | Always smiling sweetly | But he never expected to die. | - Snakefinger
dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/23/87)
Overscan is a boon in many respects. Since there is no standard overscan resolution, programmers who want to take advantage of it usually create software which conforms to a particular user's screen size. This also gives programmers more of an incentive to support PAL screens (or PAL programmers to support US screens) which is inherent when you make the GetScreenData() call. The only possible screwup occurs when a program does NOT check the size of the workbench screen before openning an overscan screen. -Matt