Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.acorn.programmer > #5865 > unrolled thread

Rotating a Colour-Filled Square

Back to article view | Back to comp.sys.acorn.programmer

Contents

  Rotating a Colour-Filled Square Richard Ashbery <basura@invalid.addr.uk> - 2019-11-12 14:05 +0000
    Re: Rotating a Colour-Filled Square Sebastian Barthel <naitsabes@freenet.de> - 2019-11-12 23:04 +0000
      Re: Rotating a Colour-Filled Square Richard Ashbery <basura@invalid.addr.uk> - 2019-11-14 16:24 +0000
        Re: Rotating a Colour-Filled Square Sebastian Barthel <naitsabes@freenet.de> - 2019-11-14 19:29 +0000
          Re: Rotating a Colour-Filled Square Sebastian Barthel <naitsabes@freenet.de> - 2019-11-15 21:26 +0000
          Re: Rotating a Colour-Filled Square Sebastian Barthel <naitsabes@freenet.de> - 2019-11-15 22:23 +0000
            Re: Rotating a Colour-Filled Square Sebastian Barthel <naitsabes@freenet.de> - 2019-11-15 22:31 +0000
              Re: Rotating a Colour-Filled Square Richard Ashbery <basura@invalid.addr.uk> - 2019-11-16 14:05 +0000
                Re: Rotating a Colour-Filled Square Sebastian Barthel <naitsabes@freenet.de> - 2019-11-16 19:47 +0000
                  Re: Rotating a Colour-Filled Square druck <news@druck.org.uk> - 2019-11-18 20:02 +0000
            Re: Rotating a Colour-Filled Square Steve Fryatt <news@stevefryatt.org.uk> - 2019-11-16 00:39 +0000
              Re: Rotating a Colour-Filled Square Richard Ashbery <basura@invalid.addr.uk> - 2019-11-16 12:21 +0000
                Re: Rotating a Colour-Filled Square Steve Fryatt <news@stevefryatt.org.uk> - 2019-11-17 10:04 +0000
                  Re: Rotating a Colour-Filled Square Richard Ashbery <basura@invalid.addr.uk> - 2019-11-17 13:50 +0000
                    Re: Rotating a Colour-Filled Square Richard Ashbery <basura@invalid.addr.uk> - 2019-11-17 14:19 +0000
                    Re: Rotating a Colour-Filled Square Steve Fryatt <news@stevefryatt.org.uk> - 2019-11-17 14:21 +0000
                      Re: Rotating a Colour-Filled Square Richard Ashbery <basura@invalid.addr.uk> - 2019-11-17 15:34 +0000
                        Re: Rotating a Colour-Filled Square Steve Fryatt <news@stevefryatt.org.uk> - 2019-11-17 16:25 +0000
                          Re: Rotating a Colour-Filled Square Richard Ashbery <basura@invalid.addr.uk> - 2019-11-18 16:17 +0000
                            Re: Rotating a Colour-Filled Square Richard Ashbery <basura@invalid.addr.uk> - 2019-11-18 16:55 +0000
            Re: Rotating a Colour-Filled Square druck <news@druck.org.uk> - 2019-11-16 11:48 +0000
              Re: Rotating a Colour-Filled Square Richard Ashbery <basura@invalid.addr.uk> - 2019-11-16 14:21 +0000
                Re: Rotating a Colour-Filled Square druck <news@druck.org.uk> - 2019-11-18 20:04 +0000
                  Re: Rotating a Colour-Filled Square Richard Ashbery <basura@invalid.addr.uk> - 2019-11-19 14:48 +0000
                    Re: Rotating a Colour-Filled Square druck <news@druck.org.uk> - 2019-11-19 20:26 +0000
                      Re: Rotating a Colour-Filled Square Brian Jordan <brian.jordan9@btinternet.com> - 2019-11-19 20:39 +0000
                        Re: Rotating a Colour-Filled Square Dave <dave@triffid.co.uk> - 2019-11-20 07:50 +0000
                          Re: Rotating a Colour-Filled Square Alan Adams <alan@adamshome.org.uk> - 2019-11-20 11:26 +0000
              Re: Rotating a Colour-Filled Square Sebastian Barthel <naitsabes@freenet.de> - 2019-11-16 19:27 +0000
                Re: Rotating a Colour-Filled Square Steve Fryatt <news@stevefryatt.org.uk> - 2019-11-16 23:37 +0000
        Re: Rotating a Colour-Filled Square druck <news@druck.org.uk> - 2019-11-14 20:47 +0000
      Re: Rotating a Colour-Filled Square druck <news@druck.org.uk> - 2019-11-14 20:44 +0000
        Re: Rotating a Colour-Filled Square Richard Ashbery <basura@invalid.addr.uk> - 2019-11-15 13:35 +0000
          Re: Rotating a Colour-Filled Square Steve Fryatt <news@stevefryatt.org.uk> - 2019-11-16 00:32 +0000
      Re: Rotating a Colour-Filled Square Richard Ashbery <basura@invalid.addr.uk> - 2019-11-13 12:54 +0000
        Re: Rotating a Colour-Filled Square Richard Ashbery <basura@invalid.addr.uk> - 2019-11-13 17:05 +0000
          Re: Rotating a Colour-Filled Square Sebastian Barthel <naitsabes@freenet.de> - 2019-11-13 23:35 +0000
            Re: Rotating a Colour-Filled Square Sebastian Barthel <naitsabes@freenet.de> - 2019-11-14 12:20 +0000
            Re: Rotating a Colour-Filled Square Richard Ashbery <basura@invalid.addr.uk> - 2019-11-14 14:09 +0000
    Re: Rotating a Colour-Filled Square Richard Ashbery <basura@invalid.addr.uk> - 2019-11-14 15:21 +0000
    Re: Rotating a Colour-Filled Square news@sprow.co.uk - 2019-11-14 05:00 -0800

