I looked at Kevin Kofler's documentation from the TIGCC website... and a lot of it really doesn't make sense. What I'm wondering is this: Is there a routine that one can call, sort of like the Sprite8,Sprite16, and Sprite32 functions, that takes a grayscale sprite and draws it? What do I need to do in my program to set up the grayscale buffers? How would I encode a grayscale sprite?

Newer documentation is available from https://debrouxl.github.io/gcc4ti/ .
FWIW, GCC4TI provides and normally documents sprite functions which are both faster and smaller than the dead ancestor's versions, despite supporting one additional drawing mode. This is one of the many contributions to the dead ancestor which were at best never merged for no good reason, or at worst rejected for outright improper reasons ("serves no purpose", despite multiple persons needing to use the contributed functionality over the years...).


For the simple drawing modes, multiple calls to the single plane sprite routine do the job. For the advanced drawing modes (transparency, etc.), you need other routines.


There are multiple grayscale-related examples in GCC4TI and its dead ancestor. Also, among others, you can have a look at a variety of TICT programs: Thomas Nussbaumer made them open source, they're reasonably well commented and some of them are simple.
At some point, in GCC4TI, I made sure that not only all of the examples could be built, but also, that their on-calc names do not clash with each other.


That's conventional, there exist multiple formats for grayscale sprites. Some routines expect (full data for one plane followed by full data for the other plane), others expect it the other way around, others take two different arguments for the light plane and the dark plane (which has the upside of allowing some sharing of light or dark plane data), others expect interlaced sprite data. And then there's masking data, when using that

There are basically two modern graphics libraries for TI-68k/AMS:
* ExtGraph, compile-time library from TICT, to which I added lots of routines (and bugs, though I fixed the known ones ^^). There are 30+ demo programs, many of which use grayscale routines;
* genlib, run-time library which requires users to install PreOS. Fewer, more focused functions; much less popular than ExtGraph. That does absolutely not mean it's bad, in fact ExtGraph took a number of clues from genlib, but requiring PreOS isn't universally considered a good thing for usability

At my suggestion, ExtGraph was also used as a source of inspiration for the TI-eZ80 graphics libraries, AFAIK.


BTW: don't hesitate to ping me more directly if you post other TI-68k-related topics and I don't see them quickly. I happened to notice this one on #cemetech, but sometimes I miss them.

Thank you! I looked at the documentation you suggested and a couple demos, but I still couldn't get grayscale to work fully. I realized that I need to call GranOn to turn grayscale on and GrayOff before exiting, and I'm substituting GrayGetPlane for LCD_MEM... but I only managed to get 2 grayscale levels.
I can't figure out why, but using GrayGetPlane(0) draws light gray (in Sprite8) and passing any other value causes it to draw with full strength. Is there something I forgot to do?

* do the demos in the GCC4TI distribution work unmodified ? Fresh builds of both do for me, on two different emulators;
* check your contrast settings;
* which emulator are you using, and while at it, which calculator model and hardware revision ?
* which version of GCC4TI are you using ?
* are you using idle() in your program ? That won't work when using grayscale.

Actually, I'm using GTC right now on a physical calculator while I try to remove the ancient version of TIGCC I had installed. I have tiemu installed, and its working.

GCC4TI is giving me some problems, because the installation script can't find binutils.

Here is the system information:
Computer: OSX Yosemite
Calculator: HW4, AMS 3.10

Contrast settings don't change anything, and I haven't typed in the source code for the demos yet, only looked at the source code.

Heh. GCC4TI's build scripts normally work much better than the dead ancestor's, especially for non-Linux ^^
Did you build from the Git repo (in my signature) ? The default "next" branch is good, and if you want to go further, the "experimental" branch contains size+speed optimizations on the grayscale routines.


Judging by the dates, GTC's library ought to support the 89T, but improper operation of grayscale could be a sign that it doesn't.

Here's what I did:
Clone the repo using git
cd trunk/tigcc-linux/scripts
./Install

I have the tarball with binutils in it; where do I put the tarball? Or should I extract the stuff first? I actually have binutils installed already, but the binaries are sitting in /usr/local/Cellar/binutils/ and they aren't symlinked to /usr/local.

