FB II Compiler

PG PRO

Debugging

Memory

System

Mathematics

Resources

Disk I/O

Windows

Controls

Menus

Mouse

Keyboard

Text

Fonts

Drawing

Sound

Clipboard

Printing

Communication

ASM

Made with FB

DRAWING

Understand GWorld


My hopes for a first-try success at using GWorlds in my PG project have been dashed. I'm stuck. I'm sure, though, that one (or 20) of you can tell me what I'm missing.

1. I create a PICTURE using:

PICTURE ON (l,t)-(r,b)
'Series of QD commands
PICTURE OFF, gGridPict&

I know the picture is properly recorded, because I can draw it in my window.

2. I create a ColorGWorld with

gWorld& = FN buildGWorld(gwRect) 'FN from GRFX.FLTR

gwRect has the same Top & Bottom as the area into which I want to copy it. The width is 3 times the width of the target area, the center third having the same rect as the target. This means the Left coordinate is negative. Could this be a problem? When I check the CGrafPort record, it shows the coordinates as #0 #0 #(height) #(width). I'm not sure how (or if) that affects the following...

3. I draw the gGridPict& into the GWorld& with:

LOCAL FN calDrawGrid
  DIM oldWorld&,oldDevice&
  CALL GETGWORLD(oldWorld&,oldDevice&) 'get curr port
  CALL SETGWORLD(gWorldH&,oldDevice&) 'change to GWorld&
  PICTURE (gwL,gwT)-(gwR,gwB),gGridPict& 'coords from GWorld creation
  CALL SETGWORLD(oldWorld&,oldDevice&)' 'reset port
END FN

I can find no way of testing whether this FN does what I intend or not!
When I use MacsBug to look at oldWorld& as a CGrafPort, everything seems okay, except the baseAddr comes up as a "bad pointer." I have no clue what that tells me.

4. I copy the central third of the GWorld to my window:

LOCAL FN calCopyWeek
  DIM wPtr&
  GET WINDOW gOutputWnd, wPtr&
  FN copyBits(gWorldH&,wPtr&,gCalRect,gCalRect,_srcCopy)
END FN

Here gCalRect is the rect of my target object, which should correspond to the center third of the GWorld. Even if I am mistaken about the rects being the same, it seems I should see at least a piece of the picture I drew to the (entire) GWorld, no?

I do get a bitcopy to the screen, but it contains lovely green noise rather than the gGridPict& I drew to the GWorld.

I see there is a command to LOCKPIXELS which I haven't used. Can someone tell me what it does; when and why it is necessary? This can't be my problem, can it?

Let me know if I've not supplied enough info. Any help will be greatly appreciated.

Jay


First of all, for a reasonable gWorld demo application, look over on the FB webring site(s); I'd suggest <http://www.stiinc.com/FB/>, and click on "sample source". There are several there - mine is under "Flying Brain Screensaver source", and you'll need (thanks to copyright restrictions) to download the freeware compiled app "FlyBrain" and steal the PICT resources...

My answers below come from that code - which is overkill for what you need, as it does double-buffered animation, but hopefully it'll help! (I've tried to remove the extraneous stuff from this posting, but I don't guarantee I got it all.)

<< My hopes for a first-try success at using GWorlds in my PG project have been dashed. I'm stuck. I'm sure, though, that one (or 20) of you can tell me what I'm missing.
1. I create a PICTURE using: >>

No problem here.

<< 2. I create a ColorGWorld with
gWorld& = FN buildGWorld(gwRect) 'FN from GRFX.FLTR >>

No problem here, as the relevant code is

