Discussion:
Rotating a Colour-Filled Square
(too old to reply)
Richard Ashbery
2019-11-12 14:05:03 UTC
Permalink
Rotating a square can be done with

MODE 1920,1080,32
FOR theta = 0 TO 360 STEP 90
x = 1000 * SIN(RAD(theta+45))
y = 1000 * COS(RAD(theta+45))
IF theta = 0 MOVE 1920+x, 1080+y ELSE DRAW 1920+x, 1080+y
NEXT

By altering the angle theta+45 to theta+55 the square can be made to
rotate 10°. If I try something similar with a filled square using
'RECTANGLE FILL' or PLOT &65 I'm unable to rotate it. Has anyone got a
simple routine that rotates a colour filled square about the screen
centre?
Sebastian Barthel
2019-11-12 23:04:27 UTC
Permalink
Post by Richard Ashbery
Rotating a square can be done with
MODE 1920,1080,32
FOR theta = 0 TO 360 STEP 90
x = 1000 * SIN(RAD(theta+45))
y = 1000 * COS(RAD(theta+45))
IF theta = 0 MOVE 1920+x, 1080+y
ELSE DRAW 1920+x, 1080+y
NEXT
By altering the angle theta+45 to theta+55 the square can be made to
rotate 10°. If I try something similar with a filled square using
'RECTANGLE FILL' or PLOT &65 I'm unable to rotate it. Has anyone got a
simple routine that rotates a colour filled square about the screen
centre?
ON ERROR PRINT "ERROR IN ";ERL : END

MODE 1280,960,8

CLS
ORIGIN 1024,1024
S=0.05

FOR R=0 TO 2*PI STEP S

POINT SIN(R)*300, COS(R)*300
DRAW SIN(R+1.571)*300,COS(R+1.571)*300
DRAW SIN(R+3.141)*300,COS(R+3.141)*300
DRAW SIN(R+4.712)*300,COS(R+4.712)*300
DRAW SIN(R)*300, COS(R)*300

FILL 0,0

WAIT : CLS


NEXT


If You want to speed up things, You should use an array with the
precalculated SIN/COS values.

The only real difference to Your lines is the single FILL command.

The effect can't be seen if the MODE command isn't given.


All the best,
Sebastian
Richard Ashbery
2019-11-13 12:54:00 UTC
Permalink
Post by Sebastian Barthel
MODE 1280,960,8
CLS ORIGIN 1024,1024 S=0.05
FOR R=0 TO 2*PI STEP S
POINT SIN(R)*300, COS(R)*300 DRAW
SIN(R+1.571)*300,COS(R+1.571)*300 DRAW
SIN(R+3.141)*300,COS(R+3.141)*300 DRAW
SIN(R+4.712)*300,COS(R+4.712)*300 DRAW SIN(R)*300, COS(R)*300
FILL 0,0
WAIT : CLS
NEXT
If You want to speed up things, You should use an array with the
precalculated SIN/COS values.
The only real difference to Your lines is the single FILL command.
The effect can't be seen if the MODE command isn't given.
Excellent - many thanks Sebastian

Richard
Richard Ashbery
2019-11-13 17:05:44 UTC
Permalink
Post by Richard Ashbery
Post by Sebastian Barthel
MODE 1280,960,8
CLS ORIGIN 1024,1024 S=0.05
FOR R=0 TO 2*PI STEP S
POINT SIN(R)*300, COS(R)*300 DRAW
SIN(R+1.571)*300,COS(R+1.571)*300 DRAW
SIN(R+3.141)*300,COS(R+3.141)*300 DRAW
SIN(R+4.712)*300,COS(R+4.712)*300 DRAW SIN(R)*300, COS(R)*300
FILL 0,0
WAIT : CLS
NEXT
Excellent - many thanks Sebastian
Richard
Further to my last reply...

Hi Sebastian

I forgot about the FILL statement which I can also use in my original
code but what I'm really after is a method to overlay the existing
square with other successively smaller squares in alternating colours.
Its easier to see it illustrated...

http://www.riscosbasic.uk/problems/square.zip

Richard
Sebastian Barthel
2019-11-13 23:35:41 UTC
Permalink
Post by Richard Ashbery
I forgot about the FILL statement which I can also use in my original
code but what I'm really after is a method to overlay the existing
square with other successively smaller squares in alternating colours.
Its easier to see it illustrated...
http://www.riscosbasic.uk/problems/square.zip
This doesn't seems as easy as it should be ...
I tried it with the biggest square plotted first. Then the second on top
of it. But, from this second square on to the last and most little square
the FILL command didn't work anymore in the expected way. I think, the
FILL will only fill if there is an unpainted background colour. It
doesn't work on top of an already painted structure.

So - if one wants to use the FILL - the sqares have to be painted the
other way round; from the little one in the centre to the outmost an
biggest one.

If there is a space filled with background colour between the line of the
new-drawn outermost square an the already painted an filled inner square
the FILL command works in the expected way.

To find a point where the FILL can start in a defined way, I sorted the X-
values and used the one on the left side (XMIN). The y-value wich belongs
to this (XMINY) is corrected by a minimal absolute amount, wich sets the
start of the FILL in a region inside the square.

All this doesn't work if this starting point is located outside of the
square or if the inner square overlaps with the bigger one.