This actually isn't as bad as tigcc. At least I get error messages instead of some non-working executables.

Well, the README down the main Github page for the repo indicates that you need to run updatesrc and run the install script from the just built source tree


updatesrc takes care of it.


Right, that's one of the improvements we made to the inherited build scripts, besides portability and general reliability. Silently producing broken builds isn't acceptable for just any sane build system...

Well, I figured out some more things:

1) I did run updatesrc, but I was in the wrong directory. I ran scripts/updatesrc instead of cd scripts and updatesrc. That's why it failed. Now, it gets all the way through until here:

...
-n .
-n .
.
Updating scripts...
chmod: ../gcc4ti-0.96b11/scripts/[^S]*: Not a directory
Creating symlinks...
Done.

Then, the install script is missing. If I copy the scripts over from linux-tigcc/scripts and run them, it starts a long compilation and ends with a couple thousand errors.

I'm not using linux and I'm following the linux instructions, so would that matter?

That should not. At the time, we definitely made sure that the build scripts worked on MacOS X - the scripts contain various workarounds for MacOS X peculiarities, so that unlike the dead ancestor, GCC4TI could be successfully installed on MacOS X without lots of user hand-holding - but that was over a decade ago
Still, maybe the build scripts need a few adjustments I wasn't aware of.

You're not telling me what those errors are, so I'm left to guessing what might be occurring
One source of errors that I can think of is the usage of Clang; while that is a good compiler in general, which provides good compatibility with GCC, such outdated versions of GCC use GCC-specific extensions and can only be built by GCC.
I fixed the code of ld-tigcc not to depend on non-portable GCC extensions such as nested functions, but getting a 15-year-old GCC version to build without GCC is a whole other matter...

Several thousand occurrences of "Warning: -s option is deprecated" and Warning: unused compiler option "-s", then some weird fatal errors with hundred line long stacktraces.

Also: another question:

Which one is better, GCC4TI, or TIGCC? The TIGCC website says TIGCC (which you call the "dead ancestor" or GCC4TI) is NOT dead, and the GCC4TI is a lower quality version. I'm kind of skeptical, because the last activity on GCC4TI was around a year ago and TIGCC hasn't been touched in 6-7 years.

Alright, but which ones ?
Also, what does

Code:

return on your build environment ?


Well, you're asking me, one of the creators and by far the main contributor to GCC4TI (after being a former contributor to the dead ancestor and being listed in the credits for my contributions)


Freedom of speech makes the dead ancestor's maintainer free to pretend whatever he wants, and even try to convince others about anything

On my side, I'll just look at some relevant facts:
* you've correctly found which project has seen the largest amount of work and the most recent work, though there's not been that much work since 2012, but the ancestor is worse in that respect;
* in this topic, you've already read about multiple useful changes performed on the GCC4TI side.

