Realistically, that would be nearly impossible. So unless you're planning on learning z80 assembly, you'd probably need to recruit someone to produce the code for you. If you do in fact only need downscaling in one direction, it doesn't sound like it would be a huge undertaking, as one would just need to cut out the downscaling logic for the other direction from the existing scaled sprite Axiom. Or, it could be generalized to support separate horizontal and vertical scaling factors, and you'd just use a factor of 1.0 for one of them.

Yep, years of experience. Looking at my post history, I've been using Axe for just over 5 years now. And when I started, I also asked a bunch of questions. So you're on a good track.

By the way, if you want to ask somewhat simple questions like these in the future (which are totally fine; good, even), I'd recommend asking in the Axe Q&A thread instead of making a topic for each one. Having one thread concentrated with questions and answers is a lot nicer than a bunch of individual topics that die off within a few posts. You can even just browse around the thread as a kind of grab-bag Axe documentation that covers practical information and techniques that may not be documented elsewhere.

I believe such a routine has never been made. It may be possible to modify the existing scaled sprite Axiom to do that, though, especially if all you need is horizontal downscaling.

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.

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.

Objective:
Reduce file size, increase program speed, and general optimizations.

I love optimization!

Does space organizing your program cost space?

Nope (although in the source file, of course). The project's original name of "Axe Parser" is a pretty bad misnomer, since it suggests that Axe is an interpreted langauge, but it's actually compiled.

How can I avoid repetitively storing empty sprites without losing the tile-maps sprite synchronization?

Instead of having one tileset that's a mix of tiles with different color depths/palettes, I'd suggest segregating the tiles into different tilesets based on the colors used. For tilemap purposes, continue to treat these tilesets as if they were one, so tile values for eeach subsequent tileset continue to count up from where the last tileset left off.

As an example, say you have a white-black tileset of size x, followed by a white-gray tileset of size y, followed by a white-gray-black tileset of size z. Then a tile index t:

• Between 0 and x-1 corresponds to the white-black tile t
• Between x and x+y-1 corresponds to the white-gray tile t-x
• Between x+y and x+y+z-1 corresponds to the white-gray-black tile t-x-y

Is it possible to shrink down my map size while maintaining the same tile map?

Map compression is absolutely possible, and definitely suggested once you have a lot of map data. Many programs store their maps in a compressed form and, when that map is entered, decompress it to somewhere in RAM for quick accesses.

Your example shows a form of run-length encoding, which is a basic but fair map compression algorithm. However, Axe doesn't have any built-in compression routines, so you have to supply one. Perhaps you'd be interested in Iambian's Pucrunch decompression Axiom? It implements one of the better general data compression algorithms, in a similar class to the kind of compression used for .zip files.

---

Regarding specific optimizations to your program, I may come back and look for some later. But I'd like to at least post my general answers first.

Sure, I can break down the code a bit. Since only the tile lookup logic changed, I'm just going to focus on that. Also, I realized I could make the logic a bit nicer, so I'm going to explain this slightly different version:

Pt-On(A*8,B*8,((B+Y→D<32?A+X→C<32)?{D*32+C+GDB0},BLACK_TILE_INDEX)*8→C+Pic0)
Pt-On(A*8,B*8,C+Pic1)ʳ


((B+Y→D<32	If the Y-coordinate (saved for later in D) is between 0 and 31 (this is an unsigned comparison, so negative coordinates are interpreted as really large positive coordinates and are not less than 32)
?	And (a ternary operator with only one following clause is like a short-circuit AND operator)
A+X→C<32)	If the X-coordinate (saved for later in C) is between 0 and 31
?	Then:
{D*32+C+GDB0}	Look up the tile index at (C, D) in the map GDB0
,	Else:
BLACK_TILE_INDEX)	Use the black tile index
*8→C	Calculate the pointer offset of this tile index (saved for later in C)
+Pic0	Add the pointer offset to the tileset primary data pointer to obtain a pointer to the tile's primary sprite
... In the next sprite command...
C+Pic1	Add the pointer offset to the tileset secondary data pointer to obtain a pointer to the tile's secondary sprite