Page 1 of 3  [1] 2 3  Next page →

#5865 — Rotating a Colour-Filled Square

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?

[toc] | [next] | [standalone]

#5866

Am Tue, 12 Nov 2019 14:05:03 +0000 schrieb 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

[toc] | [prev] | [next] | [standalone]

#5868

In article <qqjgq3$dkd$1@solani.org>, Sebastian Barthel
<naitsabes@freenet.de> wrote:
> Am Wed, 13 Nov 2019 23:35:41 +0000 schrieb Sebastian Barthel:

> > Am Wed, 13 Nov 2019 17:05:44 +0000 schrieb Richard Ashbery:
> > 
> >> ... 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

> 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.

> 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

[toc] | [prev] | [next] | [standalone]

#5869

Am Thu, 14 Nov 2019 16:24:43 +0000 schrieb Richard Ashbery:

> In article <qqjgq3$dkd$1@solani.org>, Sebastian Barthel
> <naitsabes@freenet.de> wrote:
>> Am Wed, 13 Nov 2019 23:35:41 +0000 schrieb Sebastian Barthel:
> 
>> > Am Wed, 13 Nov 2019 17:05:44 +0000 schrieb Richard Ashbery:
>> > 
>> >> ... 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. )


> 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.

 
> 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)

 
> 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).


> 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.

> 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

[toc] | [prev] | [next] | [standalone]

#5873

Am Thu, 14 Nov 2019 19:29:44 +0000 schrieb Sebastian Barthel:

> Am Thu, 14 Nov 2019 16:24:43 +0000 schrieb Richard Ashbery:
> 
>> In article <qqjgq3$dkd$1@solani.org>, Sebastian Barthel
>> <naitsabes@freenet.de> wrote:
>>> Am Wed, 13 Nov 2019 23:35:41 +0000 schrieb Sebastian Barthel:
>> 
>>> > Am Wed, 13 Nov 2019 17:05:44 +0000 schrieb 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. ...
> 

> 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

[toc] | [prev] | [next] | [standalone]

#5874

Am Thu, 14 Nov 2019 19:29:44 +0000 schrieb Sebastian Barthel:

> Am Thu, 14 Nov 2019 16:24:43 +0000 schrieb Richard Ashbery:
> 
>> In article <qqjgq3$dkd$1@solani.org>, Sebastian Barthel
>> <naitsabes@freenet.de> wrote:
>>> Am Wed, 13 Nov 2019 23:35:41 +0000 schrieb Sebastian Barthel:
>> 
>>> > Am Wed, 13 Nov 2019 17:05:44 +0000 schrieb 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

[toc] | [prev] | [next] | [standalone]

#5875

Am Fri, 15 Nov 2019 22:23:14 +0000 schrieb Sebastian Barthel:

> Am Thu, 14 Nov 2019 19:29:44 +0000 schrieb Sebastian Barthel:
> 
>> Am Thu, 14 Nov 2019 16:24:43 +0000 schrieb Richard Ashbery:
>> 
>>> In article <qqjgq3$dkd$1@solani.org>, Sebastian Barthel
>>> <naitsabes@freenet.de> wrote:
>>>> Am Wed, 13 Nov 2019 23:35:41 +0000 schrieb Sebastian Barthel:
>>> 
>>>> > Am Wed, 13 Nov 2019 17:05:44 +0000 schrieb 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

