Line drawing support

Contributions to this software library are always welcome. Please ensure that you post program listings rather than .raw files. They give a reasonable idea of what your program does without having to load them into a DM42 and you can also include comments in your code. Check out the following link for a decoder/encoder: https://technical.swissmicros.com/decoders/dm42/

You can then copy/paste the listing and post it in "code" tags.
Tim Butler
Posts: 7
Joined: Fri Feb 02, 2018 10:05 pm

Line drawing support

Post by Tim Butler »

Here is my shot at LINE, with added support to draw a PATH of segments (open or closed) stored in matrix
and a demonstration NPGON, which draws some nested polygons.

NPGON_example.jpg
NPGON_example.jpg (24.8 KiB) Viewed 8710 times

LINE
y1 x1 y2 x2 -> T Z Y X
(x1, y1) (x2, y2) -> Y X
LINE2
x1 y1 x2 y2 -> T Z Y X

LINE and LINE2 draw a pixel-wide line between two points.

LINE is implemented completely on the stack and leaves all flags and non-stack registers unmolested.
It promises nothing about the stack on return.
It changes the mode to RECT, but restores it when done.
It uses the same argument order as PIXEL when identifying points and
following the same rounding and clipping behavior. It rounds arguments to the nearest integer
and will happily spend time trying to draw pixels that are off the screen.
Like PIXEL, LINE accepts complex arguments, but not in a matrix (see PATH for that).

LINE2 is a convenience function if you would prefer to supply your arguments in a different order.
LINE2 does not take complex arguments.

Others have posted horizontal and vertical line drawing routines that may be more efficient for those purposes.
My primary goal for LINE was an unsurprising interface wrt to PIXEL, and a pure stack implementation that
can be added to any program without concern.

PATH [(x1,y1), (x2,y2), ...]
PATHC [(x1,y1), (x2,y2), ...]

PATH takes a complex vector and calls LINE going from one point to another.
PATHC (closed path) connects the last point to the first.
Currently the order of points processed is undefined for multidimensional matrices.

I would like to explore support for additional data structures representing a path,
which would indicate if the pen should be up or down for each segment.
For example [ (x1,y1) 0 (x2,y2) 1 (x3, y3) 1 ...]
For these routines, the pen is always down.

NPGON - Draw nested polygons

This uses a variable menu which sets the following variables:

SIDES - number of sides for the polygons
N - number of polygons
mu - proportion of the subsequent vertex mixed into the current vertex when transforming the original polygon into the next.

In short, vertexes [ A' B' C' D' ](transpose) = [

Code: Select all

   [ 1-mu   mu    0       0    ]    [ A 
   [ 0      1-mu  mu      0    ]   X  B
   [ 0      0     1-mu    mu   ]      C
   [mu      0     0       1-mu ]]     D]

Typical values of mu are .05 or .1.
Set mu to 1.05 to demonstrate clipping.

Run NPGON, set and query the variables in the Variable Menu
and then press R/S to continue.

NPGON allocates an NxN real matrix for this transform.
It refers to ResX and ResY variables and uses a few numbered registers.
It cleans up the matrix variables and restores the RECT/POLAR mode when done.


LINE/LINE2

Code: Select all

00 { 222-Byte Prgm }
01▸LBL "LINE"
02 CPX?
03 GTO 01
04 X<>Y
05 R↓
06 R↓
07 X<>Y
08 R↓
09 R↓
10▸LBL "LINE2"
11 STO ST L
12 CLX
13 0.5
14 STO+ ST Y
15 STO+ ST Z
16 STO+ ST T
17 RCL+ ST L
18 IP
19 R↓
20 IP
21 R↓
22 IP
23 R↓
24 IP
25 R↓
26 MVAR "cxpt2"
27 FC? 73
28 GTO 02
29 RECT
30 COMPLEX
31 1ᴇ-5
32 GTO 03
33▸LBL 02
34 RECT
35 COMPLEX
36 0
37▸LBL 03
38 R↓
39 R↓
40 COMPLEX
41 STO- ST T
42 R↑
43 GTO 04
44▸LBL 01
45 -0.025
46 SQRT
47 5
48 +
49 STO+ ST Y
50 RCL+ ST Z
51 1ᴇ-5
52 FC? 73
53 CLX
54 RECT
55 X<>Y
56 COMPLEX
57 IP
58 X<>Y
59 IP
60 X<>Y
61 COMPLEX
62 RCL ST Z
63 COMPLEX
64 IP
65 X<>Y
66 IP
67 X<>Y
68 COMPLEX
69 RCL- ST Y
70 MVAR "nsteps"
71▸LBL 04
72 COMPLEX
73 X<0?
74 +/-
75 X<>Y
76 X<0?
77 +/-
78 X>Y?
79 X<>Y
80 CLX
81 LASTX
82 MVAR "normdxy"
83 X<>Y
84 X≠0?
85 STO÷ ST Y
86 MVAR "stashf"
87 RCL+ ST T
88 1
89 +
90 R↑
91▸LBL 05
92 COMPLEX
93 X<0?
94 GTO 06
95 X<>Y
96 X>0?
97 PIXEL
98▸LBL 06
99 R↓
100 CLX
101 LASTX
102 RCL+ ST Z
103 DSE ST Y
104 GTO 05
105 X<>Y
106 X≠0?
107 POLAR
108 RTN
109 MVAR "v180210"
110 END
PATH/PATHC

