Animation in SMSQE

[Derek_Stewart]

Hi,

This might do the job:

MOVE.L 63295,a1 ; Source
MOVE.L 23295,a2 ; Destination
MOVE.W 6912,d1 ; Number of words to copied
loop:
MOVE.B (a1)+,(a2)+ ; Copy source location to destination location
DBRA d1,loop ; Decrement by 1 till zero.
RTS

[martyn_hill]

A tiny-weeny adjustment, if I may Derek

As our humble 68k DBRA instruction quits once its loop-counter reaches -1 - rather than the more intuitive 0 - we must reduce the byte-count by 1 before entering the loop, thus

Code: Select all

          ...
          MOVE.W 6912,d1     ; Number of words to copied
          SUBQ    #1,d1          ; adjust for DBRA
          ...

Alternatively, we sometimes skip the actual byte-moving instructions on the first iteration and enter the loop at the DBRA instruction.

[stevepoole]

Hi Tiny, You said :

<< For animation, updating a screen 50 times a second should be fast enough but only if one could create the frames in the background. I have no idea how one could do this. I am guessing that one could write to a buffer and then write the buffer to a window but I am sure this can not be done in SBASIC. >>

Yes, you have pinpointed a big problem : The TURBO tooolkit command MOVE_MEMORY can swap screens in and out of memory very fast indeed. But you cannot write to a screen in memory, other than the output screen itself. So MOVE_MEMORY is useful for storing screens for a later fast and smooth replay. Very frustrating, because there is no suitable channel 'access to memory' with SBASIC graphics commands. MOVE_MEMORY uses PEEKing and POKEing, so you would have to write your own graphics drawing routines to achieve what you suggest ! Maybe someone has done such a thing already?

The usual method of animating sprites is to redefine font chracters, and let the screen driver do the displaying. But you need to be very careful to optimise your inner loops to be sure to get fast and smooth output. The TURBO guide gives plenty of advice on the latter point...

Keep on trying.... Steve.

[pjw]

I have been trying to write some "crap" games for the 2021 competition using Liberated SBASIC in SMSQE and have found
animation rather difficult ,so when I noticed the Dynamic Sprite topic I posted a some questions relating to their use in
games programming.

My questions were quickly answered by dilwyn as follows:-
---
Short and simple answer: no they can't be used as moving sprites for games. The operating system has no support other than using them as 'moving' or animated on-screen pointers (mouse pointer), and writing them out as simple non-animated objects using commands such as SPRW in Easyptr and WSPRT in QPTR toolkit.
<>

There is this:

Code: Select all