[toc] | [prev] | [next] | [standalone]

#5880

In article <qqn90i$q84$3@solani.org>, Sebastian Barthel
<naitsabes@freenet.de> wrote:
> Am Fri, 15 Nov 2019 22:23:14 +0000 schrieb Sebastian Barthel:

> > Am Thu, 14 Nov 2019 19:29:44 +0000 schrieb 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

[toc] | [prev] | [next] | [standalone]

#5883

Am Sat, 16 Nov 2019 14:05:10 +0000 schrieb Richard Ashbery:

> In article <qqn90i$q84$3@solani.org>, Sebastian Barthel
> <naitsabes@freenet.de> wrote:
>> Am Fri, 15 Nov 2019 22:23:14 +0000 schrieb Sebastian Barthel:
> 
>> > Am Thu, 14 Nov 2019 19:29:44 +0000 schrieb 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.

 
> 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.

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

[toc] | [prev] | [next] | [standalone]

#5894

On 16/11/2019 19:47, Sebastian Barthel wrote:
> Am Sat, 16 Nov 2019 14:05:10 +0000 schrieb Richard Ashbery:
>> 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

[toc] | [prev] | [next] | [standalone]

#5877

On 15 Nov, Sebastian Barthel wrote in message
    <qqn8gi$q84$2@solani.org>:

> 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/

[toc] | [prev] | [next] | [standalone]

#5879

In article <mpro.q11dta047jn0401u8.news@stevefryatt.org.uk>, Steve
Fryatt <news@stevefryatt.org.uk> wrote:
> On 15 Nov, Sebastian Barthel wrote in message
>     <qqn8gi$q84$2@solani.org>:

> > 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

[toc] | [prev] | [next] | [standalone]

#5886

On 16 Nov, Richard Ashbery wrote in message
    <5813d0c48ebasura@invalid.addr.uk>:

> In article <mpro.q11dta047jn0401u8.news@stevefryatt.org.uk>, Steve Fryatt
> <news@stevefryatt.org.uk> wrote:
>
> > 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.

> 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

> 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/

[toc] | [prev] | [next] | [standalone]

#5887

In article <mpro.q13yny00yw3jx01ho.news@stevefryatt.org.uk>, Steve
Fryatt <news@stevefryatt.org.uk> wrote:
> On 16 Nov, Richard Ashbery wrote in message
>     <5813d0c48ebasura@invalid.addr.uk>:

> > In article <mpro.q11dta047jn0401u8.news@stevefryatt.org.uk>,
> > Steve Fryatt <news@stevefryatt.org.uk> wrote:
> >
> > > 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.

> > 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

[toc] | [prev] | [next] | [standalone]

#5888

In article <58145cb23cbasura@invalid.addr.uk>, Richard Ashbery
<basura@invalid.addr.uk> wrote:
> In article <mpro.q13yny00yw3jx01ho.news@stevefryatt.org.uk>, Steve
> Fryatt <news@stevefryatt.org.uk> wrote:

> > 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!!! 

> 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.

[toc] | [prev] | [next] | [standalone]

#5889

On 17 Nov, Richard Ashbery wrote in message
    <58145cb23cbasura@invalid.addr.uk>:

> 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?

> 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/

[toc] | [prev] | [next] | [standalone]

#5890

In article <mpro.q14ak103csv5801ho.news@stevefryatt.org.uk>, Steve
Fryatt <news@stevefryatt.org.uk> wrote:
> On 17 Nov, Richard Ashbery wrote in message
>     <58145cb23cbasura@invalid.addr.uk>:

> > 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?

> > 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

[toc] | [prev] | [next] | [standalone]

#5891

On 17 Nov, Richard Ashbery wrote in message
    <5814663fc5basura@invalid.addr.uk>:

> 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/

[toc] | [prev] | [next] | [standalone]

#5892

In article <mpro.q14ga904tx8wa01ho.news@stevefryatt.org.uk>, Steve
Fryatt <news@stevefryatt.org.uk> wrote:
> On 17 Nov, Richard Ashbery wrote in message
>     <5814663fc5basura@invalid.addr.uk>:

> > 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

[toc] | [prev] | [next] | [standalone]

#5893

In article <5814ee09f0basura@invalid.addr.uk>, Richard Ashbery
<basura@invalid.addr.uk> wrote:
> In article <mpro.q14ga904tx8wa01ho.news@stevefryatt.org.uk>, Steve
> Fryatt <news@stevefryatt.org.uk> wrote:
> > On 17 Nov, Richard Ashbery wrote in message
> >     <5814663fc5basura@invalid.addr.uk>:

> > > 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

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.sys.acorn.programmer

csiph-web