SirC's flood-filler would probably be easily modifiable to make grayscale.

IIRC the Circle() routines are coded in such a way that it is very difficult to make it draw on the back buffer.

For For() loops, just use a While loop instead and increment manually, it probably is just as optimized anyway.

As for the flickering on the grayscale, I think Deep Thought already mentioned going across the screen by rows instead of columns as per thepenguin77s grayscale tutorial, so I'll just remention that again

And now I have something I want to say...
People, this has kind of been bugging me. Feature-request-wise, remember that Quigibo is really busy. Complex routines are hard to put in, and most of the time they can easily be written in Axe anyway with a few commands (like the for() and the paint bucket thing). Figure out how to do it yourself; don't just ask for a feature request because you don't want to take the time to code your own routines. Another example: grayscale. Are you really complaining that the shades of gray are too dark/light? It's freaking grayscale on a monochrome screen. Seriously, any asm programmer will tell you that grayscale is a huge pain to program correctly and IMHO we should be grateful that we have it as good as it is. I'm talking to everybody here. I feel like some people are taking Quigibo for granted, and imo something like a paint bucket is in no way really important enough to merit its own command. Something like bit-manipulation, label-addresses or switch-statements or big-endian nibble reads hint hint hint are more appropriate candidates for feature requests. And did someone really ask for multitasking?

I guess what I'm really trying to say, is just try and think about what you are asking for before you post, and whether or not it's practical. Then think about how you could code it; a lot of things are not difficult to code by hand anyway. Some languages don't even have for() loops, for example. And when you do post, try to explain what you are talking about. Not everyone knows what the phrase "stateful goto" or "try/catch" means.

Sorry to rage like this but I felt the need to say it. No offense to anyone intended. Also I do not want to start any kind of war or fight so if you have a problem with this, rate it down and pm me. Leave it off the forums, thanks 

My bad. I now resolve to be more explanatory/serious in the future.

Quote from: Qwerty.55 on March 27, 2011, 11:58:25 pm

What about a buffer swap command instead of implementing bunch of <command>^r's?

You could just use Exch(L3,L6,768) for this.

I had forgotten about Exch(. This certainly makes my programs smaller.

Speaking of which, I think it is now time to start an "Axiom Request" thread for requests such as the paint bucket, which legitimately would be a lot better as an assembly command, but wouldn't be used enough to justify being part of the standard language.  It would also be a good to keep a list of Axioms created so far so people have access to those.

The highest priority requests to me right now are actual features of the compiler, user interface improvements, and language control features.  Commands are low priority right now unless they are absolutely essential or super easy to implement since this is what Axioms are for.

I still think a "jump to label" from the compile menu would be a handy feature. Maybe like pressing PRGM in the compile menu would display a list of the labels in the program and allow you to quickly jump to a label in your program. It would be much faster than going through the actual PRGM menu and having to scroll through and find the section of code you want to look at. I know this wouldn't be an incredibly necessary feature, just a convenience thing...And it certainly shouldn't be a priority over other features that actually improve the Axe language

I have a feature request that would significantly reduce the size of Axe programs: automatically calculate constants. For example, L1+4 is a constant, but when Axe encounters it, it loads L1, then adds 4, instead of simply loading the end value. So, when Axe encounters a string of constants in the program, it actually runs through the operations of adding, subtracting, multiplying, and dividing until a variable is encountered. For example,
{L1+5}→{L3+2}
should parse as:
ld hl,saveScreen+5
sto hl,appBackupScreen+2


I still think a "jump to label" from the compile menu would be a handy feature. Maybe like pressing PRGM in the compile menu would display a list of the labels in the program and allow you to quickly jump to a label in your program. It would be much faster than going through the actual PRGM menu and having to scroll through and find the section of code you want to look at. I know this wouldn't be an incredibly necessary feature, just a convenience thing...And it certainly shouldn't be a priority over other features that actually improve the Axe language

I second that.