lang@rex.cs.tulane.edu (Raymond Lang) (08/08/90)
How do you set up an offscreen grafport in Orca/Pascal for an image that is larger than the screen (i.e., greater than 640 pixels across by 200 pixels in height)? Thanx in advance Ray lang@rex.cs.tulane.edu
dlyons@Apple.COM (David A. Lyons) (08/10/90)
In article <3980@rex.cs.tulane.edu> lang@rex.cs.tulane.edu (Raymond Lang) writes: >How do you set up an offscreen grafport in Orca/Pascal for an image >that is larger than the screen (i.e., greater than 640 pixels across >by 200 pixels in height)? For general information about off-screen grafports, see "Math" and "DTS Libraries and Tools" in Apple IIgs Source Code Sampler volume 2, and the QuickDraw documentation. In summary, you need to allocate memory for the off-screen pixel map, open a new grafport by calling OpenPort on a 170-byte chunk of memory, and use SetLocInfo to set up the locInfo record of your grafport to refer to your pixel map. -- David A. Lyons, Apple Computer, Inc. | DAL Systems Apple II Developer Technical Support | P.O. Box 875 America Online: Dave Lyons | Cupertino, CA 95015-0875 GEnie: D.LYONS2 or DAVE.LYONS CompuServe: 72177,3233 Internet/BITNET: dlyons@apple.com UUCP: ...!ames!apple!dlyons My opinions are my own, not Apple's.
jonah@amos.ucsd.edu (Jonah Stich) (08/10/90)
In article <43826@apple.Apple.COM> dlyons@Apple.COM (David A. Lyons) writes: >In article <3980@rex.cs.tulane.edu> lang@rex.cs.tulane.edu (Raymond Lang) writes: >>How do you set up an offscreen grafport in Orca/Pascal for an image >>that is larger than the screen (i.e., greater than 640 pixels across >>by 200 pixels in height)? > >In summary, you need to allocate memory for the off-screen pixel map, >open a new grafport by calling OpenPort on a 170-byte chunk of memory, >and use SetLocInfo to set up the locInfo record of your grafport to >refer to your pixel map. Okay, I've been bitten by this before, so I just thought I'd chip in and warn you before you havev this problem, too. When you open a grafPort this way it sets up a visRgn that is the size of the screen. If you want to do things in this grafPort (I've had problems drawing text) you have to make the following call sequence: NewRgn OpenRgn (FrameRect, whatever...) CloseRgn SetVisHandle This is because, as it says in vol II of the TB Ref., drawing is clipped to the visRgn. Also burried in there is that the visRgn is handled by the window manager when the grafPort is associated with a window, but when it's not, it's up to you to take care of it. If you don't, you'll have problems with strange clipping. :( Also make sure that you get the port rect set properly. Hope this has helped! >David A. Lyons, Apple Computer, Inc. | DAL Systems Jonah
jsurine@entec.Wichita.NCR.COM (James Surine) (08/10/90)
In article <3980@rex.cs.tulane.edu> lang@rex.cs.tulane.edu (Raymond Lang) writes: >How do you set up an offscreen grafport in Orca/Pascal for an image >that is larger than the screen (i.e., greater than 640 pixels across >by 200 pixels in height)? >Ray >lang@rex.cs.tulane.edu The only resriction I have found in creating offscreen bitmaps is that some of the Quickdraw commands like copybits don't work if the total bitmap is larger than 32K (they're using stupid 16 bit integers again). For actual code, I've got some at home and will mail you a copy later. -- +=+ +=+ +=+ +=+ +=+ +=+ +=+ +=+ +=+ +=+ +=+ +=+ +=+ +=+ +=+ +=+ +=+ +=+ +=+ +=+ j.surine@Wichita.NCR.COM (Jim Surine) /\/\/\/\/\ NCR Peripheral Products Division, Wichita Kansas / / /\/\/\ \ \ work (316) 636-8586 home (316) 721-6280 / / / / /\ \ \ \ \
toddpw@tybalt.caltech.edu (Todd P. Whitesel) (08/10/90)
dlyons@Apple.COM (David A. Lyons) writes: >In summary, you need to allocate memory for the off-screen pixel map, >open a new grafport by calling OpenPort on a 170-byte chunk of memory, >and use SetLocInfo to set up the locInfo record of your grafport to >refer to your pixel map. WHOA... is that 170 GUARANTEED or is there a better way to do it that doesn't require us to hard-code how big the grafport record should be? I loath hardwiring constants into my program and I prefer to avoid it whenever possible. Todd Whitesel toddpw @ tybalt.caltech.edu
mattd@Apple.COM (Matt Deatherage) (08/11/90)
In article <12237@sdcc6.ucsd.edu> jonah@amos.ucsd.edu (Jonah Stich) writes: >Okay, I've been bitten by this before, so I just thought I'd chip in and warn >you before you havev this problem, too. When you open a grafPort this way >it sets up a visRgn that is the size of the screen. If you want to do things >in this grafPort (I've had problems drawing text) you have to make the >following call sequence: > >NewRgn >OpenRgn >(FrameRect, whatever...) >CloseRgn >SetVisHandle > >Jonah You'll probably find SetRectRgn to be a whole lot easier. -- ============================================================================ Matt Deatherage, Apple Computer, Inc. | "The opinions represented here are Developer Technical Support, Apple II | not necessarily those of Apple Group. Personal mail only, please. | Computer, Inc. Remember that." ============================================================================
jonah@amos.ucsd.edu (Jonah Stich) (08/11/90)
In article <43842@apple.Apple.COM> mattd@Apple.COM (Matt Deatherage) writes: >In article <12237@sdcc6.ucsd.edu> jonah@amos.ucsd.edu (Jonah Stich) writes: >>Okay, I've been bitten by this before, so I just thought I'd chip in and warn >>you before you havev this problem, too. When you open a grafPort this way >>it sets up a visRgn that is the size of the screen. If you want to do things >>in this grafPort (I've had problems drawing text) you have to make the >>following call sequence: >> >>NewRgn >>OpenRgn >>(FrameRect, whatever...) >>CloseRgn >>SetVisHandle >> >>Jonah > >You'll probably find SetRectRgn to be a whole lot easier. > >Matt Deatherage, Apple Computer, Inc. | "The opinions represented here are You know, I've read through all 3 Toolbox References, cover to cover, and I still manage to see calls that I've never heard of before! Jeez.... :) Matt's right though. This would be much better: NewRgn SetRectRgn SetVisHandle Thanks for catching that, Matt. Not onl do I learn something every day, but my rhyming abilities improve, too. :) Jonah jonah@amos.ucsd.edu
dlyons@Apple.COM (David A. Lyons) (08/11/90)
In article <1990Aug10.154457.17376@laguna.ccsf.caltech.edu> toddpw@tybalt.caltech.edu (Todd P. Whitesel) writes: (Dave L says call OpenPort on a 170-byte chunk of memory) >WHOA... is that 170 GUARANTEED or is there a better way to do it that doesn't >require us to hard-code how big the grafport record should be? The 170 is guaranteed, and there's no better way. It's not going to change. That would be a pain, since the Window Record structure is built around the grafport structure. -- David A. Lyons, Apple Computer, Inc. | DAL Systems Apple II Developer Technical Support | P.O. Box 875 America Online: Dave Lyons | Cupertino, CA 95015-0875 GEnie: D.LYONS2 or DAVE.LYONS CompuServe: 72177,3233 Internet/BITNET: dlyons@apple.com UUCP: ...!ames!apple!dlyons My opinions are my own, not Apple's.
mattd@Apple.COM (Matt Deatherage) (08/12/90)
In article <639@entec.Wichita.NCR.COM> jsurine@entec.UUCP (James Surine) writes: >The only resriction I have found in creating offscreen bitmaps is that some >of the Quickdraw commands like copybits don't work if the total bitmap is >larger than 32K (they're using stupid 16 bit integers again). Uh...CopyBits is a Macintosh QuickDraw routine. The IIgs has CopyPixels, and I'm not aware of any 32K restriction on the pixel map. -- ============================================================================ Matt Deatherage, Apple Computer, Inc. | "The opinions represented here are Developer Technical Support, Apple II | not necessarily those of Apple Group. Personal mail only, please. | Computer, Inc. Remember that." ============================================================================
dlyons@Apple.COM (David A. Lyons) (08/12/90)
In article <639@entec.Wichita.NCR.COM> jsurine@entec.UUCP (James Surine) writes: >The only resriction I have found in creating offscreen bitmaps is that some >of the Quickdraw commands like copybits don't work if the total bitmap is >larger than 32K (they're using stupid 16 bit integers again). >For actual code, I've got some at home and will mail you a copy later. QuickDraw is supposed to support everything in the conceptual drawing space (32768 by 32768 pixels, centered around (0,0)). If you've found something that doesn't work in a large offscreen bitmap, please report it in detail so we can fix it. -- David A. Lyons, Apple Computer, Inc. | DAL Systems Apple II Developer Technical Support | P.O. Box 875 America Online: Dave Lyons | Cupertino, CA 95015-0875 GEnie: D.LYONS2 or DAVE.LYONS CompuServe: 72177,3233 Internet/BITNET: dlyons@apple.com UUCP: ...!ames!apple!dlyons My opinions are my own, not Apple's.
jsurine@entec.Wichita.NCR.COM (James Surine) (08/15/90)
In article <43876@apple.Apple.COM> dlyons@Apple.COM (David A. Lyons) writes: >In article <639@entec.Wichita.NCR.COM> jsurine@entec.UUCP (James Surine) writes: >>The only resriction I have found in creating offscreen bitmaps is that some >>of the Quickdraw commands like copybits don't work if the total bitmap is >>larger than 32K (they're using stupid 16 bit integers again). >>For actual code, I've got some at home and will mail you a copy later. > >QuickDraw is supposed to support everything in the conceptual drawing space >(32768 by 32768 pixels, centered around (0,0)). If you've found something >that doesn't work in a large offscreen bitmap, please report it in detail >so we can fix it. >-- >David A. Lyons, Apple Computer, Inc. | DAL Systems Note it should read >64K not >32K. A while back I created a program that used a large bitmaps to store images. It was 32 x 8192 pixels or 128K in size. I used copyPixels, or which ever one does scaling, to copy 32 x 32 pixel bitmaps from this bitmap to another offscreen bitmap that was 512 x 512 pixels. I scaled the images by several values (2,4,8,...). This second bitmap was then used to copy the scaled 32 x 32 pixel bitmap to the screen to increase the speed of the screen refresh at all scale settings. I found that after copying the scaled imaged to the 512 x 512 pixel bitmap some of the 32 x 32 pixel images were duplicated. The algorith for copying the images was straightforward ( for i = 0 to 15 for j = 0 to 15) but two columns of images were duplicates (columns 11 and 13 I think). I could find no explanation except that the pixel copy didn't work very well above 64K for particular varaibles in the copying procedure. Also get and set pixel wraps around after 64K. I fixed the problem by changing the 32 x 8192 pixel bitmap to 256 sucessice 32 x 32 pixel bitmaps. And instead of referencing these by changing the copy rect I changed the bitmap pointer. Anyways thats the story. -- +=+ +=+ +=+ +=+ +=+ +=+ +=+ +=+ +=+ +=+ +=+ +=+ +=+ +=+ +=+ +=+ +=+ +=+ +=+ +=+ j.surine@Wichita.NCR.COM (Jim Surine) /\/\/\/\/\ NCR Peripheral Products Division, Wichita Kansas / / /\/\/\ \ \ work (316) 636-8586 home (316) 721-6280 / / / / /\ \ \ \ \