# Requesting advice / input from a user standpoint.

Hi all, quick question:

Let's say you are writing a function that will draw an ARC with an X/Y origin, with a radius R and a start angle and end angle in degrees. 0 degrees is at the top (i.e. the 12 o'clock position), 90 is at 3 o'clock, etc...

The function will accept a start and end angle in either direction (that is, you can draw from 90 to 0, or from 0 to 90 and the pixels will be drawn in the correct order).

Now here's my users-point-of-view question:

Say you entered -360 degrees for a start angle and +360 degrees for the ending angle.

Note that both -360 and +360 are equivalent to 0 degrees.

Should the function:

(A) Start at -360, (12 o'clock) draw two complete circles, stopping at +360 (12 o'clock)?
(B) Do nothing since drawing from 0 to 0 results in nothing?
(C) Other idea?

Input will be appreciated. Thanks!

You would use the circle( ... ) function.

boolrules:
You would use the circle( ... ) function.

First of all, circle cannot draw an arc. Secondly, that's not what I asked.

A competent and responsible user would read the documentation for the arc() function.
What will that documentation (written by the competent and responsible programmer) have to say about the input parameters?

Normally you would restrict the inputs to occur only on one single circle. Either -180 to +180 or 0 to 360. Then the order of inputs is important. An arc from -170 to +170 could be a short arc while an arc from +170 to -170 would go the long way around.

Validate the user input. Tell the user that an arc can be max 360 degrees and draw nothing would be my approach.

You might have considered this, but if not: how should the arc be drawn if the numbers are e.g. -90 and +90? Draw clockwise from 9 o'clock through 12 o'clock to 3 o'clock or counterclockwise from 9 o'clock though 6 o'clock to 3 o'clock?

It depends on requirements but you might want to consider to change the 'end' parameter to a 'length' in degrees. In that case, you can allow a 'length' of -360 to +360 and you know the direction.

jremington:
A competent and responsible user would read the documentation for the arc() function.

Do they still exist? I think I'd expect (C) one full circle drawn clockwise from 1200 to 1200 (but I've had lots of gin so may wish to reconsider this after the festive period.

sterretje:
Validate the user input. Tell the user that an arc can be max 360 degrees and draw nothing would be my approach.

You might have considered this, but if not: how should the arc be drawn if the numbers are e.g. -90 and +90? Draw clockwise from 9 o'clock through 12 o'clock to 3 o'clock or counterclockwise from 9 o'clock though 6 o'clock to 3 o'clock?

If I say "start angle = -90" and "end angle = +90", then that means I want the "angle" variable (in the code) to go in a positive direction (i.e. towards +90). So, the code would come up from the 9 o'clock position, pass through 12 o'clock and stop at 3 o'clock.

To go "under" past 6 o'clock and ending up at 3 o'clock would require the "angle" variable to go more negative (that is, 6 o'clock is -180 and the destination is -270).

To go under I would have to specify "start=-90, end=-270".

To go under from right to left, I would specify start=+90, end=+270.

Of course, I still wonder... what makes more sense? If I specify "start=0, end=720", should it draw two circles, one on top of the other, or should it do nothing (since both 0 and 720 are the same point in degrees)?

jremington:
A competent and responsible user would read the documentation for the arc() function.
What will that documentation (written by the competent and responsible programmer) have to say about the input parameters?

Crabby tonight? Santa left you a lump of coal?

Seriously though, where is there an "arc()" function? All I could find on Google was old DOS and Borland C stuff.

There is no "arc()" in GCC...... I'm trying to write one for my Noritake graphical VFD display driver library for AVR/Arduino.

Actually, it's done and it works... all I need to know is if it makes more sense to draw redundant pixels or only draw the actual result of "360 degree rollover" (for lack of a better thing to call it).

MorganS:
Normally you would restrict the inputs to occur only on one single circle. Either -180 to +180 or 0 to 360. Then the order of inputs is important. An arc from -170 to +170 could be a short arc while an arc from +170 to -170 would go the long way around.

Yes exactly!

The real reason I'm doing this is to make designing and drawing "analog gauges" on a VFD graphics display easier.

Rather than draw a circle, then erase half of it, try to figure out where to draw lines, etc... there will be two ways to make an "analog" display:

(1) Draw your own arc, label it and draw/redraw a line for the "needle".
(2) There will be various "draw XXX" functions, one of which will be an analog guage. All you will do is specify where you want it on the display, how big it should be, what it should display and what it should accept as input.

My library also draws any polygon, with any number of sides and rotated at any angle, plus a huge bunch of other features that are in-work.

That's what I need "arc()" for.

MorganS:
Normally you would restrict the inputs to occur only on one single circle. Either -180 to +180 or 0 to 360. Then the order of inputs is important. An arc from -170 to +170 could be a short arc while an arc from +170 to -170 would go the long way around.

Here’s a short video I made of a typical “analog meter” on a 128 x 64 pixel VFD display. 9.2 megabytes if you have a fast line view it (if you want to)  