sean1@garfield.UUCP (09/25/86)
My Problem: I am very familiar with the operations of sprites on the Commodore 64. I have a Commodore 128 and decided to write a program in native 128 mode using sprites. No matter what I tried, using the SSHAPE and SPRSAV commands the sprites showed mounds of junk instead of the image I wanted. Is there no way to use the VICII's locations directly, thereby overriding the BASIC 7.0 commands? Some of those commands are GREAT, like the BiZillion features of MOVSPR, but the actual definition and page flipping of sprite definitions MUST be easier. Here is one example: I drew a small 2x2 box on the screen at 100,100. Then I used: SSHAPE A$,100,100,102,102 : rem should save all data from 100,100 to 102,102 into A$. then: SPRSAV A$,5 : rem assigns the data in A$ to sprite 5 Now, sometimes this would ALMOST work, I would get the general shape I was looking for, but I would also get a few bits of junk that is not supposed to be there. Also, it was NOT what I drew on the screen. Can anyone out there (Maybe someone has a copy of the Programmer's Reference guide for the 128, I dont't) tell me how to define the sprites the old fashioned Read-a-file and assign-sprite-page-pointers method? Surely there must be a way. Maybe due to my inexperience with the commands, I have made an error somewhere. I also tried defining A$ myself, This almost worked too. Four out of the six sprites were perfect, but two of them had JUNK at the bottom. These commands are the same as the Super Expander, which I bought last year but seldom used. HHHHEEEEEEEEEEEELLLLLLLLLLLLLLLLLLLLLLLPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP! (What I would really appreciate is a memory map of the sprite pointers to see where they have been relocated and of the sprite registers so I can use them the old way. If it is possible.) /~~~~~\ |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| |/ / \ \| | UUCP: {akgua,allegra,cbosgd,ihnp4,mcvax,utesri}!garfield!sean1 | [|-@-@-|] | CDNNET: sean1@garfield.mun.cdn | \| ^ |/ | Sean Huxter | | \_/ | | Apt. 420, 235 Blackmarsh Rd., St. John's, NF, Canada | \___/ |(Can YOU say NEWFOUNDLAND, boys and girls?) (and pronounce it?) | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The opinions expressed here will be put to a general vote and the results will be posted. Stand by...
fred@cbmvax.cbm.UUCP (Fred Bowen) (09/26/86)
> I drew a small 2x2 box on the screen at 100,100. Then I used: > SSHAPE A$,100,100,102,102 : rem should save all data from 100,100 > to 102,102 into A$. > then: > SPRSAV A$,5 : rem assigns the data in A$ to sprite 5 > > Now, sometimes this would ALMOST work, I would get the general shape > I was looking for, but I would also get a few bits of junk that is > not supposed to be there. Also, it was NOT what I drew on the screen. ... > > (What I would really appreciate is a memory map of the sprite pointers > to see where they have been relocated and of the sprite registers so > I can use them the old way. If it is possible.) When you copy a SSHAPE into a sprite, you must be sure the dimensions of the area you saved is exactly that of a sprite (24x21). If your first example had been SSHAPE A$,100,100,123,120 then your resulting sprite definition would have been correct (assuming high-res mode- SSHAPE A$,100,100,111,120 is correct for a muticolor shapes. Each dot in X needs 2 pixels in this case). To create your own SSHAPE strings, you must understand how the shapes are stored in the strings. Because BASIC limits string lengths to 255 characters, the size of the area you can save is limited (no problem for shapes destined for sprites, obviously). The string size required can be calculated using the following (unscaled) formula: Length = INT((ABS(x1-x2)+1)/M+.99) * (ABS(y1-y2)+1) + 4 where (x1,y1) and (x2,y2) are diagonally opposite corner coordinates and M=4 for multicolor mode or M=8 for high-res mode. The shape is saved row by row. The last four bytes contain the width-1 and height-1, in low/high byte format. For sprite shapes, the Length will always be 67 and the last four bytes will always be 23, 0, 20, 0 (regardless of graphic mode). BASIC automatically sets the sprite pointers to the system's sprite definition area, $E00-$FFF. The pointers are found in the last 8 bytes of the video matrix, $7F8-$7FF for text mode or $1FF8-$1FFF for graphic mode. You can alter these (eg., point more than one sprite to the same definition), and as long as you do not clear the screen the modified pointers will be left alone. One last note. BASIC 7.0 controls the VIC itself, maintaining 'shadow' registers in RAM which are copied to the VIC automatically during each raster- generated IRQ (the SID is similarly controlled). You can disable this (and consequently lose some BASIC sound and animation capabilities) by POKEing a non-zero value to RAM location $12FD. This would give you, and not BASIC, control of most VIC registers. Incidentally, the VIC 'shadow' registers are located at $11D6; these contain the 16 sprite X-Y position coordinates. You can re-enable BASIC's IRQ handler by POKEing a zero to $12FD. Addressing other VIC registers for purposes of moving the screen, for example, is possible too, only a bit more involved and beyond the scope of your original questions, I think. Happy experimenting. -- Fred Bowen uucp: {ihnp4|seismo|caip}!cbmvax!fred arpa: cbmvax!fred@seismo.CSS.GOV tele: 215 431-9100 Commodore Electronics, Ltd., 1200 Wilson Drive, West Chester, PA, 19380