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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#5878

On 15/11/2019 22:23, Sebastian Barthel wrote:
> 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

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

#5881

In article <qqonn1$67t$1@dont-email.me>, druck <news@druck.org.uk>
wrote:
> On 15/11/2019 22:23, Sebastian Barthel wrote:
> > 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

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

#5895

On 16/11/2019 14:21, Richard Ashbery wrote:
> In article <qqonn1$67t$1@dont-email.me>, druck <news@druck.org.uk>
> wrote:
>> On 15/11/2019 22:23, Sebastian Barthel wrote:
>>> 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

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

#5897

In article <qqutgu$5lh$2@dont-email.me>, druck <news@druck.org.uk>
wrote:
> On 16/11/2019 14:21, Richard Ashbery wrote:
> > In article <qqonn1$67t$1@dont-email.me>, druck
> > <news@druck.org.uk> wrote:
> >> On 15/11/2019 22:23, Sebastian Barthel wrote:
> >>> 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

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

#5898

On 19/11/2019 14:48, Richard Ashbery wrote:
> In article <qqutgu$5lh$2@dont-email.me>, druck <news@druck.org.uk>
> wrote:
>> On 16/11/2019 14:21, Richard Ashbery wrote:
>>> In article <qqonn1$67t$1@dont-email.me>, druck
>>> <news@druck.org.uk> wrote:
>>>> On 15/11/2019 22:23, Sebastian Barthel wrote:
>>>>> 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

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

#5899

In article <qr1j5f$f8f$1@dont-email.me>,
   druck <news@druck.org.uk> wrote:

[Snip]

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

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

#5900

In article <581589cf6ebrian.jordan9@btinternet.com>,
   Brian Jordan <brian.jordan9@btinternet.com> wrote:
> In article <qr1j5f$f8f$1@dont-email.me>,
>    druck <news@druck.org.uk> wrote:

> [Snip]

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

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

#5901

In message <5815c73df4dave@triffid.co.uk>
          Dave <dave@triffid.co.uk> wrote:

> In article <581589cf6ebrian.jordan9@btinternet.com>,
>    Brian Jordan <brian.jordan9@btinternet.com> wrote:
>> In article <qr1j5f$f8f$1@dont-email.me>,
>>    druck <news@druck.org.uk> wrote:

>> [Snip]

>>> 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
alan@adamshome.org.uk
http://www.nckc.org.uk/

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

#5882

Am Sat, 16 Nov 2019 11:48:48 +0000 schrieb druck:

> On 15/11/2019 22:23, Sebastian Barthel wrote:
>> 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.


> 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

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

#5884

On 16 Nov, Sebastian Barthel wrote in message
    <qqpij4$cg4$2@solani.org>:

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

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

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

#5871

On 14/11/2019 16:24, Richard Ashbery wrote:
> 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

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

#5870

On 13/11/2019 23:35, Sebastian Barthel wrote:
> 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

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

#5872

In article <qqkec1$2bg$1@dont-email.me>, druck <news@druck.org.uk>
wrote:
> On 13/11/2019 23:35, Sebastian Barthel wrote:
> > 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

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

#5876

On 15 Nov, Richard Ashbery wrote in message
    <581353b019basura@invalid.addr.uk>:

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

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

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

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

#5902

In article <qqfdpr$n4t$1@solani.org>, Sebastian Barthel
<naitsabes@freenet.de> wrote:

>  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

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

#5903

In article <58124834ffbasura@invalid.addr.uk>, Richard Ashbery
<basura@invalid.addr.uk> wrote:
> In article <qqfdpr$n4t$1@solani.org>, Sebastian Barthel
> <naitsabes@freenet.de> wrote:

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

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

#5904

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

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

#5905

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.

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

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

#5907

In article <qqi40d$e0m$1@solani.org>, Sebastian Barthel
<naitsabes@freenet.de> wrote:
> Am Wed, 13 Nov 2019 17:05:44 +0000 schrieb 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

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

#5867

In article <468e414f-a0ff-41fd-bc80-216dd45fd082@googlegroups.com>,
   <news@sprow.co.uk> wrote:
> On Tuesday, 12 November 2019 14:06:20 UTC, Richard Ashbery  wrote:
> > 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

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web