Sprites on QL

[bwinkel67]

Quick question. On the QL Homepage there is a section under Software for Sprites. It seems that sprites are either mode 4 or 16 with some going up higher. What's the aversion to mode 8? Can you use a mode 16 sprite in mode 8?

[bwinkel67]

No takers for this question?

[tofro]

Sprites is a bit of an unfortunate term in the QL world: Very often, it does not relate to "games sprites" just like everywhere else, but rather to "PE sprites", which is a different thing: A sprite for the pointer environment has nothing to do with games in the first place, but rather is what other windowing systems call an "icon" or a "cursor" (that is, graphical decoration for a windowing system program). The section "Sprites" on the QL homepage seems to cover PE sprites mainly (maybe with the exception of the "Sprite System" entry towards the end of the section, I don't know that package).

PE sprites only make sense, well, in the Pointer environment. And PE only sensibly works in MODE 4 and higher resolutions (MODEs 16, 32, 33), that is why most of the programs covering these disregard MODE 8 completely, because, well, PE disregards MODE 8.

You could possibly write games with PE sprites (and I have given a very simple example lately somewhere here), but then only in MODE 4 and higher resolutions.

[bwinkel67]

Sprites is a bit of an unfortunate term in the QL world...

Thank you for the reply. I'm specifically curious about how the sprites in this Christmas card were created:

Claus-small.gif (492.5 KiB) Viewed 4621 times

The BASIC code loads _spr files for both Santa's sleigh and the present and uses a Turbo Toolkit call of MOVE_MEMORY to move the sprite. Both are using more than 4 colors. How were these created?

Code: Select all

100 MODE 4: PAPER 0:INK 4: CLS
110 INPUT 'Device: '; d$
120 IF d$='' THEN 
130   dev$='win1_dev_santa_'
140  ELSE 
150   dev$=d$
160 END IF 
170 PRINT dev$
180 MODE 8
190 LBYTES dev$&'image1_scr',131072
200 PAUSE 250
210 LBYTES dev$&'image3_scr',131072
220 PAUSE 250
230 LBYTES dev$&'image2_scr',131072
240 santa=RESPR(13600):backgrd=RESPR(3200):owl=RESPR(480):gift=RESPR(140)
250 LBYTES dev$&'santa_spr',santa
260 LBYTES dev$&'owlblink_spr',owl
270 LBYTES dev$&'gift_spr',gift
280 SantaFrame=0: OwlFrame=0:BackDx=-2: RedoBackgrd=0
290 REMark save background where Santa will be drawn
300 MOVE_MEMORY 131072+512 TO backgrd, 3200
310 SantaPos=131072+512:OwlPos=131072+9366+128:GiftPos=134316
320 REMark Precalculate Santa and Owl frame offsets in sprite buffer
330 DIM Frames(7,24)
340 DIM OwlFrames(7,5)
350 FOR i=0 TO 7
360   FOR j=0 TO 24
370    Frames(i,j)=santa+1700*i+68*j
380   NEXT j
390 NEXT i
400 REMark Precalculate Owl frame offsets in sprite buffer
410 DIM OwlFrames(7,5)
420 FOR i=0 TO 7
430   FOR j=0 TO 5
440    OwlFrames(i,j)=owl+60*i+10*j
450   NEXT j
460 NEXT i
470 REMark Precalculate Gift frame offsets in sprite buffer
480 DIM GiftLine(13)
490 FOR i=0 TO 13
500    GiftLine(i)=gift+6*i
510 NEXT i
520 :
530 REMark Santa can move between -68 and 256
540 BlinkOwl
550 FOR SantaX=-68 TO 256
560   PutSantaFrame
570   PutGift
580   BlinkOwl
590 NEXT SantaX
600 BlinkOwl
610 :
620 SantaFrame=0: OwlFrame=0:BackDx=-2: RedoBackgrd=0
630 SantaPos=131072+512:OwlPos=131072+9366+128:GiftPos=134316
640 GO TO 530
650 DEFine PROCedure PutSantaFrame
660 LOCal pos, i, dx, ddx
670   pos=SantaPos :dx=0:ddx=0
680   IF SantaX<0 THEN 
690     dx=(68+SantaX)DIV 4:dx=34-dx-dx:ddx=dx
700   END IF 
710   IF SantaX>192 THEN dx=1+((SantaX-192)DIV 4): dx=dx+dx
720   FOR i=0 TO 24: MOVE_MEMORY Frames(SantaFrame,i)+ddx TO pos, 34-dx:pos=pos+128:NEXT i
730   IF RedoBackgrd THEN RedoBackground
740   SantaFrame=SantaFrame+1
750   IF SantaFrame=8 THEN SantaFrame=0
760   IF (SantaFrame=4 OR SantaFrame=0) AND SantaX>=0
770     RedoBackgrd=1
780     SantaPos=SantaPos+2
790     BackDx=BackDx+2
800   ELSE RedoBackgrd=0
810   END IF 
820 END DEFine 
830 :
840 DEFine PROCedure RedoBackground
850 LOCal backpos, newBackDx, i
860   backpos=SantaPos-2
870   newBackDx=BackDx
880   FOR i = 0 TO 24
890     POKE_W backpos,PEEK_W(backgrd+newBackDx)
900     backpos=backpos+128
910     newBackDx=newBackDx+128
920   NEXT i
930 END DEFine 
940 :
950 DEFine PROCedure BlinkOwl
960 LOCal pos
970   pos=OwlPos
980   IF OwlFrame<8 THEN FOR i=0 TO 5: MOVE_MEMORY OwlFrames(OwlFrame,i) TO pos, 10:pos=pos+128:NEXT i
990   OwlFrame=OwlFrame+1
1000   IF OwlFrame=24 THEN OwlFrame=0
1010 END DEFine 
1020 :
1030 DEFine PROCedure PutGift
1040 LOCal pos
1050   pos=GiftPos
1060   IF SantaX=128 THEN 
1070     pos=141484
1080     FOR i=0 TO 11: MOVE_MEMORY GiftLine(1) TO pos, 6:pos=pos+128:NEXT i
1090   END IF 
1100   IF SantaX<100 OR SantaX>127 THEN RETurn 
1110   FOR i=0 TO 13: MOVE_MEMORY GiftLine(i) TO pos, 6:pos=pos+128:NEXT i :GiftPos=GiftPos+256
1120  END DEFine 
1130 RECHP santa
1140 RECHP backgrd
1150 RECHP owl
1160 RECHP gift

[Derek_Stewart]

Hi,

So all you need to do is make sprite for Santa's Sleigh and pan then over the background scenery.

[bwinkel67]

Hi,

So all you need to do is make sprite for Santa's Sleigh.

Hi Derek...read the beginning of the thread. It asks how to create mode-8 sprites? How do you do that?

[tofro]

If you want to create QPTR sprites for MODE8, you can simply use Easysprite, which is part of the EasyPtr package.

[dilwyn]

I'm not at home to check about mode conversion with sprites, so I can only guess from memory about this for now.

I've used the Easysprite package to make mode 4 and 8 sprites. From memory I *think* mode 4 ones can be displayed in mode 8 but can't remember the result.

High colour sprites (mode 16 and above) will display whatever high colour mode is used, there's a certain amount of mode conversion which takes place but only the gd2 modes. As far as I can remember, it is not possible to display them on a mode 8 screen. Internal Conversion of gd2 sprites is limited to other gd2 modes.

So, if my memory is serving me right, you would have to design a mode 8 sprite for use in mode 8. But since extended PE sprites can have a sequence of chained sprites which, for example, would allow you to merge a mode 4, mode 8 and mode 16 versions of a sprite into one file, thus allowing the PE to choose the most appropriate one to display for the current mode. I've only tried this with GD2 systems (examples in Launchpad). Can't remember if standard PE for QL allows this with a combined mode 4+8 pair of sprites, sorry.

Wolfgang Lenerz wrote what is probably the definitive set of articles on such sprites in QL Today. They are on my website somewhere.

[pjw]

GD1 systems (ie original QL hardware) can only display sprites of the same
mode as the display is in. Ie in mode 0 (4) only mode 0 sprites can be
displayed, and in mode 8 only mode 8 sprites can be displayed.

But, as Dilwyn suggests, the sprite format allows spites of different
modes to be chained together within the same object, in which case the
system will select the first appropriate sprite for a given mode, if one
exists.

GD2 systems can display sprites of any mode, 0..64, even if the object only
contains a single definition of the "wrong" mode.

I dont have access to a GD2 mode 2 system (mono) so cant be sure that
applies in that case, but Id assume so.

[Andrew]

Thank you for the reply. I'm specifically curious about how the sprites in this Christmas card were created:

The BASIC code loads _spr files for both Santa's sleigh and the present and uses a Turbo Toolkit call of MOVE_MEMORY to move the sprite. Both are using more than 4 colors. How were these created?

I simply used Photoshop to create the sprite sheet, saved is as a RAW file that uses QL mode 8 pallette, then converted it in QL screen format.
There is a sprite sheet for the owl's blink and one for Santa. The gift box is just an image (only one frame).
Keep in mind that my sprites are NOT the same sprites as used by PE environment.