Graphics coordinates vs Pixels coordinates

[Oulan]

To draw an ARC, the radius is given in PIXEL, not in graphical units. So when making some drawing I observe some peculiar behaviour. If the graphical units are not well defined, you always got a "visual circle" but in fact an "ellipse" in term of graphical units.
The following program try to draw a circle with ARC and the same circle with SIN&COS+LINE.

Code:

#pragma mode(separator(.,;) integer(h32))
EXPORT gl() BEGIN
 LOCAL ra:=10.0;
 LOCAL o,x,y,xx,yy,dn;
 RECT();HAngle:=1;
 Xmin:=-15.9;Xmax:=15.9;
 Ymin:=-10.9;Ymax:=11.0;
 ARC(0.0,0.0,ra*320/(Xmax-Xmin),0,360,#FF0000);
 dn:=0;x:=0.0;y:=0.0;
 FOR o FROM 0.0 TO 360.0 STEP 5.0 DO
  xx:=ra*COS(o);yy:=ra*SIN(o);
  IF dn THEN LINE(x,y,xx,yy,#000000);END;
  dn:=1;x:=xx;y:=yy;
 END;FREEZE;RETURN;
END;

I started with

Code:

Xmin:=-16.0;Xmax:=16.0;
Ymin:=-12.0;Ymax:=12.0;

in the hope to have a square graphical units, but in this case the SIN&COS circle was not corresponding to the ARC one. I finally found that using

Code:

Xmin:=-15.9;Xmax:=15.9;
Ymin:=-10.9;Ymax:=11.0;

gave a quite good overlapping circles and a quite good square graphical units .
My question is the following, are those differences explained somewhere in the manual ?
I thinks that the graphical units do not use the full vertical size of the screen (to keep some space to draw the menus ?)

It seem ok to do so, but for ARC vs ARC_P with the radius given in PIXELS and not in graphical units there is some discrepancy. In fact ARC_P should always give a perfect circle. But ARC should use a radius in graphical units and could result in drawing an ellipse if graphical units are not rectangular. This will be more consistent. (And easier to deal with as using C->PX and PX->C to deal with distance is not very friendly).

Olivier

[Carlos295pz]

The graphic coordinates are oriented to applications, that is why not all of them are configured in the same way and care must be taken with this (programming directly on an app).

(03-19-2019 11:57 AM)Oulan Wrote:  I thinks that the graphical units do not use the full vertical size of the screen (to keep some space to draw the menus ?)

Exactly, 21 pixels height menu, the calculator in some cases pushes us to use DRAWMENU, as well as the WAIT (-1) or MOUSE when touch in that area.

(03-19-2019 11:57 AM)Oulan Wrote:  It seem ok to do so, but for ARC vs ARC_P with the radius given in PIXELS and not in graphical units there is some discrepancy

I agree, had not noticed, in the Geometry App your solution is simple.

----------------------

There are Apps that are not graphically configurable, for this case I would recommend the Geometry App, it always has a square relationship and allows defining the pixel size and only one corner point. Assuming the menu height of 21 pixels, a full screen and a circle, it can be set up in this way:

Code:

PixSize:=.1;
Xmin:=-16;
Ymin:=-12+21*PixSize;
LOCAL r=2;
RECT;
ARC(0,0,r/PixSize);
TEXTOUT("r="+r,0,-r);
FREEZE;

It is timely to mention that even when working with decimal coordinates, a conversion to pixel of integer coordinate is performed; also that the Xmin+320*PixSize will drop a pixel off the screen.

[cyrille de brébisson]

Hello,

When I first codded the ARC function, I did NOT yet have the elipse drawing function codded.. So I had this exact issue, how to draw circles on a non homogenous cartesian plan...

This is when I thought that circles would mostly be drawn by people that were doing pixel based graphics, not cartesian based graphics and that therefore it would not be ab issue to have the radius in pixels as ARC would, most likely, very rarely be used (ARC_P would be used instead)...

This is the root reason for the pixel only radius for ARC...

I then codded the elips as it was needed for something else and extended ARC_P, but did not change the pixel based parameters...

You could ask: but then, why do an ARC and not just an ARC_P... the reason is that the drawing and drawing_P functions all share the same code with a semi automatic way for the system to test and convert from cartesian to pixels... so having both was no extra work...

Cyrille

[Carlos295pz]

I think I understood very badly the thread xD
The solution for a circle that allows a rectangular relation would be very similar to your initial code, adding the second radius in Y, it is not uncomfortable in my opinion.

Code:

 ARC(0,0,ra*{320/(Xmax-Xmin),240/(Ymax-Ymin)},#FF0000);