I'll now give a very high-level overview of the effect of the changes performed on the GCC4TI side:
* better usability: build scripts !, VTI support even though that's not really advised, etc. - and of course, on the developer side, switching from the awful CVS to a usable VCS, at first SVN, then Git like nearly everybody else;
* better reliability: build scripts !, or merely making the source control tree complete: on the dead ancestor, some files are available only in some release tarballs, they're missing from the CVS repository;
* better portability: code, build scripts !!
* more features: new functions, etc. - but also the integration of the TI-68k Developer Utilities, a TICT project which Thomas Nussbaumer always meant to be partially integrated to the development environment, and which, nearly two decades after its creation, still serves as a source of inspiration - and relatively high priority todo/wish list item for a CLI front-end to libti* ( https://github.com/debrouxl/tilibs/issues/31 );
* more optimizations: some code bits very commonly duplicated across AMS native programs were optimized on the GCC4TI side, e.g. SAVE_SCREEN, _rowread, the Sprite* functions; qsort() is quite a bit faster despite being smaller; etc.
* fewer bugs: last time I checked, even my fixes on the GCC4TI side for calculator-crashing bugs reported on the dead ancestor's side after the creation of GCC4TI did not get integrated into the dead ancestor. In addition to this, for instance, GCC4TI has a bsearch() routine whose algorithm actually works (and is smaller, too).
* better documentation: for instance, there's a configuration sample for the documentation generator tools. Fortunately, I had a working config file since my earlier attempts at contributing more to the dead ancestor...

The full details are in the GCC4TI commit history, you or anybody else can technically check for yourself my statements anyway, and can make your own opinion about both sides' statements and underlying motivations


Is GCC4TI perfect ? Well, nothing is.
Is it, on average, in better shape than the dead ancestor ? Definitely, for multiple reasons I outlined. We performed software engineering on it, which makes it more usable over a decade later.
Could we have done better ? Definitely, by spending much more time on it. However, I spent much more time on libti*/gfm/tilp, because those had - and still have - far more users, so that's where spending time makes the most sense. Even if for a while, I clearly had more fun on the GCC4TI side.


Some changes we did intentionally not make on the GCC4TI side include pursuing the folly of imposing a KDE-based IDE on all platforms (without fixing the Delphi IDE's well-identified defects, at that). More than 11 years after the announcement of this plan - after a number of other events - triggered the creation of GCC4TI, as we correctly predicted:
* not only KDE remains basically nonexistent in the non-Linux world, which happens to include the Windows and macOS giants, but...
* 1) the severe instability of KDE 4 and KDE 4-based programs during the two first years of its life cycle cost extremely dearly to the market share of KDE even on Linux. API breakage over the KDE 4.x series, some of which hit that KDE-based IDE, made KDE 4.x even harder to support. In terms of popularity, KDE never recovered, even with '2020 KDE 5.x, despite its general level of features and polish... And with Qt 6 on the horizon, I guess that there will be a KDE 6.x series, so more breakage at first.
* 2) in the meantime, FreePascal and Lazarus improved in terms of reliability, portability and compatibility with Delphi, so the maintenance and evolution of Delphi-based code from a Linux enviroment is easier than it used to be.
Ah, forgot to mention: the code quality and maintainability of the KDE-based IDE are terrible. Like the my other statements, this one can easily be checked by looking at the code: multiple huge and poorly commented files, to begin with.

gcc --version (which is clang --version) gives:
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin15.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

And the errors are the generic Apple clang stuff:

Code:


EDIT:

Later on, more errors appear.


Code:


I think it's because of clang. Should I remove the symlink to gcc and actually install it?

Yes, you'll need to use GCC to build the ancient GCC 4.1.2 & binutils 2.16... and probably an older version of GCC, even: GCC 4.9 from the Debian Jessie timeframe and 5.x are supposed to be decent enough for a Linux environment, but a GCC 4.9 cross-compiler targeting Windows is known to produce a broken compiler (for floating-point values, at least), and I haven't tested the build on recent GCC versions...
Temporarily changing the gcc symlink will do the job, but that shouldn't be necessary if you enter the name of another executable (which should probably be in your PATH, though I'd expect a full file path to work as well) at the beginning of the invocation of the Install script.

Well, I was unable to get gcc to install. 4.9 isn't even available anymore except in source format, and it refuses to build with Apple's clang.

On the bright side, I figured out the graysacle thing:
Light gray: Draw the sprite to the LIGHT_PLANE
Med gray: Draw the sprite to the DARK_PLANE
Dark gray: Draw the sprite to both planes

Thank you for all your assistance!

ExtGraph's sprite routines do that for you, but since you don't have a working build of GCC4TI yet, ExtGraph won't help you right now...

Well, I wrote a sprite routine. It takes a 2D array of chars that gives the gray level. 0 is transparent. passing 1 for cache means skip recalculation of the panes and just draw it. The code works, but it's slow and I really need to optimize it. I wish I could get GCC4TI to work...

Code:

I don't have access to a MacOS X computer I could use interactively for testing purposes, I'll have to get that somehow (or have someone else try things for me while we communicate through IRC)

I have tested some things and gave the log to debrouxl for further analysis, hopefully we can fix a few things in the code and build scripts to make it work more smoothly.

Adriweb's log of a build using GCC 10 shows the same build errors as in https://github.com/debrouxl/gcc4ti/issues/13 .