Here's the size of the lib :

With CLSCREEN, 969 bytes
Without CLSCREEN, 700 bytes

Let's not forget that the size will soon change as I'm writing the zoomed display routine

Quote from: DJ Omnimaga on May 21, 2016, 08:42:12 PM
Does that use Mateo C rectangle routine and does it support chaining? That is quite cool

No, it doesn't use any Mateo's routine. I write all the routines by myself, and yes, I intend to make it support chaining
(I'm also workin' on a zooomed sprite display routine...)

I forgot to mention that CLSCREEN won't be able to use colors from palette, but colors amongst 256

@MateoConLechuga, Thanks !

@DJ Omnimaga, perhaps I'll go back to the zoom possibilities later, ...
For now, I've been working on a new option to display boxes, available through CLSCREEN :

{x,y,width,height,color:Asm(prgmCLSCREEN

Here's a screenshot of random boxes :

As it's late (have to go to bed!)
I just write this little message:
"I've just posted SPRITES version 3 on TI-Planet "
https://tiplanet.org/forum/viewtopic.php?f=12&t=18433

Oh thanks

The version 2.1 is not uploaded yet

I've just modified EFFECR   
now, when you type :

{0:Asm(prgmEFFECR



It will clear/fill the screen, using the color 0,  BUT leaving the Status Bar & Run Indicator safe


Of course, it's always possible to clear the whole screen & put Run Indicator off by omitting the {  :

0:Asm(prgmEFFECR

(nota bene:  the bubble in the corner comes back only when the Basic Program is over)

Actually, the sprites Data are values between "0" and "Z"
Which means 36 different possible values ...base 36
If you want,  you can decide to use the 16 first colors only

(I can't access to IRC...sorry)

If I well understand, there would be 2 manners:
-either clear partially the screen ( leaving the "gray status bar" & "run indicator" fines)
-or clear the whole screen, and deactivate the "run indicator"

Is this what you mean?

Thanks, alexgt

I've optimised again the display routine (a little bit faster).
Moreover, I also make the "run indicator" (yellow bubble) disappear, now.

Thanks 

I've just typed my very first "true" sprite... Here are screenshots demonstrating  zoom x1, x2 & x3 :

When you suggested a zoom possibility a few days ago, I thought  I'd have to modify AFFSPR (which would slow it down)
I had not your nice idea to include zoom within the sprite definition

I went back to the source of DEFSPR and included the parameter "zoom" : x1, x2 or x3 
I realised that a zoom greater than 3 would slow the display routine (AFFSPR) down.
This zoom parameter will appear in version 2.1 

Here is a small test program  plus its screenshot:

       

3 "undefined" (because no data!) sprites 35x35 , respectively defined using  zoom x1, x2 et x3

Thanks a lot for the add, DJ Omnimaga   

The AFFSPR routine can display up to 85 sprites at a time
and , yes, we must launch DEFPAL in the beginning (just 1 time) before DEFSPR and AFFSPR because DEFPAL not only (re)defines the palette but also does several initialisations & relocates the AFFSPR routine to the 1Kb memory-area "Cursor Image Ram" ($e30800) in order to run a bit faster