rap@peck.ardent.com (Rob Peck) (08/29/89)
I've been working on a set of generic functions to add to the MakeBob, MakeVSprite, ReadyGels, PurgeGels stuff from the RKM (I created those originally, by the way), to complete a suite of Gels functions with MakeAnimOb, MakeAnimComp, DeleteAnimOb, DeleteAnimComp. As a demo of these functions, I now have something that responds correctly to Animate(...) by correctly placing one or more AnimObs, with corresponding AnimComps. And a correct response to an AnimCRoutine and an AnimORoutine, where the AnimCRoutine changes the base location of the AnimOb (AnX, AnY) and the AnimCRoutine changes the location of the AnimComp (XTrans, YTrans) relative to the AnimOb. The images consist of two AnimObs, each a 32 by 20 wide box, bouncing off the edges of the screen (reversing Y or X direction when it hits the top/bottom or the left/right sides) with a 10 by 6 box of another color bouncing around inside each of these boxes. I also designed a diamond shaped item which is the alternate image -- the idea was that when the large box hits a side and reverses, the image within the large box changes from a rectangle to a diamond and back on the next bounce. It works, but after an indeterminate number of image changes (ranging from 1 to 5) I crash the machine, probably due to an uninitialized pointer somewhere. For linked images, I use the PrevSeq and NextSeq pointers in the AnimComp structures and I don't necessarily initialize "everything" in an AnimComp that is a non-active image. If there is an example somewhere on a Fish Disk or some other PD disk (with source of course) that shows using the Animate function with the PrevSeq/NextSeq stuff active, I'll like to know about it. Or if someone wants to volunteer a small example that I can check out, to fix my PD version (or wants just to help find the bug...). MakAnimOb and so on (as currently configured -- or as "fixed" if I can fix em quickly) will appear in a near-future magazine article... so its almost as good as releasing them to PD, but I'd rather that they be "right" instead of released with a disclaimer that "it works up to here". Does anyone have an example that I could look at that uses PrevSeq/NextSeq. If I can't quite figure it out, I'll probably write my own version of Animate() anyway because it has a bug in it that "someone" told me about. OK, OK, the bug is: "Animate(...) is not useful for a Bob on a HIRES screen because all of the positioning calculations are based on AnX, XOffset, XAccel and XVelocity expressed as a 16-bit signed binary fraction of the form: wwwwwwwwww.ffffff where w is the whole number (signed) and f is the fractional part. After adding in the velocity and acceleration, AnX or XOffset of an AnimOb or AnimComp is calculated as: (Value >> 6) SO, the highest positive value of X is 512, a problem on a 640 pixel or wider screen. To get any value higher than that, one would have to traverse the list of Bobs ones-self after a call to Animate, and adjust the Bob X values. The alternative is to rewrite a version of Animate for our own use." Inovatronics This is what they told me, so I am quoting from a telephone conversation. I am a beta tester for CAN DO and may write a thing or two about it. Rob Peck