You can try this by setting the maximum square length (F) (F as in
"factor", because it's the zooming factor for the calculated length) from
500 to e.g. 800. Or You can change the STEP to a lesser value (30).

To ease the finding of a good combination of all the factors involved
there is a little CIRCLE drawn at (XMIN,XMINY) wich should be removed,
with a REM command, once a good combination has been found.


The ANGLE is (re)calcuated in a "fancy" form with a SIN to give a fine
rotating effect. This could be exchanged by an addition of a fix value to
increase the ANGLE for every square - ANGLE=ANGLE+25 ; this should give
the effect You initially wanted to plot (without additional animations).

It's a little bit "flickery", but gives a fine little demo ... :)
I hope You enjoy it.




REM BBC BASIC Code , rotating squares - filled with fancy colours

ON ERROR PRINT "ERROR IN ";ERL : END

MODE 1280,1024,8

CLS : ORIGIN 1024,1024

S=RAD(0.5)

FOR R=0 TO 2*PI STEP S

ANGLE=R

FOR F=50 TO 500 STEP 75


GCOL ( F MOD 7 )

X0=SIN(ANGLE)*F : Y0=COS(ANGLE)*F

X1=SIN(ANGLE+1.571)*F : Y1=COS(ANGLE+1.571)*F

X2=SIN(ANGLE+3.141)*F : Y2=COS(ANGLE+3.141)*F

X3=SIN(ANGLE+4.712)*F : Y3=COS(ANGLE+4.712)*F

POINT X0,Y0

DRAW X1,Y1 : DRAW X2,Y2 : DRAW X3,Y3 : DRAW X0,Y0


XMIN=X0 : XMINY=Y0

IF XMIN > X1 THEN XMIN=X1 : XMINY=Y1

IF XMIN > X2 THEN XMIN=X2 : XMINY=Y2

IF XMIN > X3 THEN XMIN=X3 : XMINY=Y3


IF XMINY < 0 THEN XMINY=XMINY+4 ELSE XMINY=XMINY-4

FILL XMIN+15,XMINY

GCOL 200,200,200 : CIRCLE XMIN+15,XMINY,3


ANGLE=ANGLE+RAD( SIN(ANGLE)*7)


NEXT F

FOR I=0 TO 2500 : NEXT I : WAIT : CLS

NEXT R
Sebastian Barthel
2019-11-14 12:20:19 UTC
Permalink
Post by Sebastian Barthel
... but what I'm really after is a method to overlay the existing
square with other successively smaller squares in alternating colours.
To find a point where the FILL can start in a defined way, I sorted the
X-values and used the one on the left side (XMIN).
The y-value wich belongs to this (XMINY) is corrected by a minimal
absolute amount, wich sets the start of the FILL in a region
inside the square.
This can and probably should be changed to a variant wich calculates the
startpoint for the FILL command directly.

To find such a point You could do an

XMIN=SIN(ANGLE)*(F-8) : XMINY=COS(ANGLE)*(F-8)
FILL XMIN,XMINY

and delete all the other lines wich include XMIN or XMINY.

But: This starts the filling everytime on another part of the screen.
Thats why the filling itself will then sometimes go from up to down and
sometimes down to up and in 50% it starts on the left side and in 50% on
the right side. I suppose its possible to see a difference between these
variations of the fill-start. On the other hand this is so in original
program too. I think the best way to do is to find the topmost pixel (or
line) and start the filling there. But this depends also on how the
filling routine works.

Since You are knowing about the fact that there are only squares involved
eventually the better (best?) solution is to write a little fill
procedure. This has to find the outmost points (leftmost,rightmost) for
every line of the screen where the square should be plotted. With these
coordinates one can draw a horizontal line. This should be done for every
line in the square. Since drawing of a horizontal line can be much faster
than a comlex FILL command wich needs to test every pixel this is
eventually faster ; even if the squares are plotted in full and from the
biggest to the smallest one.

The other thing one would include in such a demo is double-buffering.
This can be done in BBC BASIC with an SWI wich switches between two
alternating drawports. Its not a challenge but I can't remember the SWI
number at the moment. It won't change the rest of the code and can be
added afterwards with ease.


All the best,
Sebastian
Richard Ashbery
2019-11-14 16:24:43 UTC
Permalink
Post by Sebastian Barthel
Post by Sebastian Barthel
... but what I'm really after is a method to overlay the
existing square with other successively smaller squares in
alternating colours.
To find a point where the FILL can start in a defined way, I
sorted the X-values and used the one on the left side (XMIN). The
y-value wich belongs to this (XMINY) is corrected by a minimal
absolute amount, wich sets the start of the FILL in a region
inside the square.
This can and probably should be changed to a variant wich
calculates the startpoint for the FILL command directly.
To find such a point You could do an
XMIN=SIN(ANGLE)*(F-8) : XMINY=COS(ANGLE)*(F-8) FILL XMIN,XMINY
and delete all the other lines wich include XMIN or XMINY.
It gets better :-) Implemented above which saves 4 lines of code. Came
up with an error to start with but error routine gives no hint as to
what might be wrong. I've found the following more helpful...

ON ERROR REPORT:PRINT " at line ";ERL:END
Post by Sebastian Barthel
But: This starts the filling everytime on another part of the
screen. Thats why the filling itself will then sometimes go from
up to down and sometimes down to up and in 50% it starts on the
left side and in 50% on the right side. I suppose its possible to
see a difference between these variations of the fill-start. On
the other hand this is so in original program too. I think the
best way to do is to find the topmost pixel (or line) and start
the filling there. But this depends also on how the filling
routine works.
Since You are knowing about the fact that there are only squares
involved eventually the better (best?) solution is to write a
little fill procedure. This has to find the outmost points
(leftmost,rightmost) for every line of the screen where the square
should be plotted. With these coordinates one can draw a
horizontal line. This should be done for every line in the square.
Since drawing of a horizontal line can be much faster than a
comlex FILL command wich needs to test every pixel this is
eventually faster ; even if the squares are plotted in full and
from the biggest to the smallest one.
There's a lot of information here - I've got the basics but I'll need
some time to digest it all.
Post by Sebastian Barthel
The other thing one would include in such a demo is
double-buffering. This can be done in BBC BASIC with an SWI wich
switches between two alternating drawports. Its not a challenge
but I can't remember the SWI number at the moment. It won't change
the rest of the code and can be added afterwards with ease.
As it stands I'm not sure that double-buffering will be enough to
really improve its smoothness - I believe there's something called
triple buffering - would this work I wonder?

This is turning out to be a rather nice little animation. Keep up the
good work. I think it needs more squares (bearing in mind the overlap
issue blanking out the colour) and a larger colour range but is pretty
good as it is. An intesting effect is the rotation speed variation -
probably due to the # of sine/cosine calculations required. This is
obviously what you meant when you said routine needs speeding up with
an array function to work out all the values before doing the
rotation. Could this be a feature perhaps :-)

When "perfected" can I put it on my website?

Regards

Richard
Sebastian Barthel
2019-11-14 19:29:44 UTC
Permalink
Post by Richard Ashbery
Post by Sebastian Barthel
Post by Sebastian Barthel
... but what I'm really after is a method to overlay the existing
square with other successively smaller squares in alternating colours.
To find a point where the FILL can start in a defined way, I sorted
the X-values and used the one on the left side (XMIN). ...
This can and probably should be changed to a variant wich calculates
the startpoint for the FILL command directly.
To find such a point You could do an
XMIN=SIN(ANGLE)*(F-8) : XMINY=COS(ANGLE)*(F-8) FILL XMIN,XMINY
and delete all the other lines wich include XMIN or XMINY.
It gets better :-) Implemented above which saves 4 lines of code. Came
up with an error to start with but error routine gives no hint as to
what might be wrong. I've found the following more helpful...
ON ERROR REPORT : PRINT " at line ";ERL : END
Yes, that's the "more informative" way to produce an error message. But
it's only a miniroutine and then I couldn't remember how to print the
message (REPORT). But: Sometimes its better not to know the name of the
error - so one gets a chance to find it by himself ... (OK; that's
nonsense ;) ...)