QDErr = FN NEWGWORLD(theWorld&,0,#@t,0,0,0)

which gives a nice "default" gWorld of the size you specify.

<< gwRect has the same Top & Bottom as the area into which I want to copy it. The width is 3 times the width of the target area, the center third having the same rect as the target. This means the Left coordinate is negative. Could this be a problem? When I check the CGrafPort record, it shows the coordinates as #0 #0 #(height) #(width). I'm not sure how (or if) that affects the following... >>

Hm. Strange... all windows & gWorlds use "local" coordinates, which mean the upper-left is at 0,0. I'm not sure what you're getting by using non-zero values on the input.

I'd suggest using

CALL OFFSETRECT(gwRect,-gwRect.left%,-gwRect.top%)

before the call. Then when you "copy back", you'll just need to offset by +1x, +2x, or +3x rather than -1x,0,+1x.

<< 3. I draw the gGridPict& into the GWorld& with:
LOCAL FN calDrawGrid
DIM oldWorld&,oldDevice&
CALL GETGWORLD(oldWorld&,oldDevice&) 'get curr port
CALL SETGWORLD(gWorldH&,oldDevice&) 'change to GWorld&
PICTURE (gwL,gwT)-(gwR,gwB),gGridPict& 'coords from GWorld creation
CALL SETGWORLD(oldWorld&,oldDevice&)' 'reset port
END FN >>

Problem here. Try this; note the 0 on the SETGWORLD

gOffDev& = FN GETGWORLDDEVICE(gWorldH&)
CALL SETGWORLD(gWorldH&,0) 'set output to offscreen port
locked% = FN LOCKPIXELS(FN GETGWORLDPIXMAP(gWorldH&))
LONG IF locked%
  CALL DRAWPICTURE(gGridPict&,gwRect)
  CALL UNLOCKPIXELS(FN GETGWORLDPIXMAP(gWorldH&))
END IF
CALL SETGWORLD(oldWorld&,oldDevice&) 'set output back to window

<< I can find no way of testing whether this FN does what I intend or not! When I use MacsBug to look at oldWorld& as a CGrafPort, everything seems okay, except the baseAddr comes up as a "bad pointer." I have no clue what that tells me. >>

Me either! :-)

<< 4. I copy the central third of the GWorld to my window:
LOCAL FN calCopyWeek
DIM wPtr&
GET WINDOW gOutputWnd, wPtr&
FN copyBits(gWorldH&,wPtr&,gCalRect,gCalRect,_srcCopy)
END FN
Here gCalRect is the rect of my target object, which should correspond to the center third of the GWorld. Even if I am mistaken about the rects being the same, it seems I should see at least a piece of the picture I drew to the (entire) GWorld, no? >>

I'd be concerned about gCalRect; you might try creating a new rect, say gSourceRect, from 0,0 to the height & width needed; that should give you the "left third" of your gWorld, which is fine for testing;

CALL GETGWORLD(oldWorld&,oldDevice&) 'get curr port (not GET WINDOW)
locked% = FN LOCKPIXELS(FN GETGWORLDPIXMAP(oldWorld&))
LONG IF locked%
  locked2% = FN LOCKPIXELS(FN GETGWORLDPIXMAP(gWorldH&))
  LONG IF locked2%
    CALL COPYBITS(#gWorldH&+2,#oldWorld&+2,gSourceRect,gCalRect,_srcCopy,0)
    CALL UNLOCKPIXELS(FN GETGWORLDPIXMAP(gWorldH&))
  END IF
  CALL UNLOCKPIXELS(FN GETGWORLDPIXMAP(oldWorld&))
END IF

<< I do get a bitcopy to the screen, but it contains lovely green noise rather than the gGridPict& I drew to the GWorld. >>

That tells me your offsets are wrong; note the "#gWorldH&+2" in the above!

<< I see there is a command to LOCKPIXELS which I haven't used. Can someone tell me what it does; when and why it is necessary? This can't be my problem, can it? >>

Not likely - it's "insurance" against the Memory Manager moving your memory around on you in the middle of your CopyBits. For a simple application, you can leave it out during development - just be sure to put it in before you ship to avoid weird untraceable bug reports later!

<< Let me know if I've not supplied enough info. Any help will be greatly appreciated. >>

Plenty of info. Very well done question, with just the right amount of code!

Bill


<< 3. I draw the gGridPict& into the GWorld& with:
LOCAL FN calDrawGrid
DIM oldWorld&,oldDevice&
CALL GETGWORLD(oldWorld&,oldDevice&) 'get curr port
CALL SETGWORLD(gWorldH&,oldDevice&) 'change to GWorld&
PICTURE (gwL,gwT)-(gwR,gwB),gGridPict& 'coords from GWorld creation
CALL SETGWORLD(oldWorld&,oldDevice&)' 'reset port
END FN >>

I looked at some old GWorld code that I wrote long ago, and I find I'm doing the following, _after_ the call to SETGWORLD:

CALL CLIPRECT(imRect)
IF FN LOCKPIXELS(FN GETGWORLDPIXMAP(offPort1&)) = _false THEN STOP

(imRect is the rectangle used in creating the GWorld, and offPort1& is pointer to the GWorld.) I can't remember why I did it this way, but it seems to work for me.

Rick