Hi All,

As you may have seen, there has been a small amount of interest in bringing an ASM lib with some graphics features to the TI-84+CSE (84C for short).

I have been toying with a few small ideas that i may end up implementing in a preliminary version for BASIC programmers.

There are some pretty serious speed and memory limitations on the 84C which mean that fast paced BASIC+ASM lib games arent likely if the entire screen is utilised per frame. That being said, if there are a handful of sprites on screen at any time, this should be ok.

Just a note, there will be a radical difference between the way this lib and earlier versions of xLIB (for the 83+ etc) work.

Some of the proposed features:

32 internal but user accessible 16-bit variables (functions will take references to these variables instead of TIOS variables)
Graphics mode will be 160x120 (half res)
128x64, 256 colour (standard palette) custom PIC's (likely stored in appvars) ~8192 bytes+header. Enough to store 128, 8x8 tiles/sprites.
Ability to 'load' 2 custom PIC's into temp RAM for faster access
Ability to store 2 copies of the LCD into temp RAM (kind of like a temp storePIC)
8x8 fullscreen tilemapping (160x120 = 19x13 tiles)
256 colour (standard palette) sprites (not sure on max size yet)
Capability to 'chain' keypresses and update user variables if necessary (can test up to 16 keypresses with 1 command)
On calc PIC/tile/sprite editor
*Possibly* an on calc map editor
Line/shape drawing
Colour text routines
Archived program execution
And possibly more, but that for now.

One of the BIG traps that older versions of xLIB fell into was people requesting odd or specific features that would only be used *very* rarely, if at all. These considerably slowed the entire lib down for almost no benefit. This is something that i would really like to avoid with this incarnation.

Anyway ive been testing a few small things, but screenshots are difficult to make without a fully functioning emulator. But anyway here is a small tilemap test:



Simple sprite tests, with transparency as well:



Scrolling is not ideal speed wise. Though there are options to speed things up (interlacing etc). The most probable method for games will be to scroll screen-by-screen if that makes sense.

Just wondering if anyone has any ideas/thoughts?

Tilemapping most likely wont be limited to fullscreen only to allow space for HUD's etc.

The data will not be stored in matrices as they are too slow! Id say they will be stored in appvars as well. Im not sure what the largest size map should be ... 64x64 (4096 bytes)?

Sprites will have the ability to be any size up to 64x64 i think. But the way they are stored in the PIC files will be in 8x8 chunks.

By interlacing are you referring to only drawing every 2nd line (and having black in between)? Im not sure if this would be one of those features that not many people would use since lots of detail is lost on screen. But it would be good for speed.

Copying programs from archive to RAM will be included.

I havent come across an 84C version of TilEm yet, but i have used jsTIfied. The issue with screenies is that xLIB uses the 'non-active' portion of GRAM as a buffer so it needs 160x240 mode to be emulated in order to construct proper screenshots (cropping and resizing wont give proper screenshots).

Tilemapping most likely wont be limited to fullscreen only to allow space for HUD's etc.

The data will not be stored in matrices as they are too slow! Id say they will be stored in appvars as well. Im not sure what the largest size map should be ... 64x64 (4096 bytes)?

Sprites will have the ability to be any size up to 64x64 i think. But the way they are stored in the PIC files will be in 8x8 chunks.

By interlacing are you referring to only drawing every 2nd line (and having black in between)? Im not sure if this would be one of those features that not many people would use since lots of detail is lost on screen. But it would be good for speed.

Copying programs from archive to RAM will be included.

I havent come across an 84C version of TilEm yet, but i have used jsTIfied. The issue with screenies is that xLIB uses the 'non-active' portion of GRAM as a buffer so it needs 160x240 mode to be emulated in order to construct proper screenshots (cropping and resizing wont give proper screenshots).

Ah ok, I didn't realize matrices were slow. They seemed faster than strings to me (at least for collision detection). But appvars would be better as it would be smaller.

Sprites that are 64x64 seems fine to me. Else I guess 32x32 or 16x32 would be fine as well. Most large sprites will most likely be enemy data for RPGs and bosses for other games.

For the emulator, as I said, you could just use a video capture program then edit the screenshot resolution afterward, cropping the non-active portion of the GRAM out. This is what I did with my older screenshots to fake the 160x240 mode:


As for interlacing, see image below for what I mean (basically you don't even need to implement 160x240 mode, as long as you implement scanlines):

I like the transparent color idea. By the way, how will palettes be stored? Will each sprite have their own palette or will it be one palette at once for the sprite sheet?

Ah ok I see now. I guess in that case too it shouldn't take too much memory. I worried that each sprite had its own palette, so that would have been quite large >.<

Will line/rectangle routines be forced to 120 px height btw or will they be able to use the full res?

On a side note tr1p1ea, since xLIB is starting to get old, a lot of younger TI-Z80 programmers are probably unaware of what the original version was, here. So as a suggestion, I would change the topic title to xLIB 84C - fast ASM lib for BASIC programmers or something like that, to attract more people.

Well, it seems that 3rd party app development is off to a better start than TI's app development! We already have two released apps (BrandonW's Linky beta and my MicrOS), and now a third in development. I suspect that performance issues will push even more BASIC coders to adopt assembly augmentation.

Also, I'd like to suggest possibly using the ExecLib command as your hook for BASIC functions, for it might be faster. Based on what I'm seeing in the USB8X source, you specify using ExecLib by putting the byte sequence 96 E2 00 01 at 40A0 in your app. Then, put a short pointer to a header continuation, which then contains the bytes 01 00 02 00 followed by a pointer to your ExecLib handler. These two extra headers can be sequential. Why TI didn't just make this part of a new app header field I can't image, but maybe BrandonW can.

On a side note tr1p1ea, since xLIB is starting to get old, a lot of younger TI-Z80 programmers are probably unaware of what the original version was, here. So as a suggestion, I would change the topic title to xLIB 84C - fast ASM lib for BASIC programmers or something like that, to attract more people.

Wasn't it that you have to put stuff in ans and then call Asm(prmXLIB ?

And nice thingy, the xlib for the cse!
i /really/ should get one...........