The error is the missing ":" in front of the FILL command.
( That's a "special feature" of the Newsreader wich likes to concatenate
lines together in a single line - especially if they are exported from
RISC OS to Unix textformats. )
Post by Richard Ashbery
There's a lot of information here - I've got the basics but I'll need
some time to digest it all.
OK, think about it.
Has to do much with the way in wich the fill routine works. So it depends.
Post by Richard Ashbery
As it stands I'm not sure that double-buffering will be enough to really
improve its smoothness - I believe there's something called triple
buffering - would this work I wonder?
Double Buffering will produce an un-flickery picture. That's all.
To increase the "smoothness" I would change the STEP parameter S - for
instance to 3 degrees; S=RAD(3)
Post by Richard Ashbery
This is turning out to be a rather nice little animation. Keep up the
good work. I think it needs more squares (bearing in mind the overlap
issue blanking out the colour) and a larger colour range but is pretty
good as it is. An intesting effect is the rotation speed variation -
probably due to the # of sine/cosine calculations required.
Yes, looks fine as an effect.

The speed variation isn't there, not really ... it's not an intended or
programmed one. It's only an optical effect wich is partly reasoned by
the changes in the direction of the rotation (clockwise,
counterclockwise) between the different layers of squares.

This gets more interesting with more layers and/or higher values for the
"rotation variance" ( the factor "*7" in the line where ANGLE is
recalculated).
Post by Richard Ashbery
This is
obviously what you meant when you said routine needs speeding up with an
array function to work out all the values before doing the rotation.
Could this be a feature perhaps :-)
This could be a feature.
We'll see if it finds its way into reality.
Post by Richard Ashbery
When "perfected" can I put it on my website?
Yes, you can. It's not that exclusive and there are many 80's Demos wich
demonstrated it long before 2019.

Eventually anybody else can find an interesting way to choose the
colours. Rainbow colors or something TIME variable based.


All the best,
SBn
Sebastian Barthel
2019-11-15 21:26:31 UTC
Permalink
Post by Sebastian Barthel
... but what I'm really after is a method to overlay the existing
square with other successively smaller squares in alternating colours.
This is turning out to be a rather nice little animation. ...
This could be a feature.
We'll see if it finds its way into reality.
So, today it happened ... its there
in its full glory with a sinustable and the double buffering included.

Other interesting colour combinations can be found by modifying the number
in the GCOL statement. In exchange of the 32 the numbers 23, 45 and e.g.
68 gave interesting results.

I wonder if there is an official way to claim the needed memory for the
double buffering. All the things I tested didn't work.
(OS_ClaimScreenMemory, OS_Byte 114 ...) Thats why there is a doubled MODE
line. The first reserves the Memory, the second is the real thing.


Have a look and hopefully it gives some funny minutes to whom whoever
runs it.




REM BBC BASIC Code , rotating squares - filled with fancy colours
REM uses FILL command, layers of squares shouldn't "touch"

ON ERROR REPORT : PRINT " ERROR IN ";ERL : END

DIM STB(720) : REM STB sinustable

R=0

FOR I%=0 TO 719 : STB(I%)=SIN(R) : R=R+(4*PI /720) : NEXT I%

MODE 1280,1024,16

MODE 1280,1024,8

SCREENBANK%=2

ORIGIN 1024,1024


WHILE R<>-1

FOR R=0 TO 360 STEP 3


WAIT

SYS "OS_Byte",113,SCREENBANK%

SCREENBANK% = SCREENBANK% MOD 2 +1

SYS "OS_Byte",112,SCREENBANK%

CLG


ANGLESIN=R

ANGLECOS=R+90

FOR F=50 TO 900 STEP 105


GCOL ( F MOD 32 )

X0=STB(ANGLESIN)*F : Y0=STB(ANGLECOS)*F

X1=STB(ANGLESIN+90)*F : Y1=STB(ANGLECOS+90)*F

X2=STB(ANGLESIN+180)*F : Y2=STB(ANGLECOS+180)*F

X3=STB(ANGLESIN+270)*F : Y3=STB(ANGLECOS+270)*F

POINT X0,Y0

DRAW X1,Y1 : DRAW X2,Y2 : DRAW X3,Y3 : DRAW X0,Y0


XMIN=STB(ANGLESIN)*(F-8) : XMINY=STB(ANGLECOS)*(F-8)

FILL XMIN,XMINY


ANGLESIN=ANGLESIN+( STB(ANGLESIN)*7 )

ANGLECOS=ANGLESIN+90


NEXT F

NEXT R

ENDWHILE
Sebastian Barthel
2019-11-15 22:23:14 UTC
Permalink
Post by Richard Ashbery
... but what I'm really after is a method to overlay the existing
square with other successively smaller squares in alternating colours.
This is turning out to be a rather nice little animation. Keep up the
good work. I think it needs more squares (bearing in mind the overlap
issue blanking out the colour) and a larger colour range but is pretty
good as it is. An intesting effect is the rotation speed variation -
probably due to the # of sine/cosine calculations required.
And - to complete it a little bit more - here is the variant with
TRIANGLEs as proposed by druck.

This allows to overlap the layers, wich means: more layers and/or greater
values for the rotation difference between them.

Works fine, and - I didn't measure it, but - feels a bit faster than the
normal FILLs.

Mark: this time the squares are filled in their full area and they are
plotted from the bottom to the top of the square stack.


One can ask: Why isn't there a TRIANGLE command or TRIANGLE FILL in the
BASIC ? The functions exists. With this a RECTANGLE FILL ROTATE command is
also a possibility.

OK, questions, questions, now for the program ...




REM BBC BASIC Code , rotating squares - filled with fancy colours

REM uses triangles to fill the squares, allows overlapping

ON ERROR REPORT : PRINT " ERROR IN ";ERL : END

DIM STB(720) : REM STB sinustable

R=0

FOR I%=0 TO 719 : STB(I%)=SIN(R) : R=R+(4*PI /720) : NEXT I%

MODE 1280,1024,16

MODE 1280,1024,8

SCREENBANK%=2

ORIGIN 1024,1024


WHILE R<>-1


FOR R=0 TO 360 STEP 3


WAIT

SYS "OS_Byte",113,SCREENBANK%

SCREENBANK% = SCREENBANK% MOD 2 +1

SYS "OS_Byte",112,SCREENBANK%

CLG


ANGLESIN=R

ANGLECOS=R+90


FOR F=900 TO 50 STEP -85


GCOL ( F MOD 32 )

X0=STB(ANGLESIN)*F : Y0=STB(ANGLECOS)*F

