POS N

[nra]

Hello guys)

Working with limited microcomputers like Speccy, programmers are justified to use tricks, know-hows, and even anti-patters to save mem and logic parts.

For instance, instead of using two vars/bytes for saving 16x16-aligned screen coords, I often need some POS N sub/macro, linearizing a 16x12 grid

0 - 1 - 2 - 3 - .. - 15
16 - 17 - 18 -. . . - 31
. . .
160 - 161 - . . . . - 175
176 - 177 - . . 190 - 191

via N = column + row*16, updating the current SPRITE values as Y = N div 16, and X = N - Y*16.

Perhaps, it's possible via ASM keywords, yet except a "control" god-object, I found no simple way to use subs (extracts of similar/identical code) for different sprites, so copypasting/duplication is a must, alas.

Maybe Jonathan would update the Speccy AGD version too, and for now I can't help wondering whether the PC AGD version is more flexible in terms of re-usability

TY

[nra]

It seems a bit vague, yet lack of variables makes me either prefer combining two octets (0..63) into a single byte or having some function to encode/decode the position

[Jonathan Cauldwell]

Subroutines have been suggested before so may be added to MPAGD at some point.

MPAGD does have more global variables, a full set A to Z minus X and Y of course. It also has extra sprite variables. If you still need to multiply or divide by 16 in the way you described you'll find it far more efficient than AGD 4.7. The old version ALWAYS called the multiplication or division routines, whereas the compiler in the PC version will see that you're multiplying or dividing by 16 and convert that into 4 shifts left or right instead. Much, much faster.