If it's set to that, all the game is slowed down. So it's safer to exclude it I think. Plus reading some theory in ThePenguin's tutorial on perfect grayscale, only a specific range is worth using. The best frequency is about 60Hz, the setting that slows the calc down is way beyond that.

I have several things:
1) Can you replace all the lower case letters with uppercase ones in the commented version? they take up a lot of MEM. (lowercase letters are two bytes right?)
2)If i don't know weather my user is using a ti83 or a ti84 then how do i compile? Should i just fallback upon the ti83 method? Is there a way for greylib, when run, to automatically choose the correct setting?
3) Can i strip out every thing i don't need to just leave the timer/inturupt stuff.
4)Is there any advantage of using the Crystal timer (84 method) verses just using interrupts?
5)Doest using the Crystal timer (84 method) mess with the cpu speed?
AND LAST BUT NOT LEAST:
Your library can render text with all shades of back/fore ground. And yet when i asked about the ti84 and the location of the sprite sheets, you "At least, I hope that information's correct. I haven't tried any of this, but this would be my best guess as to doing it correctly." (https://www.omnimaga.org/general-calculator-help/where-does-ti-(84)-os-store-the-sprite-sheets-for-chars/msg399940/#msg399940). So how exactly do you render text? ("performs magic" is not a good enoufe explanation for me    )

I have several things:
1) Can you replace all the lower case letters with uppercase ones in the commented version? they take up a lot of MEM. (lowercase letters are two bytes right?)

If you're trying to read and understand GrayLib in the calculator editor, you're probably going to have a bad time. It's a huge library that doesn't display well on a tiny screen, so navigating around in on a calculator isn't fun. Consider the lowercase letters taking up extra space a deterrent against trying to learn the library on-calc.

On a computer, you can also open multiple programs at once. Doing something like opening an example program and GrayLib together and looking at how they interact is probably the best way to get a feel for how to use the library. And the examples cover basically all the included commands and ramp up in difficulty, from simply invoking the built-in tuner, to screensaver-like bouncing text, to a very faithful clone of the first-generation Pokemon games' overworld movement engine.

2)If i don't know weather my user is using a ti83 or a ti84 then how do i compile? Should i just fallback upon the ti83 method? Is there a way for greylib, when run, to automatically choose the correct setting?

As Sorunome said, if both the 83+ and 84+ grayscale methods are included, the library will automatically choose the appropriate one based on which calculator the program is run on.

3) Can i strip out every thing i don't need to just leave the timer/inturupt stuff.

What Sorunome said about unused things being stripped out during compilation isn't exactly true. Axe doesn't have "real" functions, so the compiler doesn't have enough information to be able to remove unused code. But it does have preprocessor conditionals that allow the programmer to specify simple logic for whether or not to compile sections of the program. That's why there are so many options starting with GI, which stands for GrayLib Include. You'll notice that only the most essential two are included by default: saving/loading settings in an appvar across runs and "allocating" the four buffers. Even these can be disabled if you desire, but you'd need to implement your own logic to replace them.

4)Is there any advantage of using the Crystal timer (84 method) verses just using interrupts?

As Sorunome said, the crystal timer method provides much finer tuning. This makes it possible to minimize tearing artifacts, usually seen as a rolling horizontal line of garbled pixel values, much more. It may also provide more consistent tuning across different levels of battery charge.

5)Doest using the Crystal timer (84 method) mess with the cpu speed?

The CPU speed is unchanged by GrayLib. However, as Sorunome mentioned, the effective CPU speed of your code is greatly lessened because lots of CPU time is used by GrayLib. Your code probably only gets access to about 25% of the CPU time, which is unfortunate, but unavoidable. At least, it is on the 83+; I've been working on something to free up more CPU time with the crystal timer method, so stay tuned for that.