X1=STB(ANGLESIN+90)*F : Y1=STB(ANGLECOS+90)*F

X2=STB(ANGLESIN+180)*F : Y2=STB(ANGLECOS+180)*F

X3=STB(ANGLESIN+270)*F : Y3=STB(ANGLECOS+270)*F

MOVE X0,Y0
MOVE X2,Y2
SYS "OS_Plot",85,X1,Y1

MOVE X0,Y0
MOVE X2,Y2
SYS "OS_Plot",85,X3,Y3

ANGLESIN=ANGLESIN+( STB(ANGLESIN)*14 )

ANGLECOS=ANGLESIN+90


NEXT F

NEXT R

ENDWHILE

END
Sebastian Barthel
2019-11-15 22:31:46 UTC
Permalink
Post by Sebastian Barthel
Post by Richard Ashbery
... but what I'm really after is a method to overlay the existing
square with other successively smaller squares in alternating colours.
This is turning out to be a rather nice little animation. Keep up the
good work. I think it needs more squares (bearing in mind the overlap
issue blanking out the colour) and a larger colour range but is pretty
good as it is. An intesting effect is the rotation speed variation -
probably due to the # of sine/cosine calculations required.
And - to complete it a little bit more - here is the variant with
TRIANGLEs as proposed by druck.
... need to enhance my usenet-posting skills ; errors by "line-
concatenation" removed ( ":" in the MOVE lines added )





REM BBC BASIC Code , rotating squares - filled with fancy colours

REM uses triangles to fill the squares, allows overlapping

ON ERROR REPORT : PRINT " ERROR IN ";ERL : END

DIM STB(720) : REM STB sinustable

R=0

FOR I%=0 TO 719 : STB(I%)=SIN(R) : R=R+(4*PI /720) : NEXT I%

MODE 1280,1024,16

MODE 1280,1024,8

SCREENBANK%=2

ORIGIN 1024,1024


WHILE R<>-1


FOR R=0 TO 360 STEP 3


WAIT

SYS "OS_Byte",113,SCREENBANK%

SCREENBANK% = SCREENBANK% MOD 2 +1

SYS "OS_Byte",112,SCREENBANK%

CLG


ANGLESIN=R

ANGLECOS=R+90


FOR F=900 TO 50 STEP -85


GCOL ( F MOD 32 )

X0=STB(ANGLESIN)*F : Y0=STB(ANGLECOS)*F

X1=STB(ANGLESIN+90)*F : Y1=STB(ANGLECOS+90)*F

X2=STB(ANGLESIN+180)*F : Y2=STB(ANGLECOS+180)*F

X3=STB(ANGLESIN+270)*F : Y3=STB(ANGLECOS+270)*F

MOVE X0,Y0 : MOVE X2,Y2 : SYS "OS_Plot",85,X1,Y1

MOVE X0,Y0 : MOVE X2,Y2 : SYS "OS_Plot",85,X3,Y3


ANGLESIN=ANGLESIN+( STB(ANGLESIN)*14 )

ANGLECOS=ANGLESIN+90


NEXT F

NEXT R

ENDWHILE

END
Richard Ashbery
2019-11-16 14:05:10 UTC
Permalink
Post by Sebastian Barthel
And - to complete it a little bit more - here is the variant with
TRIANGLEs as proposed by druck.
I seems Druck was right in that PLOTting with triangles is a much
better solution and avoids the dreaded FILL command.

Just a few other points:

I only use my Raspberry Pi with res of 1920 x 1080. If I use your MODE
(1280,1024,8) sure enough it works but I get severe breakup of the
pattern. I've had to slow the shadow memory down somewhat by placing a
a large (2cS) delay for MODE 1280,1024,8 and a much shorter delay for
MODE 1920,1080,8 between SYS "OS_Byte",112,SCREENBANK% and
CLG.

Curious - what advantage is there in using SYS "OS_Plot" over plain
old PLOT 85?

All we need now is some music - what about "The Blue Danube" by Strauss
or something from Holst, "The Planets" ;-)

Overall an extemely effective but simple pattern :-) Well done
Sebastian.

Best regards

Richard
Sebastian Barthel
2019-11-16 19:47:08 UTC
Permalink
Post by Sebastian Barthel
And - to complete it a little bit more - here is the variant with
TRIANGLEs as proposed by druck.
I seems Druck was right in that PLOTting with triangles is a much better
solution and avoids the dreaded FILL command.
Yes, I agree.


In a time I had read about an HLine command or a PolyHLine command wich
existed in RISC OS 6 and eventually others too. This could perform a
little bit better, but in terms of simplicity combined with speed and
"easiness" the TRINAGLE solution is probably the best.
I only use my Raspberry Pi with res of 1920 x 1080. If I use your MODE
(1280,1024,8) sure enough it works but I get severe breakup of the
pattern. I've had to slow the shadow memory down somewhat by placing a a
large (2cS) delay for MODE 1280,1024,8 and a much shorter delay for MODE
1920,1080,8 between SYS "OS_Byte",112,SCREENBANK% and CLG.
Strange. Has eventually something to do with a non-hardware SCREENBANK%
switch. Old VIDC would be faster than this.
Curious - what advantage is there in using SYS "OS_Plot" over plain old
PLOT 85?
As I wrote for druck, its not a "real" reason. Its more because PLOT
itself is unreadable for the "uninitiated" programmer - an that is
clearer stated if "SYS OS_Plot" is used. So if You feel that PLOT looks
better - use this.
All we need now is some music - what about "The Blue Danube" by Strauss
or something from Holst, "The Planets" ;-)
Strauss is already assigned with Elite and Odyssee 2001 ...
a little bit too big in comparison
Overall an extemely effective but simple pattern :-) Well done
Sebastian.
Thanks.


All the best,
SBn
druck
2019-11-18 20:02:47 UTC
Permalink
Post by Sebastian Barthel
Curious - what advantage is there in using SYS "OS_Plot" over plain old
PLOT 85?
As I wrote for druck, its not a "real" reason. Its more because PLOT
itself is unreadable for the "uninitiated" programmer - an that is
clearer stated if "SYS OS_Plot" is used. So if You feel that PLOT looks
better - use this.
I don't see OS_Plot being any clearer than the BASIC PLOT keyword, both
are documented in the appropriate places.

The main point is for SYS "OS_Plot" BASIC has to do a lot of work to
make a generic system call, but the PLOT keyword is handled directly by
BASIC.

Mixing a SYS call with other build in keywords such as MOVE is just meh!

