I would like to improve line drawing, but I need your help! I want to add horizontal and vertical line commands, and then also allow modifiers to all line and other drawing commands to allow white or inverted drawing. The question is, what syntax for these features looks best and/or is easiest to use?

I have added a poll to get your input on this question. Really this is two polls in one:
[1] What should the command for horizontal and vertical lines be?
[2] What should the syntax for white and xor drawing be?

So please look over all the options, and then pick ONE in the [1] category and ONE in the [2] category. Please consider the pros and cons of each; for instance, Horizontal seems like a great choice, but it might cause confusion with the existing Horizontal+ comamnd; and tokens like LinReg(a+bx) can be turned into much better names with the token hook, but without the token hook, they may look confusing.


I would like to note that, for specifying white and xor drawing modes, something like WhiteLine(X1,X2,Y1,Y2) is very much a possibility as well. But then the question is, what tokens should be replaced to be White and Xor? I don't see any obvious choices, but if you have an idea about it, pick the "other" option for [2] and post what your idea is.

I am in favor of preceding the commands with the letter modifiers.  This allows the same syntax to be used for both the horizontal/vertical lines, as well as the different drawing modes for the drawing commands, which would help keep the syntax more consistent.  Additionally, adding more and more extra tokens for new but similar commands can get annoying when they start being spread out over multiple menu's, with the letter modifiers we only ever have to look towards a single token.   

Also what would happen if you did something like this?

→XLine(,Y,X+3,Y+3)

You'd get a syntax error.

Then just add a newline between X and Line and it will work.

Quote from: Freyaday on December 18, 2012, 07:56:35 pm

The error message for a too-large app is "ERR:MEMORY". It really should be something more descriptive, like say, "ERR:TOO BIG FOR ONE PAGE" or something.

And that is too big for one error message. Anyways this isn't really a bug, and you still knew what it meant so it seems like it's descriptive enough. Maybe you won't even see that error eventually.

Does this mean we might be able to have two-page Axe apps in the future?

Quote from: Freyaday on December 19, 2012, 12:32:46 am

Quote from: Runer112 on December 19, 2012, 12:20:54 am

Quote from: Freyaday on December 18, 2012, 07:56:35 pm

The error message for a too-large app is "ERR:MEMORY". It really should be something more descriptive, like say, "ERR:TOO BIG FOR ONE PAGE" or something.

And that is too big for one error message. Anyways this isn't really a bug, and you still knew what it meant so it seems like it's descriptive enough. Maybe you won't even see that error eventually.

Does this mean we might be able to have two-page Axe apps in the future?

Eventually I hope so, yes. But as I've mentioned in previous posts, it's a logistical nightmare so don't expect it any time soon.

Alrighty, then!

Bump,

At school, I'm in a project that requires the linking abilities of my Ti-83+, and since I'm too lazy to make it in assembly (), I wondered : what's the protocol you're using with the Send( command ? My goal is to catch the bits sent with an Arduino in a byte.

Also, since these functionalities had been added to the latest version of Axe, I think you should remove the current poll and make a new one

In fact it's ok, I've already wrote my routine thanks