Well, as work goes on in C and ez80, I would really appreciate to know some specific routines (NOTE: Specific, as in not just "graphics functions", or "File stuff" ), (And ones that will be used the most often), among other things. Note that this only includes routines that are not supported by the OS.

Adapted from ExtGraph's the list of routines:

* sprite drawing with transparency;
* sprite grabbing for saving background (important, especially useful with transparency mode);
* triangle filling with given color;
* circle filling with given color;
* fast screen fill with given color, a special case of rectangle drawing;
* fast screen grabbing;
* fast screen blitting with transparency;
* tilemap engine, of course - this encompasses multiple routines, for rendering sprites to the large backbuffer, for rendering the large backbuffer to screen, etc.;
* arbitrary clipped lines in XOR mode;
* pixel drawing in XOR mode;
* circle drawing in XOR mode;
* circle filling in XOR mode;
* triangle filling in XOR mode;
* rectangle filling in XOR mode;
* sprite drawing in XOR mode;
* character and string drawing, unless TI's code is acceptably fast - on the TI-68k series, character drawing on AMS 1.xx is relatively slow, and far worse on AMS 2.xx and 3.xx;
* rectangle outline drawing, with given color and in XOR mode - probably makes less sense on a register-starved ISA and 8/16 bpp drawing mode than on a 68000 in 1 bpp drawing mode ?
* line drawing routines specialized in vertical and horizontal line drawing, in both given color and XOR modes ?
* two different scrolling routines, one horizontal and one vertical ?
* horizontal and vertical sprite mirroring, +90/-90/180° sprite rotation ?

The XOR mode makes sense only if there's a reasonable way to compute the inverted color from a given byte / word. For 8 bpp mode, a LUT might be reasonable, but hardly so for 16 bpp mode, obviously.

