Article 3169 of comp.sys.amiga: Path: mcdsun!fnf From: fnf@mcdsun.UUCP (Fred Fish) Newsgroups: comp.sys.amiga Subject: Re: Sun Tools on Amiga Summary: VSprite Reposting (nobody seems to have seen it the first time) Keywords: vsprite demo Message-ID: <283@mcdsun.UUCP> Date: 2 Apr 87 18:30:52 GMT Organization: Motorola Microcomputer Division, Tempe, Az. Lines: 687 NOTE: Rob is having problems posting from his system and has asked me to post this for him, please respond to hplabs!dana!rap. ------------------------------------------------------------ A few weeks ago, a plea for help crossed the net regarding VSprites. I am posting the source to the VSprite demo that I had written for my book, the Programmers' Guide To The Amiga (SYBEX, January, 1987). It produces 28 VSprites onscreen simultaneously, starting with one distinct sprite image (an "S!"), and using only three distinct sets of colors. The limited number of colorsets was chosen to give the gel engine the best possible chance to be able to assign vsprites before running out of real sprites to use (especially since I restrict it to sprites 2-7 by using the line: g->sprRsrvd = 0xFC; /* do not use sprites 0 or 1. */ This prevents the gel engine from trying to change the color of the cursor. In the background area of the window, there are the digit sets 17 18 ... 31, each drawn in that particular color. As the vsprites move you will notice that certain of the colors (21-23, 25-27, 29-31) get changed. This illustrates that if you produce vsprites against a 32-color screen, the upper set of color registers, which is shared in the Amiga with the vsprites, get dynamically reassigned by the gel engine. Therefore one should avoid drawing any background stuff using the colors that the vsprites use, unless you want the effect you see there (yuck). Also, as the sprites move, if you follow any one of them, you will see it disappear occasionally. This happens when there are more than (N) sprites on a single horizontal line. N is variable depending on the way that the colors have been assigned. The list of vsprites to be produced is sorted (SortGList) from top to bottom as well as from left to right. The lowest numbered available real sprite is chosen first, and the system creates copper (coprocessor) instructions that point to the first vsprite image, as well as instruction to load that first vsprite's colors into the real sprite color registers. The hardware sprite thus used is declared unusable until a couple of lines past the bottommost line of this vsprite's display. For each subsequent vsprite in the list, the system attempts the same kind of assignment for both image and color registers. A preference is given to assigning to a hardware sprite that is both available, and for which its color registers have already been loaded with the colors that it wants to use. Thus, hardware sprites 2 and 3 can occupy the same horizontal positions in any overlap position if both carry the same colors, and can have any arbitrary images. The gel engine does not, however, compare the colors in the colorset to make the decision about possible sprite pair assignment. Rather it compares the POINTERs to the colorsets. That is why you would not want to have multiple colorsets, each of which contained identical colors for your vsprites... because the POINTER values to those colorsets would be different and the system would run out of vsprites sooner. The book goes into a similar example for simple sprites and uses a nearly identical data structure for its Bob example. The programs are available on disk in both source and executable form. All, including this one, are in Lattice C, though I'm working on converting all to run under either Lattice or Manx. NOTE: THIS PROGRAM CAN BE COMPILED AND LINKED UNDER 1.1 (Lattice 3.03) BUT ONLY RUNS UNDER 1.2. (There was a problem in release 1.1 that prevents VSprites from running). Hope this helps. Rob Peck hplabs!dana!rap USnail: DATAPATH, POBox 1828, Los Gatos, Ca. 95031-1828