---druck
Steve Fryatt
2019-11-16 00:39:15 UTC
Permalink
On 15 Nov, Sebastian Barthel wrote in message
Post by Sebastian Barthel
One can ask: Why isn't there a TRIANGLE command or TRIANGLE FILL in the
BASIC ? The functions exists. With this a RECTANGLE FILL ROTATE command is
also a possibility.
The fact that PLOT exists, probably. You would also need PARALLELOGRAM, ARC,
SEGMENT and SECTOR, as well as DRAW variants for "dotted", "no first" and
"no last". The "background" and "inverse" plot modes aren't supported by
dedicated keywords, either.

In the end, there was presumably a tradeoff between making things easy to
remember and 'wasting' keyword tokens on the task -- there are only a finite
number of these available, after all.
--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/
Richard Ashbery
2019-11-16 12:21:49 UTC
Permalink
Post by Steve Fryatt
On 15 Nov, Sebastian Barthel wrote in message
Post by Sebastian Barthel
One can ask: Why isn't there a TRIANGLE command or TRIANGLE FILL
in the BASIC ? The functions exists. With this a RECTANGLE FILL
ROTATE command is also a possibility.
The fact that PLOT exists, probably. You would also need
PARALLELOGRAM, ARC, SEGMENT and SECTOR, as well as DRAW variants
for "dotted", "no first" and "no last". The "background" and
"inverse" plot modes aren't supported by dedicated keywords, either.
In the end, there was presumably a tradeoff between making things
easy to remember and 'wasting' keyword tokens on the task -- there
are only a finite number of these available, after all.
I would value a RECTANGLE FILL ROTATE command. Not too
bothered about the other shapes. The rectangle/square is extremely
versatile - a single line command to do this could save a lot of time.
I take your point though Steve with the tradeoff - something I'm not
knowledeable to argue with.

Is it worth mentioning in the ROOL forum?

Richard
Steve Fryatt
2019-11-17 10:04:52 UTC
Permalink
On 16 Nov, Richard Ashbery wrote in message
Post by Richard Ashbery
Post by Steve Fryatt
The fact that PLOT exists, probably. You would also need PARALLELOGRAM,
ARC, SEGMENT and SECTOR, as well as DRAW variants for "dotted", "no
first" and "no last". The "background" and "inverse" plot modes aren't
supported by dedicated keywords, either.
In the end, there was presumably a tradeoff between making things easy
to remember and 'wasting' keyword tokens on the task -- there are only a
finite number of these available, after all.
I would value a RECTANGLE FILL ROTATE command.
The thing is, having thought about it, you wouldn't actually do it like
that.

The ELLIPSE command is ELLIPSE [FILL] x%, y%, m%, n%[, a], so you would
ideally be consistent and do RECTANGLE [FILL] x%, y%, w%, h%[, a]. Sadly
that's slightly problematic, since the h% is already optional on RECTANGLE.
You could always state that a isn't valid unless h% is present, though.
Post by Richard Ashbery
Not too bothered about the other shapes. The rectangle/square is extremely
versatile - a single line command to do this could save a lot of time.
What do you mean by "a lot of time"? Is that programmer time in working out
the calls to use, or actual program execution time? The latter possibly, but
if the former, then why not PROCrectange(x%, y%, w%, h%, a)?

ON ERROR PRINT REPORT$; " at line "; ERL : END
MODE MODE

FOR a = 0 TO 2 * PI STEP PI / 40
WAIT
CLS
PROCrectangle(300, 300, 600, 600, a)
NEXT a

END


DEF PROCrectangle(x%, y%, w%, h%, a)
LOCAL cx%, cy%, i%, px%(), py%()
DIM px%(3), py%(3)

cx% = x% + (w% / 2)
cy% = y% + (h% / 2)
r% = SQR(((w% / 2) ^ 2) + ((h% / 2) ^ 2))

a -= PI/4

FOR i% = 0 TO 3
px%(i%) = cx% + (r% * SIN(a))
py%(i%) = cy% + (r% * COS(a))
a += PI/2
NEXT i%

MOVE px%(0), py%(0)
MOVE px%(1), py%(1)
PLOT 85, px%(2), py%(2)
MOVE px%(3), py%(3)
PLOT 85, px%(0), py%(0)
ENDPROC
Post by Richard Ashbery
Is it worth mentioning in the ROOL forum?
It might be -- that's usually the place to suggest new features for the OS
these days.
--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/
Richard Ashbery
2019-11-17 13:50:14 UTC
Permalink
Post by Steve Fryatt
On 16 Nov, Richard Ashbery wrote in message
Post by Richard Ashbery
Post by Steve Fryatt
The fact that PLOT exists, probably. You would also need
PARALLELOGRAM, ARC, SEGMENT and SECTOR, as well as DRAW
variants for "dotted", "no first" and "no last". The
"background" and "inverse" plot modes aren't supported by
dedicated keywords, either.
In the end, there was presumably a tradeoff between making
things easy to remember and 'wasting' keyword tokens on the
task -- there are only a finite number of these available,
after all.
I would value a RECTANGLE FILL ROTATE command.
The thing is, having thought about it, you wouldn't actually do it
like that.
The ELLIPSE command is ELLIPSE [FILL] x%, y%, m%, n%[, a], so you
would ideally be consistent and do RECTANGLE [FILL] x%, y%, w%,
h%[, a]. Sadly that's slightly problematic, since the h% is already
optional on RECTANGLE. You could always state that a isn't valid
unless h% is present, though.
Post by Richard Ashbery
Not too bothered about the other shapes. The rectangle/square is
extremely versatile - a single line command to do this could save
a lot of time.
What do you mean by "a lot of time"? Is that programmer time in
working out the calls to use, or actual program execution time? The
latter possibly, but if the former, then why not PROCrectange(x%,
y%, w%, h%, a)?
The former - for simple soles like me ;-)

4 lines of code should do it...

FOR rotate = 0 TO PI STEP PI/4
GCOL RND(10)
RECTANGLE FILL 0,0,600,400,rotate
NEXT rotate

OK it can't be done but could it be implemented in some form? Only by
substituting ELLIPSE for RECTANGLE will it work.

[SNIP : Another excellent rotating rectangle example]

Richard
Richard Ashbery
2019-11-17 14:19:26 UTC
Permalink
Post by Richard Ashbery
Post by Steve Fryatt
What do you mean by "a lot of time"? Is that programmer time in
working out the calls to use, or actual program execution time?
The latter possibly, but if the former, then why not
PROCrectange(x%, y%, w%, h%, a)?
The former - for simple soles like me ;-)
Or did I mean souls - It'll give you a laugh!!!
Post by Richard Ashbery
4 lines of code should do it...
FOR rotate = 0 TO PI STEP PI/4 GCOL RND(10) RECTANGLE FILL
0,0,600,400,rotate NEXT rotate
OK it can't be done but could it be implemented in some form? Only
by substituting ELLIPSE for RECTANGLE will it work.
Steve Fryatt
2019-11-17 14:21:42 UTC
Permalink
On 17 Nov, Richard Ashbery wrote in message
Post by Richard Ashbery
4 lines of code should do it...
FOR rotate = 0 TO PI STEP PI/4
GCOL RND(10)
RECTANGLE FILL 0,0,600,400,rotate
NEXT rotate
OK it can't be done but could it be implemented in some form?
Um, why not

