Sprites v3, a new ASM lib to enhance TI-84 Plus CE BASIC games tutorial

[xlibman]

TI-83 Premium CE and TI-84 Plus CE BASIC programmers who wants to use sprites in their games via the help of ASM and C libraries dedicated to enhance their favorite language are waiting for the arrival of Doors CE 9, which will include xLIBCE and Celtic 2, both of which have advanced sprite support along with many other features. However, did you know that even though Doors CE 9 is not released yet, it is already possible to program in hybrid TI-BASIC on your color screen calculator?

For a very long while, CE Textlib, by DrDnar, was the only choice available for those who wanted something else than monochrome home-screen text and slow DRAW command graphics. Featuring rectangles with the ability to chain commands for much faster execution speed, it was later discovered that CE Textlib rectangle command could be exploited to circumvent the multiples of 12x20 pixels limit to display rectangles as small as 4x4 and was fast enough to display sprites:



But now there is a second ASM library available, called Sprites! As the name suggests, this one is dedicated to displaying sprites and it was made by grosged from TI-Planet. It supports custom palettes and can display sprites of any size up to 35x35 pixels:

The library comes with 6 different sub-programs, three of which are optional, but still can be handy. How the lib works is as follows:

1) First of all, you must define a color palette with the PALETTE program. A palette can contain 36 colors at once but you don't have to define all 36 everytime. You can define the first three, for example (it's recommended to place the colors you plan to change the most often at the beginning)

Code: [Select]

{color0, color1, color2:Asm(prgmPALETTEThe color IDs go from 0 to 255 and this library uses the same colors as xLIBC. (Click here to see the chart.) If you use Asm(prgmPALETTE with something else than a list, then a default color palette will be defined instead. Using the "":Asm(prgmPALETTE syntax will display the current palette on the screen.


2) Then you must define sprites with SPRITE. Here are the limitations:
-ID: Starts at zero
-Height: From 1 to 35
-Width: From 1 to 35
-Zoom: From 1 to 3
-Each pixel color: From 0 to 9 and A to Z.
Sprites are stored as numbers and letters, with the ID and size in the header, all inside a string, like this:

Code: [Select]

"0C310123456789AB
Ans+"CDEFGHIJKLMN
Ans+"OPQRSTUVWXYZ
Asm(prgmSPRITEIn this code, you basically create or overwrite sprite 0 and it's 12x3 pixels (Note the 0 C3 at the start. The width, height and pixels are in base-35, meaning from 0 to 9 and from A to Z). You can store up to 10 35x35 sprites at a time if they are not zoomed in. Note that zoomed sprites take more space than non-zoomed sprites, so basically a 8x8 sprite with a 2x zoom will take the same amount of memory as a 16x16 sprite and with a 3x zoom it will take the same as a 24x24 sprite.


3) Draw the sprites with SPRITE. You can draw multiple sprites at once in one command (it is unknown how many can be drawn at once, but CE Textlib took lists of up to 255 elements at a time). You can use the entire screen, but be careful to not draw outside the screen!

Code: [Select]

{0,100,200,1,0,0:Asm(prgmSPRITEThis code draws Sprite 0 at (100,200) on the screen and Sprite 1 at (0,0). You must always re-define the palette before defining any sprite, according to the author!

As you can see in the screenshot above, the only reason why the trees are being drawn gradually is because I decided to only draw 10 at a time. It's up to you to judge if you need higher speed or a smaller file size in such situation.

The other program is optional (CLRSCREEN fills the entire screen with one of the palette colors of your choice and you can choose to redraw the status bar or disable the busy indicator). For example, {5:Asm(prgmCLRSCREEN will erase the screen with color #5, but preserve the run indicator and status bar, while 5:Asm(prgmCLRSCREEN will erase the entire screen with color #5, including the status bar, and will disable the run indicator.


In conclusion, there will soon be three different ASM libraries available for TI-84 Plus CE BASIC programmers to enhance their games with sprites, some of which are smaller, others larger and some has features that the others lack. You can even use CE Textlib and Sprites v3 together, such as if you want colored home screen text and erasing the busy indicator, but still be able to use high-quality sprites at the same time. This new Sprite lib addition will give you even more choice! As always, though, backup your progress often if you start programming, in case you do mistakes and freeze your calculator!


Download Sprites v3: https://tiplanet.org/forum/archives_voir.php?id=539203
Source: https://tiplanet.org/forum/viewtopic.php?f=12&t=18391

[grosged]

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

[xlibman]

Hi grosged and welcome here. 85 sprites seems very good for me. That would definitively be more than enough for a custom font routine (I wanted to make one in CE Textlib too but the fonts would be too big).

Something that would be cool for future versions is the ability to define if we want a sprite to show up at its original size, twice larger (each pixel would be 2x2), three times larger, etc. Many people prefer using 8x8 sprites to save space and be able to port monochrome games easier, but at 320x240 resolution it's harder, so scaled sprite support (even if we can't change them on the fly) would be nice. Maybe the syntax could be 0 C32, for example? (0 being sprite #0, C being 12 pixels width, 3 being 3 pixels height and 2 being 200% zoom).

[grosged]

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

[xlibman]

Woah great job :O. I don't mind a bit of slowdowj, considering there is chaining support. I can now save RAM and time doing pixel art yet still fill the entire screen.

[grosged]

Thanks 

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

[xlibman]

Nice. Also I should check if SourceCoder lets us convert images to hex.

[alexgt]

Nice! Looks good grosged

[grosged]

Thanks, alexgt

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

[xlibman]

Is there an option to make the run indicator appear and disappear? That could be handy if someone prefers keeping it, but I am fine if it doesn't have one.

One option that would be nice, though, is if EFFECR redrew the gray status bar at the top of the screen when you do "String":Asm(prgmEFFECR.

[grosged]

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?

[Ivoah]

Nice. Also I should check if SourceCoder lets us convert images to hex.

I thought the sprites were base-35, not base-16 (hex)

[grosged]

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)

[xlibman]

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?

Neither of those, actually. What I mean is doing like Doors CSE 8.0's real(0,1,0,1) command. I think redrawing the status bar is a TI-OS routine or BCall but I could be wrong. Basically, when we exit our games then we would have the ability to redraw the gray bar if we want to (with is currently impossible with CE Textlib and Sprites v2).

Nice. Also I should check if SourceCoder lets us convert images to hex.

I thought the sprites were base-35, not base-16 (hex)

Yeah it's base-35 for Sprite v2 and base-16 for SourceCoder, but most of the time I only use about 4 colors per tile so it's not a problem for me. I just don't remember if SourceCoder can convert images to hex or if it can only do the opposite.

[grosged]

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)