I've noticed that in TI Basic when using the Text( command it puts the top left corner of the text on the X,Y. I don't know if there is an ASM routine already for this or not, but it would be nice to have an upgraded Text( routine in C that takes these args:

graphText(X,Y,Text,Color,Background Color,Justification to XY

Text would take a String or Number
Background Color would be 0 for Transparent
Justification to XY would be Left, Centered, Right for both X & Y Respectively

Thanks guys! Will get working to create these functions to be nice and user-friendly. Any more would be greatly appreciated; and if anyone is looking for a challenge, you can code together some routines as well if you would like. Anything goes; pretty much.

Okay, this is the moment when I have run into the ultimate dilemma. There are too many bpp modes. I believe 8bpp should be the standard for all graphics; with simple graphic functions for 16bpp, such as lines and access to TIOS text functions and such. Sprites and other elements only really work in 8bpp mode, as this allows for double buffering, and other things. There will still be support for 16bpp, but 8bpp should become the standard. There are, many, many reasons for this, and if you have any questions, I'll be happy to answer them. Thanks!

Also, for double-buffered graphics, how would you guys like that to work? Note that it is possible to swap the location of the vRAM pointer rather than copying to the screen.

More than two bpp modes is a burden, indeed.

Not sure how this would play out, but I believe there is a bcall to flip the screen 180 degrees... I think this could be a cool feature to squish into a lib besides that, maybe the equivalent of an input command? Since right now, on other color calcs, the only way to do such a thing is with a pretty slow routine... Just things I wish were in other libs :')

The beauty of 8bpp mode is that it is palette driven so if the user really needs specific colours they can use a custom palette. So I guess maybe some palette related functions are needed, possibly only a default palette function (h=l)?

Second vote for a default h=l palette, because it has plenty of software and tools already designed for it.

Meh; that was added a long time ago Plus there are tools for other things too But on the other side of the spectrum; what else would you like? I've started some file IO stuff; much like the standard C implementation of it in most cases, I guess. It's going to be a tad different, of course; but that's just how some things are structured. Seriously though; what else would everyone like? I make some routines to pull in TI float support, for conversions, and other things.

Also, the main problem I'm having now is I have the clipped sprite routines and the grabbing routines; but I don't know what we should do about storing the background for sprites when updating their location. Actually; I wonder if it would work to just switch the sprite and recovery data when updating... And somehow account for transparency through setting a bit or somethings? Thoughts? Thanks everyone!

ExtGraph's sprite grabbing routines are not meant for restoring to a different location, unless there's no background. All they care about is speeding up the more or less common case of several sprites drawn with a destructive mode, over a background which is scrolling less frequently than the few sprites, and whose redrawing is costly, even with a tilemap engine.
One of the ExtGraph examples showcases the speed difference.


stdio.h routines are nice for compatibility, but... since both the TI-(e)Z80 and TI-68k platforms are fortunate enough to have memory-mapped file I/O in a flat addressing space, nothing beats the native OS file handling functions
I did optimize TICT TI-68k/AMS programs for both size and speed by switching them from stdio.h to the native vat.h functions.

One thing you should not do, especially since you'll be using a shared copy of the file functions, is to use a naive implementation of fwrite, such as the one in GCC4TI, inherited from its dead ancestor. It has a conservative, but slow, memory allocation scheme, which reduces its usability...
Granted, TI's official, less general functions for handling "other" type variables (whereas stdio.h and vat.h functions can consume and produce arbitrary files), provided by GCC4TI in files.h, are very much slower, like 2-3 KB/s IIRC (!) - but still.
"fwrite_fast" never came to be in GCC4TI's dead ancestor, because the maintainer refused anything which might have increased the size of that function duplicated across programs...

EDIT: Mateo reminds me on IRC that the TI-eZ80's native VAT handling functions use non-C calling conventions, and need wrappers. That's a necessary lower layer, indeed - but the upper stdio.h layer, which could be at least partially written in assembly using the non-C calling convention of the native routines, looks low(er) priority to me.

Even though I've linked it through IRC, https://wiki.inspired-lua.org/ contains categories of the functions TI has provided in its TI-Nspire Lua API. It'd be nice to take the most useful ones, especially if one day we'll have Lua ported on the CE

Sounds good! Timer functions as well, and perhaps support for interrupts as well, of course.

So, I do have a line drawing routine, but it is no where near optimized. I would really appreciate it if someone were to make a simple line drawing routine in eZ80 in 8bpp mode, where the inputs are:
(TopLeft X, TopLeft Y, BottomRight X, BottomRight Y, Color)
Thank you very much for any assistance! (Clipping would be great, if at all possible)

Clipping lines is a mild chore... There's relatively little to be gained by combining the clipping routine and the drawing routine, so I'd suggest to leave the non-clipped routine as is, and supplement it by a separate clipping routine.

According to a comment, ExtGraph's ClipLine_R routine, used by ClipDrawLine_R before calling the callback (if necessary) uses the Cohen-Sutherland algorithm. I see 4 16x16 -> 32-bit multiplications and 4 divisions with 32-bit dividend, 16-bit divisor and 16-bit result (no overflow handling). The former is easier on an eZ80 than on a Z80, but the latter is no fun on both.

Ah, okay. This makes sense, and is a good way to implement it for most clipping in graphics then.

It appears that the Cohen–Sutherland algorithm can actually be applied to rectangular coordinate systems all around. As long as I write that, that should work just fine with rectangles, horizontal lines, vertical lines, and more, unless I am mistaken? If this is the case, neat! Drawing circles and things can also use this algorithm if I draw them in terms of lines. Thanks for the information! This is a big help.

AFAICT, yes, the Cohen-Sutherland applies to general lines. Within some bounds, of course, lest you want to use over-wide data types internally, in order to try and prevent numeric overflows, but that's a pain on a register-starved 8-bit microcontroller.


For filled circles, ExtGraph uses a loop chaining:
* a fast Bresenham-type algorithm to compute the endpoints;
* fast clipped horizontal line drawing routines to draw every line of the circle.
I don't think there's a much faster way to do it.

For special lines (horizontal, vertical, rectangles), better using trivial, and much faster, algorithms. Cohen-Sutherland's multiplications and divisions make an implementation of it relatively slow on a 68000 or worse, eZ80...

In the list of functions from ExtGraph I posted in August, I forgot about the decompression (TTPack, which is PuCrunch) + TTArchive handling functions. IOW, a library of standard, battle-proven compression and/or decompression algorithms, plus some thin layer on top for handling multipart compressed archives (e.g. title screen and text in eBooks in TICT eBook Reader format).

PuCrunch's page used to be https://www.cs.tut.fi/~albert/Dev/pucrunch/ , but the content is gone now. PuCrunch has both RLE and LZ77 working together. The compression ratio is usually close to the compression ratio of ZIP.
In order to achieve very low memory consumption on the decompressor side (it was originally made for the C64), it uses more memory for compression on the computer side. Even with the TI-68k and TI-eZ80 series' 256 KB of RAM, it's not suitable for compression on the calculator side.
PuCrunch decompression was already used at some point on the TI-Z80 series; it's the de-facto standard compression on the TI-68k series, powering hundreds of ppg-compressed executables.

On the TI-68k series, the are two implementations of the decompressor, resulting from a long evolution, with optimizations by at least Thomas Nussbaumer, Greg Dietsche, myself, Samuel Stearley, on C code at first and later on pure ASM versions: a fast one, over 500 bytes and 60-80 KB/s speed, and a small / slow one, without a 256-byte dynamically generated lookup table on the stack, less than 250 bytes but not over 20 KB/s speed. In a shared library, only the fast version make real sense.