FOR rotate = 0 TO PI STEP PI/4
GCOL RND(10)
PROCrectangle(0,0,600,400,rotate)
NEXT rotate

from my previous post?
Post by Richard Ashbery
Only by substituting ELLIPSE for RECTANGLE will it work.
Or by writing a procedure to do it quickly whenever you need it.

That's the fundamental point of programming: break down what you need to do
into chunks, and write re-usable code to do those things. Spend half an hour
perfecting PROCrectangle() once, and you never need to do it again.

:-)
--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/
Richard Ashbery
2019-11-17 15:34:33 UTC
Permalink
Post by Steve Fryatt
On 17 Nov, Richard Ashbery wrote in message
Post by Richard Ashbery
4 lines of code should do it...
FOR rotate = 0 TO PI STEP PI/4 GCOL RND(10) RECTANGLE FILL
0,0,600,400,rotate NEXT rotate
OK it can't be done but could it be implemented in some form?
Um, why not
FOR rotate = 0 TO PI STEP PI/4 GCOL RND(10)
PROCrectangle(0,0,600,400,rotate) NEXT rotate
from my previous post?
Post by Richard Ashbery
Only by substituting ELLIPSE for RECTANGLE will it work.
Or by writing a procedure to do it quickly whenever you need it.
That's the fundamental point of programming: break down what you
need to do into chunks, and write re-usable code to do those
things. Spend half an hour perfecting PROCrectangle() once, and you
never need to do it again.
Hard to argue with you on this Steve but these days my memory lets me
down. My way: I don't have to remember where I've stashed 6 months
down the line. All right I do have to remember the very simple ELLIPSE
FILL construct and then substitute RECTANGLE but then I'm away.

Richard
Steve Fryatt
2019-11-17 16:25:27 UTC
Permalink
On 17 Nov, Richard Ashbery wrote in message
Post by Richard Ashbery
Hard to argue with you on this Steve but these days my memory lets me
down. My way: I don't have to remember where I've stashed 6 months down
the line. All right I do have to remember the very simple ELLIPSE FILL
construct and then substitute RECTANGLE but then I'm away.
Create a library file (or files) containing your graphics routines, and
include it (them) into every program using

LIBRARY "<BasicLibrary$Dir>.GraphicsLib"

or similar.

To put the libraries somewhere easy to find, create a folder !BasLibs or
similar, containing a Libs folder and !Boot of

Set BasicLibrary$Dir <Obey$Dir>.Libs

and !Run of

Set BasicLibrary$Dir <Obey$Dir>.Libs
Filer_OpenDir <BasicLibrary$Dir>

Stick your GraphicsLib into the Libs folder, and make sure that !BasLibs is
seen by the Filer before running your programs.
--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/
Richard Ashbery
2019-11-18 16:17:44 UTC
Permalink
Post by Steve Fryatt
On 17 Nov, Richard Ashbery wrote in message
Post by Richard Ashbery
Hard to argue with you on this Steve but these days my memory
lets me down. My way: I don't have to remember where I've stashed
6 months down the line. All right I do have to remember the very
simple ELLIPSE FILL construct and then substitute RECTANGLE but
then I'm away.
Create a library file (or files) containing your graphics routines,
and include it (them) into every program using
LIBRARY "<BasicLibrary$Dir>.GraphicsLib"
or similar.
To put the libraries somewhere easy to find, create a folder
!BasLibs or similar, containing a Libs folder and !Boot of
Set BasicLibrary$Dir <Obey$Dir>.Libs
and !Run of
Set BasicLibrary$Dir <Obey$Dir>.Libs Filer_OpenDir
<BasicLibrary$Dir>
Stick your GraphicsLib into the Libs folder, and make sure that
!BasLibs is seen by the Filer before running your programs.
Excellent Steve :-)

Many thanks

Richard
Richard Ashbery
2019-11-18 16:55:09 UTC
Permalink
Post by Steve Fryatt
On 17 Nov, Richard Ashbery wrote in message
Post by Richard Ashbery
Hard to argue with you on this Steve but these days my memory
lets me down. My way: I don't have to remember where I've
stashed 6 months down the line. All right I do have to remember
the very simple ELLIPSE FILL construct and then substitute
RECTANGLE but then I'm away.
Create a library file (or files) containing your graphics
routines, and include it (them) into every program using
LIBRARY "<BasicLibrary$Dir>.GraphicsLib"
or similar.
To put the libraries somewhere easy to find, create a folder
!BasLibs or similar, containing a Libs folder and !Boot of
Set BasicLibrary$Dir <Obey$Dir>.Libs
and !Run of
Set BasicLibrary$Dir <Obey$Dir>.Libs Filer_OpenDir
<BasicLibrary$Dir>
Stick your GraphicsLib into the Libs folder, and make sure that
!BasLibs is seen by the Filer before running your programs.
Just gone through your well explained example as is and it works. I
wish I'd asked the question before - this is exactly what I need.

Many thanks again.

Richard
druck
2019-11-16 11:48:48 UTC
Permalink
Post by Sebastian Barthel
And - to complete it a little bit more - here is the variant with
TRIANGLEs as proposed by druck.
SYS "OS_Plot",85,X1,Y1
You do know BASIC has a PLOT keyword? So you can just do PLOT 85,X1,Y1
That will make it a bit quicker. You might also want to use integers for
your coordinates, that will have better performance too.

---druck
Richard Ashbery
2019-11-16 14:21:03 UTC
Permalink
Post by druck
Post by Sebastian Barthel
And - to complete it a little bit more - here is the variant with
TRIANGLEs as proposed by druck.
SYS "OS_Plot",85,X1,Y1
You do know BASIC has a PLOT keyword? So you can just do PLOT
85,X1,Y1 That will make it a bit quicker.
Not scientific but in practice no obvious discernible difference.

Richard
druck
2019-11-18 20:04:46 UTC
Permalink
Post by Richard Ashbery
Post by druck
Post by Sebastian Barthel
And - to complete it a little bit more - here is the variant with
TRIANGLEs as proposed by druck.
SYS "OS_Plot",85,X1,Y1
You do know BASIC has a PLOT keyword? So you can just do PLOT
85,X1,Y1 That will make it a bit quicker.
Not scientific but in practice no obvious discernible difference.
PERFORMANCE!

