Drawing Speed of Sprite/Tile in Assembler

[spkr]

Ha, a topic to my liking.

I'm not sure if I understand the requirements (something with transparency or not), but the fastest sprite code is generated code.
As such you analyse the sprite that you generate specific draw routine, rather than 'generic code' that just reads from buffer and treats all bytes the same.

As such, your sprite generation should recognize individual cases like 'all bits are set and therefore I can move the data, rather than or the data in', and similarly on a more technical level, it should reuse data in registers in case certain places in the code use the same pattern/bits/data.

Similarly it could take into account sequential writing of memory and so on, and so on.

I wrote an article about it that at least touches part of what I mentioned above;
https://smfx.st/?sprites (sorry the certificate is invalid...).

If you need hands on help, I'd gladly give you a hand. Or we can have a little play who can get a faster routine and see how fast we can go .

Kind regards
Wietze

[t0nyt]

Thanks spkr

I don’t have a particular game in mind at the moment, so generic coding is what I’m looking at for now rather than trying to make something particularly fast

This is all about me learning as much as I can about assembly programming on the QL and learning to use all the tools available

I may well drop my “sprite” experiments for now and work on a new code editor (much more in my comfort zone, along with terminal applications, from my 8086 assembler days)

Many thanks

[spkr]

Then,

Make 4 versions of the sprite (one for each position), and save both masking code and drawing code per position, and you have a generic optimal approach.

Kind regards
Wietze

[t0nyt]

Then,

Make 4 versions of the sprite (one for each position), and save both masking code and drawing code per position, and you have a generic optimal approach.

Kind regards
Wietze

That’s the approach I’ve taken (I think)

I have a colour sprite definition for each sprite where a word = 4 pixels. I then expand this in memory to mode 8 format, then create 3 more versions each shifted 1 pixel. It also makes transparency masks

Am currently getting a slight corruption in 2nd sprite set which I’m trying to get my head around. Will get there though.

Many thanks

[spkr]

The only thing that is fast on m68k is move (movem in particular). So if you are going for speed, arrange your code for lineair reading and writing, and try to avoid any kind of transformations in the time critical code.

Kind regards and godspeed
Wietze

[t0nyt]

I now have my sprites code working, in that it will draw a sprite anywhere on the screen (not tested the masks yet)

So I've now gone back to add in the 50hz timer routine so I can animate the sprites, but when I added the timer code back in I can't call the "timerInit" routine

The instruction "bsr timerInit" (or "jsr timerInit") give a linker error of "Warning - 36 Truncation Error at offset 00000020"

Is this likely to be caused by the fact that "timerInit" is a very long way away (at end of the main code and after all the sprites/masks) please?

Many thanks

[t0nyt]

Have managed to get rid of the linker error by relocating the code (I had assumed it had to go in a code section after offset section)

Am getting an exception though in QemuLator, but will have a play

[t0nyt]

Have managed to get rid of the linker error by relocating the code (I had assumed it had to go in a code section after offset section)

Am getting an exception though in QemuLator, but will have a play

Finally got my head around where to put everything in the code and why I'm getting what I thought were issues/exceptions

Now I'll be able to get a fully moving animation working hopefully