AND LAST BUT NOT LEAST:
Your library can render text with all shades of back/fore ground. And yet when i asked about the ti84 and the location of the sprite sheets, you "At least, I hope that information's correct. I haven't tried any of this, but this would be my best guess as to doing it correctly." (https://www.omnimaga.org/general-calculator-help/where-does-ti-(84)-os-store-the-sprite-sheets-for-chars/msg399940/#msg399940). So how exactly do you render text? ("performs magic" is not a good enoufe explanation for me    )

The "magic" is a lot of assembly to somewhat efficiently convert the character bitmap (not an Axe bitmap!) produced by B_CALL(_LoadPattern) into sprite data that is then displayed with Axe's Pt-Mask(X,Y,PIC)ʳ (masked 8x8 sprite) command. This is done for each buffer, setting blank and invert flags (explained in a moment) as necessary to get the correct values for that buffer. Included in this "magic" is logic to blank out the character bitmap if the blank flag is set and logic to invert the character bitmap if the invert flag is set. Combinations of these two flags give the four possible combinations of black-on-white, white-on-white, white-on-black, and black-on-black.

Ok thanks. But by "stip out" i litraly ment take all the Asm() opcodes out and insert them into my program. 

I'm not sure why you'd want to try to manually extract code from the library. It seems more difficult to manage than just including the library with the desired settings. Even the absolute minimum required to make the library work requires code from at least half a dozen different places in the library.

Ps: why cant you just make a small PDF for this, as i think it will be the easiest option for everybody.

I'm not great at making fancy documentation... But I guess I could at least pull out all the definitions and their comments into a separate file to be able to see every setting and routine available without code cluttering it up.

Quote from: c4ooo on April 24, 2015, 07:11:39 am

Quote from: Runer112 on April 20, 2015, 04:45:05 pm

-snip-

-snip-

The whole idea of a library is to make things easier. I don't see why you'd want to pick it apart to reuse the code just to do the same thing either.

So that I have a clear understanding of what is going on at any given moment.

Update: I've played around with it and it seems cool, but as a previous post mentions it takes like 33% of the cpu and even for a main menu of a prototype, the button controls are so sluggish it's kindof sad.

I've successfully torn out the juicy asm codes and put them in my program. Just want to make sure that you will be ok with me doing so? I will credit you for "writing the greyscale interrupt code" in my programs.

I'm still not sure why you wanted to manually pull the library apart to include bits of it in your program instead of simply letting the library and its preprocessor conditionals handle it for you, but I guess that's your prerogative. The point of the library is for people to be able to use the code after all, although you've done so in a strange way.

Also can you pls explain what exactly Gwait() does?

GWait() waits until the frame most recently offered up for display with GDisp() has been "fully" displayed. This means displayed twice for 3-level grayscale and displayed three times for 4-level grayscale, as that's how many grayscale updates it takes to go through all the phases of the dithering mask so all of the pixels have been displayed for the correct ratio of time. Whether or not this actually improves the visual quality, I'm not totally sure. But it's also useful as a timing mechanism to keep your program running at a constant rate.

<sarcastic comment> waiting seems the best thing to do when the interupt  takes up a third of the cpu time!</sarcastic comment>.

One third? I think you might be dreaming. The interrupt takes more like three fourths of the CPU time. I should probably add this information to the first post/readme to clarify for potential users that "perfect" grayscale is a very expensive feature.

Ps, in an earlier post on this thread you said you where writing a more efficient timer interrupt. Was that implemented or is it still coming?

I'm still experimenting with it. Nothing I can put into the library yet, but work is being done.

When I used GIHB for some before hooks, I think it didn't work for me. Used it a while ago, so don't know the specifics of what was wrong. When I looked at the code, it also called up a subprogram called GHB0(), which does not exist. Is it a typo with the last label of GHB?

Hay runer, why does the interrupt call tin84() every time it is executed? I know it probably does not take much cpu time, but its not like the user's calculator will switch from a ti84+ to ti83+ or vice versa wile the program is being executed. 

Edit: read the IRC log. Still, after being used to the philosophy that every last cpu cycle counts, your throwing several away several amazes me.