---druck
Richard Ashbery
2019-11-19 14:48:05 UTC
Permalink
Post by druck
Post by Richard Ashbery
Post by druck
Post by Sebastian Barthel
And - to complete it a little bit more - here is the variant
with TRIANGLEs as proposed by druck.
SYS "OS_Plot",85,X1,Y1
You do know BASIC has a PLOT keyword? So you can just do PLOT
85,X1,Y1 That will make it a bit quicker.
Not scientific but in practice no obvious discernible difference.
PERFORMANCE!
Ferrari ;-)

Richard
druck
2019-11-19 20:26:21 UTC
Permalink
Post by Richard Ashbery
Post by druck
Post by Richard Ashbery
Post by druck
Post by Sebastian Barthel
And - to complete it a little bit more - here is the variant
with TRIANGLEs as proposed by druck.
SYS "OS_Plot",85,X1,Y1
You do know BASIC has a PLOT keyword? So you can just do PLOT
85,X1,Y1 That will make it a bit quicker.
Not scientific but in practice no obvious discernible difference.
PERFORMANCE!
Ferrari ;-)
Bah, souped up Fiats, get a proper British supercar from McLaren!

---druck
Brian Jordan
2019-11-19 20:39:11 UTC
Permalink
In article <qr1j5f$f8f$***@dont-email.me>,
druck <***@druck.org.uk> wrote:

[Snip]
Post by druck
Bah, souped up Fiats, get a proper British supercar from McLaren!
---druck
What you really need is a rotary Mazda.
--
_____________________________________________________________________

Brian Jordan
RISC OS 5.23 on Raspberry Pi
_____________________________________________________________________
Dave
2019-11-20 07:50:11 UTC
Permalink
Post by Brian Jordan
[Snip]
Post by druck
Bah, souped up Fiats, get a proper British supercar from McLaren!
---druck
What you really need is a rotary Mazda.
Mazda lamps stay brighter longer, always ask for Mazda... ;-)

Dave

Back in the days,when I was in my teens, a mate, a motor mechanic had a
Ford Capri with a Cosworth engine in it... Memories of that as quite a
muscle beast.

D.
--
Dave Triffid
Alan Adams
2019-11-20 11:26:28 UTC
Permalink
Post by Dave
Post by Brian Jordan
[Snip]
Post by druck
Bah, souped up Fiats, get a proper British supercar from McLaren!
---druck
What you really need is a rotary Mazda.
Mazda lamps stay brighter longer, always ask for Mazda... ;-)
Dave
Back in the days,when I was in my teens, a mate, a motor mechanic had a
Ford Capri with a Cosworth engine in it... Memories of that as quite a
muscle beast.
D.
Our local firm, Cosworth, once installed a DFV (3-litre F1) engine in a
Transit. After three of their staff loast their licenses, it was removed.
--
Alan Adams, from Northamptonshire
***@adamshome.org.uk
http://www.nckc.org.uk/
Sebastian Barthel
2019-11-16 19:27:32 UTC
Permalink
Post by druck
Post by Sebastian Barthel
And - to complete it a little bit more - here is the variant with
TRIANGLEs as proposed by druck.
SYS "OS_Plot",85,X1,Y1
You do know BASIC has a PLOT keyword? So you can just do PLOT 85,X1,Y1
That will make it a bit quicker.
Yes. I know this. But its not an command wich describes its function by
its name, and so I think its easier to read if its written as a SYS
command.

Its an very old-style BBC form of saying what You want to plot - its
necessary to know or learn the "codes" to interpret it. Thats really
perfect for an 1984 BBC Computer but absolutely not a good idea for a
32Bit System and above. On such a machine I want to have commands like
TRIANGLE or SECTOR and ARC wich tells me what they are doing.

And for the Speed ... I would guess, that the SYS is a bit faster,
because it can call the OS directly whereas the PLOT has to be
interpreted by the BASIC first and is then mapped to OS_Plot. But this is
only an idea and eventually the truth is the exact opposite.
Post by druck
You might also want to use integers for
your coordinates, that will have better performance too.
Started this with the I% - but then it worked fine and so there was no
need to change the other variables.

At least its a good suggestion.


All the best,
SBn
Steve Fryatt
2019-11-16 23:37:55 UTC
Permalink
On 16 Nov, Sebastian Barthel wrote in message
Post by Sebastian Barthel
Yes. I know this. But its not an command wich describes its function by
its name, and so I think its easier to read if its written as a SYS
command.
PLOT 85, X%, Y% vs SYS "OS_Plot", 85, X%, Y%.
Post by Sebastian Barthel
And for the Speed ... I would guess, that the SYS is a bit faster, because
it can call the OS directly whereas the PLOT has to be interpreted by the
BASIC first and is then mapped to OS_Plot. But this is only an idea and
eventually the truth is the exact opposite.
That's sort-of true, but...

PLOT (and the various named statements) simply call OS_Plot, but they call
the SWI by number. Unless you write

SYS &45, code%, X%, Y%

then you have the SWI name lookup overhead on each call, which will be
significant. At which point

PLOT code%, X%, Y%

looks preferable.

Oh, and in terms of interpreting by BASIC,

PLOT 85, X%, Y%

has to interpret a single byte token for PLOT, then the number 85, then two
variables. On the other hand

SYS "OS_Plot", 85, X%, Y%

has to interpret a single byte token for SYS, followed by reading the string
for the SWI name, then looking that up, then interpreting the number 85,
then the two variables. Even if you do SYS &45, 85, X%, Y% it still has to
interpret an extra numeric value.

After that, PLOT is looking better.
--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/
druck
2019-11-14 20:47:53 UTC
Permalink
Post by Richard Ashbery
As it stands I'm not sure that double-buffering will be enough to
really improve its smoothness - I believe there's something called
triple buffering - would this work I wonder?
Tripple buffering wont help. In double buffering you are looking at the
last while drawing the next. If it is still not smooth, you need to draw
it faster - see my post about using triangles.

