Last edited by MateoConLechuga on 20 Dec 2015 12:51:17 am; edited 3 times in total

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.

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.

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)?

"My world is Black & White. But if I blink fast enough, I see it in Grayscale."

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

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.

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.

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

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.

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.

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?

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.

Quote:

Drawing circles and things can also use this algorithm if I draw them in terms of lines.

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.

Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.