Two new screenshots with the nifty dithering have been posted.

They're beautiful. Amazing work!

I find it sad that you aren't willing to release the source code for your library. This is especially bad for libraries, because we don't and never will guarantee a stable ABI (Application Binary Interface) for TIGCCLIB. So if TIGCC changes, closed-source static libraries have to be recompiled by their authors or become useless. There have been a few closed-source static libraries in the past. None of them works anymore. (The authors aren't recompiling them and nobody else can. In one case, the author has even lost the source code, something which just cannot happen if you release it.) TIGCC works hard on source compatibility, but not binary compatibility. It is usually not needed because TIGCCLIB is statically linked, so if you rebuild your project anyway, you can also recompile everything. Closed-source static libraries are the one use case where that breaks, but I'm not going to guarantee a stable ABI (which keeps me from doing improvements, see all the arguments against a stable Linux kernel ABI for binary modules, they apply just as well to TIGCCLIB) just for these.

In addition to those practical considerations, your source code would probably also be useful for learning purposes.

That and you might get help. If the source was open someone who know asm could try implimenting 64 bit fixed point numbers.

64 bit? Sure you want that? It would be faster than floats, but still, long long operations are slow! 32 bits is the maximum that makes sense IMHO. Maybe even 16 bits for (relatively) fast multiplication/division (not that mulu/divu/muls/divs are speed wonders, but they're definitely faster than __mulsi3 and _du32u32/_ds32s32) if the low accuracy can be tolerated.

The closedGL doc states that the previous attempt at fixed point did not have enough numerical robustness. I'm assuming that first attempt was with 32 bit fixed point. So 64 bit fixed point should be able to handle it.

yeah 64 bit fixed point is slow but compared to ti's BCD floats its considerably faster.

can someone explain the reasoning behind making this program closed scource? you do give the program away for free, why not the scource?

I agree with Kevin on this one, since it is free why not release the source? I could see reasons for certain programs like HW3Patch not to release the Source Code because it could pose as an extreme threat at the destruction of a calculator if an abusive programmer got a hold of the source, but there is really no reason for not releasing the source in this case. :)

True, and then people could even use stripped-down or modified versions if they needed slightly different functions. I know I can never use a routine as it is, I always have to rewrite half of it and tweak the rest to make it do just what I want, and a lot of other programmers probably are the same way.

You're the one with the attitude problem, Kevin. You're using your position as a TIGCC developer to try and strong-arm people into making everything open source. We know you don't like closed source, but not everyone shares your position.

The problem isn't with closed source libraries, the problem is your refusal to provide a stable ABI. You will argue that you want to be able to add features, but that's silly. You can easily add features without breaking compatibility.

Example: Mac OS X 10.2 and later support lazy binding, so a library built to target OS X 10.1 won't link with an executable being built for OS X 10.1, but a library built to target Mac OS X 10.1 can be linked with an executable built for OS X 10.2.

You either refuse to or are incapable of designing a supportable ABI. I tend to believe the former, considering how often you try to use this "feature" as a way to bully developers of closed source libraries.

Sweet... but does this work with a TI-89 Titanium. If it doesn't, is ther a way to make it work???

Anything that works for TI-89 will work for the 89T if you use HW3Patch on the 89T and possibly Ghost Buster on the program.

It crashed my TI-89Ti, but works fine for the 89. I tried to compile it for the 89ti, but it was not compiling in tigcc for me.

Which one... The HW3 Patch or Ghostbuster???

What's this library going to be used for???

Cool screenshots.

That's it???

I know this is a bit off topic, well, it has to do with graphics, but does anyone, and i mean anyone, know what is required for Ti greyimage by Lexou, located in the windows graphics archives, to work? it is supposed to be able to convert bmps to grayscale but instead it shows an error everytime I try to compile. I have seen examples submitted to the archive which use this program so I know that somebody got it to work.

Try e-mailing the author (if you've already read the README.txt, that is). You'll get a better answer and won't annoy anyone with completely off-topic posts.

Wow.. somehow that sounds reeeeally familiar.. anybody see the survey? haha

Hi,
It's amazing how great diethering looks on screenshot :)

Can someone post here how fast it is?
I mean how many polygons/vertexes it can compute and display per second (can be not accuarrely).
I don't have Ti calculator, so I can't do it by myself.

Thank You.