AWCTTYPA@UIAMVS.BITNET ("David A. Lyons") (03/25/88)
>Date: Sat, 19 Mar 88 02:19:09 GMT >From: Doug Gwyn <gwyn@brl-smoke.arpa> (Discussion: How could Fonts still work if the vertical resolution of the IIgs super-hires screen changed?) >The basic problem would be that the fonts are defined as bit-maps >and if the resolution were doubled the 10-point bit-map (for example) >would come out as 5-point on the display. As far as I know no nice provision has been made in the font format for stuff like this, but it wouldn't be that big of a problem. The Font manager could be changed to recognize old and new fonts, and for the old ones it would just have to draw each line twice on consecutive lines. >The programming problem >is more basic, in that the current GS display memory is contiguously >allocated and addressed by software on the assumption that there are >200 scan lines per screen. There was no allowance made for more, so >existing software could not find it. Well, any program that uses TOOLBOX CALLS ONLY to get at the display would have no trouble. Newer versions of QuickDraw (& other toolsets) would be provided in ROM &/or on disk, and they would set up a larger screen either by default, or at an application's request, or at the user's request through the control panel. It isn't quite true that no allowance was made for mor than 200 scan lines per screen. As long as toolbox calls are used rather than direct hardware stuff, it could work nicely. For example, an application could start up QuickDraw II and do a GetPortRect on the full-screen port to get the bounds rectangle for the port--then just subtrace the top from the bottom of the rectangle, and you know the screen height! If you need to fiddle with pallettes, use SetSCB and GetSCB (not stores and loads in the $E19E00 space). --David A. Lyons a.k.a. DAL Systems PO Box 287 | North Liberty, IA 52317 BITNET: AWCTTYPA@UIAMVS CompuServe: 72177,3233 GEnie mail: D.LYONS2