---druck
Richard Ashbery
2019-11-14 14:09:28 UTC
Permalink
Post by Richard Ashbery
I forgot about the FILL statement which I can also use in my
original code but what I'm really after is a method to overlay
the existing square with other successively smaller squares in
alternating colours. Its easier to see it illustrated...
http://www.riscosbasic.uk/problems/square.zip
This doesn't seems as easy as it should be ... I tried it with the
biggest square plotted first. Then the second on top of it. But,
from this second square on to the last and most little square the
FILL command didn't work anymore in the expected way. I think, the
FILL will only fill if there is an unpainted background colour. It
doesn't work on top of an already painted structure.
That's what I've discovered - the FILL command is quite limited. What
a pity we haven't got a RECTANGLE command rather like ELLIPSE FILL
with an angle parameter. Perhaps I should take it to the ROOL forum.
So - if one wants to use the FILL - the sqares have to be painted
the other way round; from the little one in the centre to the
outmost an biggest one.
I agree.
If there is a space filled with background colour between the line
of the new-drawn outermost square an the already painted an filled
inner square the FILL command works in the expected way.
To find a point where the FILL can start in a defined way, I sorted
the X- values and used the one on the left side (XMIN). The y-value
wich belongs to this (XMINY) is corrected by a minimal absolute
amount, wich sets the start of the FILL in a region inside the
square.
All this doesn't work if this starting point is located outside of
the square or if the inner square overlaps with the bigger one.
Yes I've also discovered that issue :-(
You can try this by setting the maximum square length (F) (F as in
"factor", because it's the zooming factor for the calculated
length) from 500 to e.g. 800. Or You can change the STEP to a
lesser value (30).
The problem here is the lower your STEP size the greater the chance of
the second and subsequent squares loosing their colour through
overlap. My compromise is FOR F=50 TO 800 STEP 100 making the
graphic quite large on the screen.
To ease the finding of a good combination of all the factors
involved there is a little CIRCLE drawn at (XMIN,XMINY) wich should
be removed, with a REM command, once a good combination has been
found.
I've used that exact same method in another graphic (easier because it
had no animation) to locate the precise co-ordinates for the FILL
command.
The ANGLE is (re)calcuated in a "fancy" form with a SIN to give a
fine rotating effect. This could be exchanged by an addition of a
fix value to increase the ANGLE for every square - ANGLE=ANGLE+25 ;
this should give the effect You initially wanted to plot (without
additional animations).
To rotate each square independently is really effective. Fixed is not
as good.
It's a little bit "flickery", but gives a fine little demo ... :)
Replacing last line but one with a shadow memory routine...

OSCLI"FX112,"+S1$:OSCLI"FX113,"+S2$:SWAP S1$,S2$:WAIT:FOR
I=0 TO 20000 : NEXT I: CLS

(S1$="1":S2$="2" can be assigned near the top of the program)

seems to improve the flicker.

Many thanks again - you've obviously spent quite a bit of time coming
up with a solution :-))

You may have guessed that what I'm after is to draw a persuit curve
with its elegant spiral arms - originally non-animated but animation
certainly improves things.

All the best

Richard
druck
2019-11-14 20:44:48 UTC
Permalink
Post by Sebastian Barthel
This doesn't seems as easy as it should be ...
I tried it with the biggest square plotted first. Then the second on top
of it. But, from this second square on to the last and most little square
the FILL command didn't work anymore in the expected way. I think, the
FILL will only fill if there is an unpainted background colour. It
doesn't work on top of an already painted structure.
Don't use Fill, even when it works its very slow. You are after rotated
squares, so just draw them as two triangles with PLOT 85 - vastly
faster, and no worries about what is underneath.

---druck
Richard Ashbery
2019-11-15 13:35:37 UTC
Permalink
Post by druck
This doesn't seems as easy as it should be ... I tried it with
the biggest square plotted first. Then the second on top of it.
But, from this second square on to the last and most little
square the FILL command didn't work anymore in the expected way.
I think, the FILL will only fill if there is an unpainted
background colour. It doesn't work on top of an already painted
structure.
Don't use Fill, even when it works its very slow. You are after
rotated squares, so just draw them as two triangles with PLOT 85 -
vastly faster, and no worries about what is underneath.
As Sebastian pointed out the FILL command appears to do odd things. I
hadn't realised that it also throttles speed. I'll look at the
triangle fill command as you suggest. There is a huge list of PLOT
commands - it seems only a few are really useful.

Richard
Steve Fryatt
2019-11-16 00:32:19 UTC
Permalink
On 15 Nov, Richard Ashbery wrote in message
Post by Richard Ashbery
As Sebastian pointed out the FILL command appears to do odd things.
There are a range of different fill codes, if you look at the list of
available PLOT commands.
Post by Richard Ashbery
I hadn't realised that it also throttles speed.
Filling isn't a simple process, as the code has to check every single pixel
before plotting. If you already know the shape and it's regular (which you
do and it is), then just plotting the filled shape will always be quicker.
Post by Richard Ashbery
I'll look at the triangle fill command as you suggest. There is a huge
list of PLOT commands - it seems only a few are really useful.
On the contrary, many are used a lot. Remember that PLOT is just a thin
BASIC veneer over OS_Plot, which forms the basis of all of the core OS
graphics. Commands such as MOVE, DRAW, CIRCLE, ELLIPSE, RECTANGLE, plus all
of the BY and FILL variants, just map to OS_Plot calls -- and so have
equivalent PLOT commands as well.

So DRAW x%, y% is just PLOT 5, x%, y%, while DRAW BY x%, y% is
PLOT 1, x%, y%. And, of course, PLOT 2, 3, 6 and 7 are variations which save
you calls to GCOL in between.

Similarly, RECTANGLE FILL x%, y%, w%, h% is just a shorthand for writing
PLOT 4, x%, y% : PLOT 97, x% + w%, y% + h%.
--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/
n***@sprow.co.uk
2019-11-14 13:00:23 UTC
Permalink
Post by Richard Ashbery
Has anyone got a
simple routine that rotates a colour filled square about the screen
centre?
Another approach, since you only want a square, is to create a sprite of the required size (either programmatically, or with Paint).
Then to rotate use OS_SpriteOp 56 (plot sprite transformed) and provide a matrix which rotates as desired, or indeed any other transformation that can be described with a matrix,
Sprow.
Richard Ashbery
2019-11-14 15:21:54 UTC
Permalink
Post by n***@sprow.co.uk
Has anyone got a simple routine that rotates a colour filled
square about the screen centre?
Another approach, since you only want a square, is to create a
sprite of the required size (either programmatically, or with
Paint). Then to rotate use OS_SpriteOp 56 (plot sprite transformed)
and provide a matrix which rotates as desired, or indeed any other
transformation that can be described with a matrix, Sprow.
I don't suppose you have an example(s). I've never done much with
Sprites and I wouldn't call my self a proficient programmer. All the
stuff I've 'programmed' so far involves fairly simple BASIC graphics
based on what I've gleaned from the BBC BASIC Reference Manual.

How easy would it be to implement a rotation parameter to rotate a
filled rectangle in a similar way to ELLIPSE FILL?

Richard
Loading...