10 REMark This method only works with rectangular sprites: No transparency
11 REMark Cursor up => faster, cursor down => slower, ESC to quit
12 :
13 spr$ = "":                      REMark If no sprite => draw something
14 REMark spr$ = "win3_spr_lp_king_spr"
15 :
16 REMark     Init window
17 ch = FOPEN(#0; "con_")
18 wsx% = SCR_XLIM(#ch): wsy% = SCR_YLIM(#ch)
19 :
20 RANDOMISE
21 :
22 REMark     Load some sprite or draw something
23 IF LEN(spr$)THEN
24  spr = SprLoad(spr$): ERT spr
25  sx% = PEEK_W(spr + 4):         REMark Get size
26  sy% = PEEK_W(spr + 6)
27 ELSE
28  sx% = 50:                      REMark Set some size
29  sy% = 50
30 END IF
31 :
32 xmx% = wsx% - sx%:              REMark Work out limits
33 ymx% = wsy% - sy%
34 cx% = RND(sx% TO xmx% - sx%):   REMark Start somewhere
35 cy% = RND(sy% TO ymx% - sy%)
36 dx% = -1: dy% = 1: s% = 2:      REMark Initial direction and speed
37 :
38 OUTL#ch; sx%, sy%, cx%, cy%
39 :
40 REMark     Draw sprite/something
41 IF LEN(spr$)THEN
42  SPRW#ch; 0, 0, spr
43 ELSE
44  REMark NOTE! If scr_x/y_lim > approx 1280x800 then FILL crashes system!
45  PAPER#ch; 1: CLS#ch
46  FILL#ch; 1: INK#ch; 7: CIRCLE#ch; 50, 50, 48: FILL#ch; 0
47  FILL#ch; 1: INK#ch; 2: LINE 10,30 TO 50,96 TO 92,30 TO 10,30: FILL#ch; 0
48 END IF
49 :
50 REMark     Lets roll!
51 REPeat bounce
52  REMark    Move
53  IF dx% > 0 THEN
54   cx% = cx% + s%
55   IF cx% > xmx%: dx% = -1: NEXT bounce
56  ELSE
57   cx% = cx% - s%
58   IF cx% < 0: dx% = 1: NEXT bounce
59  END IF
60  :
61  IF dy% > 0 THEN
62   cy% = cy% + s%
63   IF cy% > ymx%: dy% = -1: NEXT bounce
64  ELSE
65   cy% = cy% - s%
66   IF cy% < 0: dy% = 1: NEXT bounce
67  END IF
68  :
69  OUTL#ch; sx%, sy%, cx%, cy%:        REMark Thats it! Move
70  :
71  REMark    User interaction
72  k% = CODE(INKEY$(#ch; 1))
73  SELect ON k%
74   = 27: EXIT bounce
75   = 32: BGET#ch; k%: IF k% = 27: EXIT bounce
76   = 208: REMark Cursor up  => faster
77          s% = s% + 1: IF s% > 9: s% = 9: BEEP 1000, 2
78   = 216: REMark Curso down => slower
79          s% = s% - 1: IF s% = 0: s% = 1: BEEP 1000, 2
80  END SELect
81 END REPeat bounce
82 QUIT
83 :
84 :
85 DEFine FuNction SprLoad(fnm$)
86 LOCal ch, fl, ad
87 ch = FOP_IN(fnm$): IF ch < 0: RETurn ch
88 fl = FLEN(#ch): CLOSE#ch
89 ad = ALCHP(fl)
90 LBYTES fnm$, ad
91 RETurn ad
92 END DEFine SprLoad
93 :
94 :

As it stands, its SMSQ/E only, and preferably on a fast platform. If you dont have EasyPtr's ptrmen_cde loaded, you could LRESPR my WSPT command and change SPRW#ch; 0, 0, spr on line 42 with WSPT#ch; 0, 0, spr. But you dont need to use either if you use the drawn "sprite" option - which is the default.
EXecute the _bas file directly.

Theres another example using transparency on my website called bounce.

Neither example is very useful. Rather they demonstrate the limitations of using the full object background refresh for moving objects. I guess a better way would be to move and refresh an object row by row, something best done in a bespoke package written in assembler.

[pjw]

Update to above:

I just tested with SMSQ/E on Q-emulator. With smallish sprites (<= 50x50) even a BBQL can just about hack it, but at SGC speed its just fine.

Regarding the drawn "sprite" option on a QL or other non-square pixel display platform, the y-size should be 3 / 4 of x-size for best results, ie line 29 could say: sy% = sx% * 3 / 4.

[Tinyfpga]

It will take me a while to digest the recent posts from BSJR Martin_Head, pjw, derek, stevepoole and TMD2003, for I am still tinkering with dilwyn's code. In particular dilwyn's "walking figure" code would be more realistic if the characters were of an actual figure. I have searched on his site for instructions on how to modify the SMSQE character set but cannot find a precise way of doing this.
If I could create some new characters that look like parts of animated figures this would be useful. Can anyone tell me how to do this this?

[dilwyn]

It will take me a while to digest the recent posts from BSJR Martin_Head, pjw, derek, stevepoole and TMD2003, for I am still tinkering with dilwyn's code. In particular dilwyn's "walking figure" code would be more realistic if the characters were of an actual figure. I have searched on his site for instructions on how to modify the SMSQE character set but cannot find a precise way of doing this.
If I could create some new characters that look like parts of animated figures this would be useful. Can anyone tell me how to do this this?

There is no specific command on QL to modify an individual character - the QL doesn't do "user defined graphics" in the same way as some other retro computers. Rather, you go about creating and modifying a new character set.

Any QL font editor should be able to alter the characters of the SMSQ/E character set, which is the same format as the QDOS equivalent, just that one or two characters look a little different, e.g. the QDOS fonts have no Euro currency symbol. Hesitant to suggest any one editor in particular as I don't know what system you intend to use - some editors need pointer environment, some don't. Easiest way once you have an editor ready for use is to load an existing font (plenty on my website) and edit some of the characters.

Fonts are generally 9 bytes per character, with a two byte preamble at the start of the file to specify the lowest character code contained, and how many characters in the font file. Normally, the QL uses two fonts, the standard one for the character codes 32 to 127 and another containing the accented characters and symbols for higher character codes.

Having created the font, it is installed for use on both SMSQ/E and QDOS with the CHAR_USE command after loading the font into common heap (temporary) or RESPR (permanent until you switch off). On QDOS, CHAR_USE is a command from Toolkit 2, in SBASIC on SMSQ/E it's a built in command.

Some general articles on the use of fonts in the Fun With Fonts articles http://www.dilwyn.me.uk/docs/articles/funfonts.zip

[TMD2003]

Update to above:
I just tested with SMSQ/E on Q-emulator.

Update to my QL knowledge (which is very, very much less extensive than everyone else here): I had no idea this was possible.

Can I assume it's just a case of switching out the JS ROM for... whatever SMSQ/E needs, or is there something that needs to be in the "Ext. ROM" box as well?

[pjw]

Re SMSQ/E on Q-emulator: I dont know if this will work with the unregistered version as you require at least 640 K memory.
You need to download SMSQ_GOLD from W Lenerz'es site. Start by booting into JS or Minerva.
My boot file, then, looks something like this:

Code: Select all

100 ptr = 1:		rem I want PE loaded if not SMSQ/E
110 :
120 IF VER$ <> 'HBA' THEN 
130  PRINT "SMSQ/E? ";
140  k$ = INKEY$(150): PRINT k$
150  smsq = (k$ = '' OR NOT k$ INSTR 'n ' & CHR$(27))
160 ELSE 
170  smsq = 1
180 END IF 
190 :
200 IF smsq THEN 
210  IF VER$ <> 'HBA' THEN 
220   LRESPR 'win2_SMSQ_GOLD'
240  END IF 
250 END IF 
260 :
270 LRESPR 'win2_qmon'
...
300 IF ptr AND NOT smsq THEN 
310  LRESPR 'win2_rxt_ptr_gen'
320  LRESPR 'win2_MacMouse11'
330  LRESPR 'win2_rxt_wman'
340  LRESPR 'win2_rxt_hot_rext'
350 END IF 
... 

Adjust to taste. As it stands, it gives you a choice to continue with Qdos/Minerva + PE or load to SMSQ/E. Its also possible to get Q-emulator to run SMSQ/E in 8 or 16 bit colour modes, but I havent managed to do that yet (Didnt try very hard..)

[pjw]

PS: So my assertion that "even a BBQL can hack it" was an misstatement; a BBQL cant run SMSQ/E! But speedwise, with a few suitable additional toolkit commands (the equivalents of which can all be found on Knoware.no) a BBQL would be capable of running the program in question.