Code: Select all

00 { 142-Byte Prgm }
01▸LBL "PATH"
02 STO "PATHMAT"
03 INDEX "PATHMAT"
04▸LBL 00
05 RCLEL
06 I+
07 FS? 77
08 GTO 01
09 RCLEL
10 XEQ "LINE"
11 GTO 00
12▸LBL 01
13 CLV "PATHMAT"
14 RTN
15 MVAR "v180210"
16 END
17▸LBL "PATHC"
18 STO "PATHMAT"
19 INDEX "PATHMAT"
20▸LBL 00
21 RCLEL
22 I+
23 FS? 77
24 GTO 01
25 RCLEL
26 XEQ "LINE"
27 GTO 00
28▸LBL 01
29 RCLEL
30 XEQ "LINE"
31 CLV "PATHMAT"
32 RTN
33 MVAR "v180210"
34 END

NPGON

Code: Select all

00 { 424-Byte Prgm }
01▸LBL "NPGON"
02 MVAR "SIDES"
03 MVAR "N"
04 MVAR "μ"
05 VARMENU "NPGON"
06 STOP
07 EXITALL
08 MVAR "saverad"
09 1
10 FC? 73
11 CLX
12 STO 00
13 RCL "SIDES"
14 1
15 NEWMAT
16 ENTER
17 COMPLEX
18 STO "NPGNP"
19 MVAR "cxangle"
20 POLAR
21 2
22 PI
23 ×
24 360
25 FS? 42
26 400
27 FS? 43
28 X<>Y
29 STO 02
30 RCL÷ "SIDES"
31 STO 03
32 1
33 X<>Y
34 COMPLEX
35 MVAR "startpt"
36 2
37 STO÷ 03
38 CLX
39 RCL "ResY"
40 2
41 ÷
42 0.95
43 ×
44 RCL "SIDES"
45 2
46 MOD
47 X=0?
48 GTO 05
49 CLX
50 RCL 02
51 4
52 ÷
53 +/-
54 GTO 06
55▸LBL 05
56 CLX
57 RCL 03
58 COS
59 ÷
60 RCL 02
61 4
62 ÷
63 +/-
64 RCL 03
65 +
66▸LBL 06
67 COMPLEX
68 MVAR "mkpoly"
69 INDEX "NPGNP"
70▸LBL 02
71 STOEL
72 RCL× ST Y
73 I+
74 FC? 77
75 GTO 02
76 MVAR "centerp"
77 RCL "NPGNP"
78 RECT
79 RCL "ResX"
80 RCL "ResY"
81 COMPLEX
82 2
83 ÷
84 STO+ "NPGNP"
85 MVAR "mktrans"
86 RCL "SIDES"
87 ENTER
88 NEWMAT
89 STO "NPGNM"
90 INDEX "NPGNM"
91▸LBL 03
92 RCLIJ
93 X≠Y?
94 GTO 04
95 1
96 RCL "μ"
97 -
98 STOEL
99 J+
100 RCL "μ"
101 STOEL
102 FS? 77
103 GTO 05
104▸LBL 04
105 J+
106 GTO 03
107▸LBL 05
108 1
109 RCL "μ"
110 -
111 STOEL
112 RCL "SIDES"
113 1
114 STOIJ
115 RCL "μ"
116 STOEL
117 MVAR "drawlp"
118 RCL "NPGNP"
119 XEQ "PATHC"
120 RCL "N"
121 1
122 -
123 STO 01
124▸LBL 01
125 RCL "NPGNM"
126 RCL "NPGNP"
127 ×
128 STO "NPGNP"
129 XEQ "PATHC"
130 DSE 01
131 GTO 01
132 CLV "NPGNP"
133 CLV "NPGNM"
134 RCL 00
135 FS? 73
136 POLAR
137 RTN
138 MVAR "v180210"
139 END

-tim
Attachments
line_path_npgon_20180210.zip
(950 Bytes) Downloaded 383 times
mcc
Posts: 277
Joined: Fri Jun 23, 2017 5:10 am

Re: Line drawing support

Post by mcc »

Hi Tim,

This is great stuff!!!
Thank you very much!

Cheers!
Meino
DM 42 - SN: 00373, Firmware release v.:3.22. / DMCP 3.24. as compiled by SwissMicros
Vitasam

Re: Line drawing support

Post by Vitasam »

Hi Tim,
thanks for the great stuff!

How can I test e.g. LINE with a full display resolution?
Tim Butler
Posts: 7
Joined: Fri Feb 02, 2018 10:05 pm

Re: Line drawing support

Post by Tim Butler »

Thanks.
How can I test e.g. LINE with a full display resolution?
The sort answer is change your display to "full resolution" and then call LINE (e.g 1 1 400 240 LINE2).

So perhaps you are asking how to change the display to "full resolution"?

The official answer is in the DM 42 User Manual,
but I suggest downloading VirtV by dlachieze from his Access the DM42 virtual variables post. Make sure you get the most recent version and apply the "line 19/20 fix" mentioned in the topic by wawachief, if a subsequent version with that fix has not already been posted.

For awhile I was lazy and just ran the first part of wawachief's Mandelbot program.

VirtV, or something like it, should be part of a "DM42 essentials" collection.

-tim
mcc
Posts: 277
Joined: Fri Jun 23, 2017 5:10 am

Re: Line drawing support

Post by mcc »

Hi Tim,

WARNING! :)
THIS IS NO CRITISM AT ALL!
WARNING! :)

...my question is driven by curiousity and "want-to-know"-wishing. I started learning Focal/DM42/RPN at 31.12.2017....

I only know the MVAR-command as being used before the VARMENU command to build kinda GUI for a program on the DM42/HP42s.

But at least your NPGON-program for the whole program even after the VARMENU-command.
What is the advantage of doing so?

Thanks a lot for any help in advance!
Cheers
Meino
DM 42 - SN: 00373, Firmware release v.:3.22. / DMCP 3.24. as compiled by SwissMicros
Vitasam

Re: Line drawing support

Post by Vitasam »

Tim Butler wrote:
Mon Feb 12, 2018 5:40 pm
So perhaps you are asking how to change the display to "full resolution"?
Yes, that's was my question!
Thank you!
VirtV, indeed should be a part of a "DM42 essentials" collection!
Tim Butler
Posts: 7
Joined: Fri Feb 02, 2018 10:05 pm

Re: Line drawing support

Post by Tim Butler »

mcc wrote:
Mon Feb 12, 2018 6:54 pm
But at least your NPGON-program for the whole program even after the VARMENU-command.
What is the advantage of doing so?
I'm using MVAR commands in the middle of a program as string comments
that let me get my bearings when I'm editing programs on the calculator.
Also I've added a "version" MVAR the the END of a program right after an explicity RTN.

There is likely some execution time cost to call a no-op command,
(I haven't looked if Free42 does anything to optimize these out)
and there is some space cost for the size of the program, but I'm not
too concerned about changing offsets between goto's and local labels with Free42.

I figured if solve and integrate can tolerate them at the start of frequently called functions
then I can tolerate them in execute-once only sections of code.

My ultimate goal is to match these strings up with external annotations and more verbose comments
in an external text file, to produce a fully commented listing that survives a round-trip between .txt and .raw.

mcc wrote:
Mon Feb 12, 2018 6:54 pm
THIS IS NO CRITISM AT ALL!
I'm totally open to constructive criticism as to if this is a totally bad idea for some reason (e.g. undefined behavior, not portable, waste of resources).

Thanks for reviewing my code :)

-tim
Thomas Okken
Posts: 1100
Joined: Tue May 02, 2017 5:48 pm
Location: Netherlands
Contact:

Re: Line drawing support

Post by Thomas Okken »

Tim Butler wrote:
Tue Feb 13, 2018 4:54 am
I'm using MVAR commands in the middle of a program as string comments that let me get my bearings when I'm editing programs on the calculator.
Also I've added a "version" MVAR the the END of a program right after an explicity RTN.

There is likely some execution time cost to call a no-op command, (I haven't looked if Free42 does anything to optimize these out) and there is some space cost for the size of the program, but I'm not too concerned about changing offsets between goto's and local labels with Free42.
I wouldn't worry about the cost of executing MVAR or other no-ops. Executing programs is pretty efficient. You can see all the relevant code just by looking at continue_running() in common/core_main.cc.

continue_running() calls get_next_command() which fetches and decodes commands from the program; then it executes each command by calling its handler, and finally calls handle_error() to deal with errors, stack lift, non-local returns, etc.

I'm sure it's possible to shave off a few cycles from this logic, but for any program that does actual work, like perform calculations or draw or print, the program execution overhead is negligible.
User avatar
Walter
Posts: 3070
Joined: Tue May 02, 2017 11:13 am
Location: On a mission close to DRS, Germany

Re: Line drawing support

Post by Walter »

Tim Butler wrote:
Tue Feb 13, 2018 4:54 am
I'm totally open to constructive criticism as to if this is a totally bad idea for some reason ...
My English is insufficient for decoding that. Please explain what that shall mean. :?
WP43 SN00000, 34S, and 31S for obvious reasons; HP-35, 45, ..., 35S, 15CE, DM16L S/N# 00093, DM42β SN:00041
keithdalby
Posts: 564
Joined: Mon Apr 24, 2017 8:38 pm

Re: Line drawing support

Post by keithdalby »

Walter wrote:
Tue Feb 13, 2018 7:25 am
Tim Butler wrote:
Tue Feb 13, 2018 4:54 am
I'm totally open to constructive criticism as to if this is a totally bad idea for some reason ...
My English is insufficient for decoding that. Please explain what that shall mean. :?
"I'm open to constructive criticism with respect to whether this is a bad idea"

The superfluous "totally" that appears twice can be read like a 1990s California Valley girl from some naff sitcom, and the "for some reason" is a qualifier to express the author's doubt in their own statement. The "as to" is fine.
Post Reply