Am Sun, 19 Sep 2021 16:52:49 +0200 schrieb Paul Sprangers:

> Dear all,
>
> A RISC OS version of the famous "Game of Life" is ready for download at
>
> www.riscos.sprie.nl/Pages/GameLife.html
>
> The Game of Life is about 50 years old, and invented by the English
> mathematician John Conway. It lets cells (black squares on a white grid)
> evolve according to 3 simple rules. The result is often quite
> fascinating.

Thank You for writing this. It's a fine new program for an old-fashioned
problem. It runs here in RPCEmu on 5.15 without problems. But there are
some minor "glithces" wich could be upgraded or polished out. On of the
easier one is eventually the use of writable Texticons for the setting of
the grid-size. This would speed up the setting and makes it more
comfortable - literally at no costs. Another idea could be the automatic
adaption of the gridsize if one loads a dataset with higher or lower
numbers of cells.

And there seems to be a little problem with the zoom (?). Here the
program always shows the same number of fields on the screen - regardless
wich gridsize is set.

But at all it runs fine and does all the thing a Game of Live should do.

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

> [...] the use of writable Texticons for the setting of the grid-siz

Yes, that would be easy enough, although the bumpers prevent you from
entering invalid numbers more safely. However, see below.

> And there seems to be a little problem with the zoom (?). Here the
> program always shows the same number of fields on the screen - regardless > wich gridsize is set.

The number of fields, that currently have a fixed width of 45, only depends
of the screen resolution. Choosing a larger grid only increases the
invisible area (the porches, as I choosed to call them). However, this is
what I'm now working on. The next update should automatically choose the
optimal cell size, together with the optimal grid size, thus providing the
largest possible visible grid in any screen mode, although you may still
alter these figures manually, of course.

> But at all it runs fine and does all the thing a Game of Live should do

Well, only after releasing my version, I was pointed to !MacroLife of Chris
Taylor. It's 25 years old and 26-bit, but it runs under Aemulor and beats
my program on virtually every aspect. The only reason that I'm still
working on it is the sheer pleasure of amateur programming.

Kind regards,
Paul Sprangers

--
http://www.riscos.sprie.nl

Am Sat, 25 Sep 2021 18:25:12 +0200 schrieb Paul Sprangers:

> In article <sinfrp$700$1@solani.org>,
> Sebastian Barthel <naitsabes@freenet.de> wrote:
>
>> [...] the use of writable Texticons for the setting of the grid-siz
>
> Yes, that would be easy enough, although the bumpers prevent you from
> entering invalid numbers more safely. However, see below.
>
>> And there seems to be a little problem with the zoom (?). Here the
>> program always shows the same number of fields on the screen -
>> regardless > wich gridsize is set.
>
> The number of fields, that currently have a fixed width of 45, only
> depends of the screen resolution. ...
> this is what I'm now working on. The next update should automatically
> choose the optimal cell size, together with the optimal grid size ...

Should be an not too hard task of programming.

Eventually its a good idea to draw only the fields wich are visible too.
This should speed up the thing 'immensely'.

>> But at all it runs fine and does all the thing a Game of Live should do
>
> Well, only after releasing my version, I was pointed to !MacroLife of
> Chris Taylor. It's 25 years old and 26-bit, but it runs under Aemulor
> and beats my program on virtually every aspect. The only reason that I'm
> still working on it is the sheer pleasure of amateur programming.

That's true - !MacroLife is a cool program and is very speedy for its
time.

BUT: it is NOT new, it is NOT 32 Bit safe, it had NEVER seen an upgrade
and it ALWAYS is a good thing if there are other solutions to one
"problem".

Here is a link to motivate You in that GoL is useful in some other ways -
some people are using this to build up logic machines wich then can be
programmed - for instance to create the program Game of Live written in
Game of Live

https://www.youtube.com/watch?v=6avJHaC3C2U&t=262s

:)

Its a fascinating idea this "GoL" and therefore a new variant to play
with it is always good thing.

All the best,
SBn

Dear all,

Just a quick note that !GoL is now at version 1.06. Most important
improvement is the flexibility of the grid (I hope).

http://www.riscos.sprie.nl/sprang.riscos/Pages/GameLife.html

Kind regards,
Paul Sprangers

--
http://www.riscos.sprie.nl

Am Mon, 27 Sep 2021 18:22:40 +0200 schrieb Paul Sprangers:

> Just a quick note that !GoL is now at version 1.06. Most important
> improvement is the flexibility of the grid (I hope).
>
> http://www.riscos.sprie.nl/sprang.riscos/Pages/GameLife.html

OK. Works.

The window is a little bit "displaced" sometimes, in a way that the top-
window-bar is then outside the desktop. But thats on RPCEmu - eventually
this effect doesn't show on real hardware.

Eventually You could try to use the WIMP Windowupdate/redraw Events to
update only the portion of the window wich has been modified too. This
should speed up the things a bit more - especially if one moves the
buttonbar (play,forward,reset,random etc) on top of / over the drawn
playfield.

It's a fine Game - and probably will be so all the times to come. Its
like fractals or 3D plot curves - fascinating in its very own style.

In article <sj1ifr$96t$1@solani.org>,
Sebastian Barthel <naitsabes@freenet.de> wrote:

> Eventually You could try to use the WIMP Windowupdate/redraw Events to
> update only the portion of the window wich has been modified too. This
> should speed up the things a bit more - especially if one moves the
> buttonbar (play,forward,reset,random etc) on top of / over the drawn
> playfield.

Yes, I have been looking at that for hours. When called from the poll loop,
the window always gets redrawn completely, in contrast to the plotting of
the individual cells per generation. The latter only plots the changes
indeed. But I've no idea how to force the redraw loop to be as selective.

Curious about a hint...
Paul

--
http://www.riscos.sprie.nl

> https://www.youtube.com/watch?v=6avJHaC3C2U&t=262s

By the way, this YouTube lecture is absolutely bloody amazing! Thanks for
pointing me to it.

--
http://www.riscos.sprie.nl

In article <59738a7fddPaul@sprie.nl>,
Paul Sprangers <Paul@sprie.nl> wrote:
> In article <sj1ifr$96t$1@solani.org>,
> Sebastian Barthel <naitsabes@freenet.de> wrote:

> > Eventually You could try to use the WIMP Windowupdate/redraw
> > Events to update only the portion of the window wich has been
> > modified too. This should speed up the things a bit more -
> > especially if one moves the buttonbar (play,forward,reset,random
> > etc) on top of / over the drawn playfield.

> Yes, I have been looking at that for hours. When called from the
> poll loop, the window always gets redrawn completely, in contrast
> to the plotting of the individual cells per generation. The latter
> only plots the changes indeed. But I've no idea how to force the
> redraw loop to be as selective.

> Curious about a hint...

Have you looked at the Redraw Window poll request? Also SWIs
Wimp_RedrawWindow and Wimp_GetRectangle - they give the rectangle to
be redrawn. SWI Wimp_UpdateWindow can be used to start the process
manually, if the Wimp does not.

I notice that GoL uses Wimp_Poll all the time, even when it it just
sitting on the iconbar doing nothing. It is currently processing
anything up to 90,000 Null Polls/second doing nothing, using 30+% of
the processor. This causes excessive power to be used and heat to be
produced, resulting in fans being called into action more than they
need. It would be better if Null Polls can be masked when not
required, or WimpPoll_Idle used.
Martin

--
Martin Avison
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received.

In article <5973945a9cNews03@avisoft.f9.co.uk>,
Martin <News03@avisoft.f9.co.uk> wrote:

> Have you looked at the Redraw Window poll request? Also SWIs
> Wimp_RedrawWindow and Wimp_GetRectangle - they give the rectangle to
> be redrawn. SWI Wimp_UpdateWindow can be used to start the process
> manually, if the Wimp does not.

I use Wimp_UpdateWindow for redrawing the changed cells individually, while
leaving all others untouched. But I have no idea to do that within the
RedrawWindow poll request. After all, after each new generation I know
exactly which cells need to be redrawn, but how do I know that when another
window floats over mine?

> I notice that GoL uses Wimp_Poll all the time, even when it it just
> sitting on the iconbar doing nothing. It is currently processing
> anything up to 90,000 Null Polls/second doing nothing, using 30+% of
> the processor.

I didn't think of that, but making the poll mask dependent of auto running
or not is easy enough. It will be fixed in the next update. By the way, how
do you count those null polls?

Thank you for helping me improve things.

Kind regards,
Paul

--
http://www.riscos.sprie.nl

On 29/09/2021 15:46, Paul Sprangers wrote:
> By the way, how do you count those null polls?

My !APPstat will count them. Also !CPULoad will show high usage with
NULLs active. http://www.armclub.org.uk/free

---druck

In article <597399eea9Paul@sprie.nl>,
Paul Sprangers <Paul@sprie.nl> wrote:
> In article <5973945a9cNews03@avisoft.f9.co.uk>,
> Martin <News03@avisoft.f9.co.uk> wrote:

> > Have you looked at the Redraw Window poll request? Also SWIs
> > Wimp_RedrawWindow and Wimp_GetRectangle - they give the rectangle
> > to be redrawn. SWI Wimp_UpdateWindow can be used to start the
> > process manually, if the Wimp does not.

> I use Wimp_UpdateWindow for redrawing the changed cells
> individually, while leaving all others untouched. But I have no
> idea to do that within the RedrawWindow poll request. After all,
> after each new generation I know exactly which cells need to be
> redrawn, but how do I know that when another window floats over
> mine?

That is what the Redraw Window request is for from Wimp_Poll.

> > I notice that GoL uses Wimp_Poll all the time, even when it it
> > just sitting on the iconbar doing nothing. It is currently
> > processing anything up to 90,000 Null Polls/second doing nothing,
> > using 30+% of the processor.

> I didn't think of that, but making the poll mask dependent of auto
> running or not is easy enough. It will be fixed in the next update.
> By the way, how do you count those null polls?

I use my TaskUsage, fom http://www.avisoft.f9.co.uk/

Martin

--
Martin Avison
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received.

Am Wed, 29 Sep 2021 14:00:25 +0200 schrieb Paul Sprangers:

>> https://www.youtube.com/watch?v=6avJHaC3C2U&t=262s
>
> By the way, this YouTube lecture is absolutely bloody amazing! Thanks
> for pointing me to it.

:)

In message <597399eea9Paul@sprie.nl>
on 29 Sep 2021 Paul Sprangers wrote:

> In article <5973945a9cNews03@avisoft.f9.co.uk>,
> Martin <News03@avisoft.f9.co.uk> wrote:
>
> > Have you looked at the Redraw Window poll request? Also SWIs
> > Wimp_RedrawWindow and Wimp_GetRectangle - they give the rectangle to
> > be redrawn. SWI Wimp_UpdateWindow can be used to start the process
> > manually, if the Wimp does not.
>
> I use Wimp_UpdateWindow for redrawing the changed cells individually, while
> leaving all others untouched. But I have no idea to do that within the
> RedrawWindow poll request. After all, after each new generation I know
> exactly which cells need to be redrawn, but how do I know that when another
> window floats over mine?

The Wimp tells you which bits of the window need redrawing in the block
pointed to by R1 in Wimp_GetRectangle. That gives you the x and y
co-ordinates of the portion of the window which you need to redraw. The Wimp
also sets the graphics window to match this area, so that if you plot
anything outside that area it will not appear, thus avoiding other windows
being obliterated.

I imagine you have the cells in a two-dimensional array. You need to work
out, from the screen or window co-ordinates provided by the Wimp, which cells
overlap with that area, and then just redraw those, rather than looping
through the whole of your array.

It's extra effort, but it can really help to speed up the redraw.

(Apologies if this is what you are doing already, but it sounded from your
questions as though it wasn't.)

If you don't mind using up the memory, anotehr approach is to create a sprite
as big as your window work area, and redirect all your output to that sprite.
Then you can simply plot the sprite in response to every window request. It
appears that OS_SpriteOp knows about the graphics window and avoids doing any
work on the bits that the Wimp has not asked for.

--
Matthew Phillips
Durham

In article <df85c07359.Matthew@sinenomine.co.uk>,
Matthew Phillips <spam2011m@yahoo.co.uk> wrote:

> I imagine you have the cells in a two-dimensional array. You need to
> work out, from the screen or window co-ordinates provided by the Wimp,
> which cells overlap with that area, and then just redraw those, rather
> than looping through the whole of your array.

Looping through the whole of my array was exactly what I was doing, and I
couldn't see how to minimalise that process. However, with your explanation
I finally managed to work out the x and y coordinates of the redraw block,
returned by Wimp_GetRectangle, and calculate the corresponding cells from
there. It's not completely perfect yet (dragging a window over the grid
still leaves traces), but at least and at last it now happens
instantaneously.

In the past you helped me mastering the Wimp_UpdateWindow call, and now I
feel that I'm close to understanding the RedrawWindow magic as well. I
really can't be thankful enough.

> If you don't mind using up the memory, anotehr approach is to create a
> sprite as big as your window work area, and redirect all your output to
> that sprite. Then you can simply plot the sprite in response to every
> window request. It appears that OS_SpriteOp knows about the graphics
> window and avoids doing any work on the bits that the Wimp has not asked
> for.

No doubt, but apart from having no idea how to redirect output to a sprite,
I fear that plotting such large sprites would have a negative effect on the
animation speed. Anyhow, since I'm more or less getting familiar with the
Redraw- and UpdateWindow routines, I'm happy to stick with them.

Kind regards,
Paul

--
http://www.riscos.sprie.nl

In message <59741f2bd3Paul@sprie.nl>
on 30 Sep 2021 Paul Sprangers wrote:

> In article <df85c07359.Matthew@sinenomine.co.uk>,
> Matthew Phillips <spam2011m@yahoo.co.uk> wrote:
>
> > I imagine you have the cells in a two-dimensional array. You need to
> > work out, from the screen or window co-ordinates provided by the Wimp,
> > which cells overlap with that area, and then just redraw those, rather
> > than looping through the whole of your array.
>
> Looping through the whole of my array was exactly what I was doing, and I
> couldn't see how to minimalise that process. However, with your explanation
> I finally managed to work out the x and y coordinates of the redraw block,
> returned by Wimp_GetRectangle, and calculate the corresponding cells from
> there. It's not completely perfect yet (dragging a window over the grid
> still leaves traces), but at least and at last it now happens
> instantaneously.

Yes, it can be hard to get the rounding in the correct direction to include
all the bits that do need redrawing.

I'm glad to hear you have pretty much got it working. It's very satisfying
getting redraw speeded up!

--
Matthew Phillips
Durham

Dear all,

Version 1.07 of the Game of Life is now ready for download:

http://www.riscos.sprie.nl/sprang.riscos/Downloads/GoL.zip

IMPROVEMENTS
- The poll mask now only allows null polls when animation is active.
- The cell redraw is optimised
- The window redraw is greatly optimised, albeit it still not perfect.
- The control over grid dimensions is now more flexible.
- The Options window can also be opened by clicking Adjust on the iconbar
icon.
- Some shapes come with comments that are shown in the Message window.

STILL TO DO
- Finding out why horizontal drags over the grid leave ugly traces
(vertical drags don't).
- Finding out if sprite plotting will be faster than font painting (I can't
see why, but you never know).
- Finding out if Chris Taylor is still around, the author of the far
superior !MacroLife. (He doesn't reply to my e-mail...)

Kind regards,
Paul

--
http://www.riscos.sprie.nl

Dear all,

With the much appreciated help of Matthew Phillips, the redraw routine of
!GoL is finally as it should be. Version 1.08 is out now.

http://www.riscos.sprie.nl/sprang.riscos/Downloads/GoL.zip

You will also find some modifications on the pane.

Kind regards,
Paul

--
http://www.riscos.sprie.nl

Am Sun, 03 Oct 2021 13:25:06 +0200 schrieb Paul Sprangers:

> Version 1.07 of the Game of Life is now ready for download:
>
> http://www.riscos.sprie.nl/sprang.riscos/Downloads/GoL.zip

Great - to see it evolving.

> IMPROVEMENTS - The poll mask now only allows null polls when animation
> is active.

I don't know if this is necessary - it should'n give much speed
improvements. It does if one never uses a null event, but its absolutely
OK to use it for calculating such stuff like in this program.

But: Probably its not allowed to switch the (poll)mask% from within a
running programm. I've never seen this and as far as I know it is, at
least, "unusual". Normally a program says at the begin wich polls it
wants and then uses only these - but it won't switch them on/off while it
is active.

> - The cell redraw is optimised - The window redraw is greatly optimised,
> albeit it still not perfect.

I see, You have done it in a "real RISCOS" way. Many people don't
understand whats done there, and thats the WIMP only redraws a portion of
the screen or the window and the actual drawing of this portion is done
by the program.

There are some speedupdates "available" wich You should include.

First of all You are deleting the part of the window wich the WIMP tells
You to "Redraw" by Yourself. Therefore You plot a color-inverted Symbol
in/at the request place(s). Thats absolutely OK, and one can do so - it
works; more or less. BUT: The WIMP not only tells You with Wimp_Redraw /
Wimp_GetRectangle the positions on the screen that have to be updated - it
also "clears" these areas for You.

Its much faster to NOT use the PROC_paint , wich not only draws a symbol
with inverted colours to every "clear" (FALSE) positon but wich also
tests everyone of them, uses an time consuming procedure call and tries
to set a Font Color and the Font itself for EVERY (!) plotted element.

Eventually You could have a look at this :

DEF PROCredraw(wh%)
SYS "Font_SetFont",cell%
!block% = wh%
SYS "Wimp_GetWindowState",,block%
ox% = block%!4 - block%!20
oy% = block%!16 - block%!24
SYS "Wimp_RedrawWindow",,block% TO more%
xstart% = (block%!28 - ox%) DIV cellsize% +porch%
xend% = (block%!36 - ox%) DIV cellsize% +porch%
ystart% = (oy% - block%!40) DIV cellsize% +porch%
yend% = (oy% - block%!32) DIV cellsize% +porch% + 1
cellx% = xstart% : celly% = ystart%

REM de-REM to show the not perfectly plotted rectangles
REM SYS "Wimp_SetColour",10
REM RECTANGLE FILL block%!28,block%!32,block%!36-block%!28,block%!40-block
%!32

IF round% THEN
chr$ = "l"
ELSE
chr$ = "n"
ENDIF
SYS "Wimp_SetFontColours",,0,5
SYS "Font_FindFont",,"Selwyn",fontsize*15,fontsize*15 TO cell%
SYS "Font_SetFont",cell%

WHILE more%

REM REPEAT
REM PROCpaint(celly%,cellx%)
REM IF cellx% < xend% THEN
REM cellx%+=1
REM ELSE
REM cellx% = xstart%
REM IF celly% < yend% THEN celly%+=1
REM ENDIF
REM UNTIL celly% = yend% AND cellx% = xend%

celly% = ystart%
WHILE celly% <= yend%

cellx% = xstart%
WHILE cellx% <= xend%

IF grid%(celly%,cellx%)=TRUE THEN SYS "Font_Paint",cell%,chr$,16, ox
%+(cellx%-porch%)*cellsize%, oy%-(celly%-porch%+1)*cellsize%

cellx%+=1
ENDWHILE

celly%+=1
ENDWHILE

SYS "Wimp_GetRectangle",,block% TO more%

ENDWHILE

ENDPROC

Here the Wimp Redraw sets the fonts once beforehand, the colors and
variables too and runs only one short plot-loop (WHILE) to plot the
symbols. It never tries to delete anything - 'cause the WIMP did this
already before it give to !block back to You.

Give it a try !

It's not perfect. There are some glitches too if one moves the toplevel
window not straight in X or Y but it should be possible to find a fix.

And, eventually, You want to have a deeper look into the magic of Font
Handles. These are there to set them "permanently". So one can find a
font and give it a name - a handle. After this one can always use this
handle to set the actual font. Since the Redraw loop eliminated the
"delete" font plotting its no problem here, but You use this at other
lines too. And, there You only uses the handle "cell%" for every font,
wich, everytime, You find directly beforhand at the same lines or nearby.
BUT: You can find the to Fonts You are using once at the start of the
program - and give them separate names / handles%. E.g. font15% and
font16% - and then use only these handles in the program.

And, to be in line with the WIMP redrawing it is, eventually, a good idea
NOT to plot a font if You want to delete a position on the screen. You
also could try to calculate the position of the bounding-box and then plot
a filled rectangled on the screen, colored to background color.

DEF PROCpaint(y%,x%)
IF grid%(y%,x%) = FALSE THEN
REM SYS "Wimp_SetFontColours",,5,0
REM SYS "Font_FindFont",,"Selwyn",fontsize*16,fontsize*16 TO cell%
REM CHR$ = "n"
SYS "Wimp_SetColour",1
RECTANGLE FILL ox%+(x%-porch%)*cellsize%, oy%-(y%-porch%+1)*cellsize%,
cellsize%, cellsize%
ELSE
SYS "Wimp_SetFontColours",,0,5
IF round% THEN
SYS "Font_FindFont",,"Selwyn",fontsize*15,fontsize*15 TO cell%
chr$ = "l"
ELSE
chr$ = "n"
ENDIF
SYS "Font_Paint",,chr$,16,ox%+(x%-porch%)*cellsize%,oy%-(y%-porch%
+1)*cellsize%
ENDIF

This, together with the thing I wrote on fonts and their handles, allows
You to reduce this code to a minimum, since there is no need for changing
and finding fonts and no one needs change the colors - since Wimp/Graphic
and Font colors are set seperately.

The setting of chr$ too is minimisable - since its only used for ploting,
not for deleting. So it can be eliminated from the PROCpaint completely -
I didn't done this here.

> - The control over grid dimensions is now more flexible.
> - The Options window can also be opened by clicking Adjust on the
> iconbar icon.
> - Some shapes come with comments that are shown in the Message window.

Every new feature is a godd feature.

One thing in the User Experience can be a point to overthink: The square
button on the userpanel is in its "old" logic a STOP symbol (tapes, CDs).
But Your button here is a reset scwitch. Some people may find it
misleading if they want to stop their "run" by pressing stop - ... and
everything vanishes into the dungeon of doom.

> STILL TO DO - Finding out why horizontal drags over the grid leave ugly
> traces (vertical drags don't).
> - Finding out if sprite plotting will be faster than font painting (I
> can't see why, but you never know).
> - Finding out if Chris Taylor is still around, the author of the far
> superior !MacroLife. (He doesn't reply to my e-mail...)

Eventually You could search for him by asking at ROOL. I think there will
be people around who know something more and can tell how to reach for
him.

All the Best,
Sebastian

In article <sjhmtp$evl$1@solani.org>,
Sebastian Barthel <naitsabes@freenet.de> wrote:
> Am Sun, 03 Oct 2021 13:25:06 +0200 schrieb Paul Sprangers:

> > IMPROVEMENTS - The poll mask now only allows null polls when
> > animation is active.

> I don't know if this is necessary - it should'n give much speed
> improvements. It does if one never uses a null event, but its
> absolutely OK to use it for calculating such stuff like in this
> program.

> But: Probably its not allowed to switch the (poll)mask% from within
> a running programm. I've never seen this and as far as I know it
> is, at least, "unusual". Normally a program says at the begin wich
> polls it wants and then uses only these - but it won't switch them
> on/off while it is active.

Changing the poll mask is perfectly normal. The key thing is to have
Nulls disabled when the program does not require them - eg when it is
doing nothing, sitting idly on the iconbar waiting for something to
do.

You can also switch to using PollIdle, and change the delay times,
when a program is running.

--
Martin Avison
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received.

Am Tue, 05 Oct 2021 15:44:04 +0100 schrieb Martin:

> In article <sjhmtp$evl$1@solani.org>,
> Sebastian Barthel <naitsabes@freenet.de> wrote:
>> Am Sun, 03 Oct 2021 13:25:06 +0200 schrieb Paul Sprangers:
>
>> > IMPROVEMENTS - The poll mask now only allows null polls when
>> > animation is active.
>
>> I don't know if this is necessary - it should'n give much speed
>> improvements. It does if one never uses a null event, but its
>> absolutely OK to use it for calculating such stuff like in this
>> program.
>
>> But: Probably its not allowed to switch the (poll)mask% from within a
>> running programm. I've never seen this and as far as I know it is, at
>> least, "unusual". Normally a program says at the begin wich polls it
>> wants and then uses only these - but it won't switch them on/off while
>> it is active.
>
> Changing the poll mask is perfectly normal. The key thing is to have
> Nulls disabled when the program does not require them - eg when it is
> doing nothing, sitting idly on the iconbar waiting for something to do.
>
> You can also switch to using PollIdle, and change the delay times, when
> a program is running.

OK. That's interesting !

Then one can change almost all other poll events simply by disabling the
mask entry. E.g. to temporarily switch off reaction to keypresses or
messages.

I only knew, that it is essential to outmask the nullevent, if the
program don't use it, and most simple programs don't need it.

In article <sji2ks$fsg$1@solani.org>,
Sebastian Barthel <naitsabes@freenet.de> wrote:
> Am Tue, 05 Oct 2021 15:44:04 +0100 schrieb Martin:

> > In article <sjhmtp$evl$1@solani.org>,
> > Sebastian Barthel <naitsabes@freenet.de> wrote:
> >> Am Sun, 03 Oct 2021 13:25:06 +0200 schrieb Paul Sprangers:
> >
> >> > IMPROVEMENTS - The poll mask now only allows null polls when
> >> > animation is active.
> >
> >> I don't know if this is necessary - it should'n give much speed
> >> improvements. It does if one never uses a null event, but its
> >> absolutely OK to use it for calculating such stuff like in this
> >> program.
> >
> >> But: Probably its not allowed to switch the (poll)mask% from
> >> within a running programm. I've never seen this and as far as I
> >> know it is, at least, "unusual". Normally a program says at the
> >> begin wich polls it wants and then uses only these - but it
> >> won't switch them on/off while it is active.
> >
> > Changing the poll mask is perfectly normal. The key thing is to
> > have Nulls disabled when the program does not require them - eg
> > when it is doing nothing, sitting idly on the iconbar waiting for
> > something to do.
> >
> > You can also switch to using PollIdle, and change the delay
> > times, when a program is running.

> OK. That's interesting !

> Then one can change almost all other poll events simply by
> disabling the mask entry. E.g. to temporarily switch off reaction
> to keypresses or messages.

Yes ... but beware that the keypresses, messages or whatever will not
be repeated, so they will be totally ignored. Null Polls will happen
again at some time...

--
Martin Avison
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received.

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

> But: Probably its not allowed to switch the (poll)mask% from within a
> running programm. I've never seen this and as far as I know it is, at
> least, "unusual".

I never did this before, but it just appears to work. Martin Avison has
convinced us that it certainly isn't as unusual as we thought.

> Eventually You could have a look at this :
> DEF PROCredraw(wh%)
> SYS "Font_SetFont",cell%
> [... etc...]

The idea of making use of rectangle fills rather than font painting is very
valuable. Actually, it was my intention to eventually abandon the font
approach and draw lines and fill rectangles instead. As a try-out I copied
your redraw routine, together with the modified font-paint routine to the
source, and it worked indeed, more or less. The main thing is that your
routines do not create a grid. Only when evolution is running, the grid is
drawn cell by cell again. So, something is missing apparently.
More importantly however is that I don't notice any speed improvement. But
that may be a matter of optimisation.

> It's not perfect. There are some glitches too if one moves the toplevel
> window not straight in X or Y but it should be possible to find a fix.

That fix is provided by Matthew Phillips. In the old routine, the start-
and end-addresses were defined outside the WHILE more% loop. After having
them moved to the inside, the redraw was finally perfect.

> BUT: You can find the to Fonts You are using once at the start of the
> program - and give them separate names / handles%. E.g. font15% and
> font16% - and then use only these handles in the program.

That's a clever solution that I will certainly include in the next update.

> One thing in the User Experience can be a point to overthink: The square
> button on the userpanel is in its "old" logic a STOP symbol (tapes, CDs).
> But Your button here is a reset scwitch. Some people may find it
> misleading if they want to stop their "run" by pressing stop - ... and
> everything vanishes into the dungeon of doom.

Again, it was Matthew Phillips who drew my attention to this as well. You
will find a more intuitive pane in the latest update.

I really appreciate your comments and hints to improvement, and they set me
thinking about the inner magics of the Wimp more than I ever did before.

Kind regards,
Paul

--
http://www.riscos.sprie.nl

Am Wed, 06 Oct 2021 10:51:16 +0200 schrieb Paul Sprangers:

> In article <sjhmtp$evl$1@solani.org>,
> Sebastian Barthel <naitsabes@freenet.de> wrote:
>
>> Eventually You could have a look at this :
>> DEF PROCredraw(wh%)
>> SYS "Font_SetFont",cell%
>> [... etc...]
>
> The idea of making use of rectangle fills rather than font painting is
> very valuable. Actually, it was my intention to eventually abandon the
> font approach and draw lines and fill rectangles instead. As a try-out I
> copied your redraw routine, together with the modified font-paint
> routine to the source, and it worked indeed, more or less. The main
> thing is that your routines do not create a grid. Only when evolution is
> running, the grid is drawn cell by cell again. So, something is missing
> apparently.
> More importantly however is that I don't notice any speed improvement.
> But that may be a matter of optimisation.

The original routine doesn't do a grid, too. The plot one can see is only
"by accident". Must have to do something with the colour of the
background and the colours of the font (I would say so).

If You want to plot a real(!) grid You can do so by including two LINE
commands in the redraw loop. Since You know the exact position of the
symbol wich should be plotted its easy to find e.g. the left-bottom to
left-upper and the left-bottom to right-bottom coordinates. Since LINE
are defined by width and height You only need to know them only once for
every LINE, and since Your plot-boxes are quadrate squares width and
height are the same.

DEF PROCredraw(wh%)

SYS "Font_SetFont",cell%
!block% = wh%
SYS "Wimp_GetWindowState",,block%
ox% = block%!4 - block%!20
oy% = block%!16 - block%!24
SYS "Wimp_RedrawWindow",,block% TO more%

IF round% THEN
chr$ = "l"
ELSE
chr$ = "n"
ENDIF

SYS "Wimp_SetFontColours",,0,5

SYS "Font_FindFont",,"Selwyn",fontsize*15,fontsize*15 TO cell%

SYS "Font_SetFont",cell%

WHILE more%
xstart% = (block%!28 - ox%) DIV cellsize% +porch%
xend% = (block%!36 - ox%) DIV cellsize% +porch%
ystart% = (oy% - block%!40) DIV cellsize% +porch%
yend% = (oy% - block%!32) DIV cellsize% +porch% +1
cellx% = xstart% : celly% = ystart%

SYS "Wimp_SetColour",14

celly% = ystart%
WHILE celly% <= yend%

cellx% = xstart%
WHILE cellx% <= xend%

REM IF grid%(celly%,cellx%)=TRUE THEN SYS "Font_Paint",cell%,chr
$,16, ox%+(cellx%-porch%)*cellsize%, oy%-(celly%-porch%+1)*cellsize%

xpos%=ox%+(cellx%-porch%)*cellsize%
ypos%=oy%-(celly%-porch%+1)*cellsize%

IF grid%(celly%,cellx%)=TRUE THEN SYS "Font_Paint",cell%,chr$,16,
xpos%, ypos%

LINE xpos%,ypos%,xpos%,ypos%+cellsize%
LINE xpos%,ypos%,xpos%+cellsize%,ypos%

cellx%+=1
ENDWHILE

celly%+=1
ENDWHILE

SYS "Wimp_GetRectangle",,block% TO more%
ENDWHILE
ENDPROC

This then plots a real(!) grid. But only at redraws.

To plot it at the start a similiar code needs to be included in the right
place. One of the things the WIMP gives to the humble programmer is the
"easy update a window" variant. Therefore one uses the
"Wimp_UpdateWindow" call - wich is espacially useful if one already has a
functional redraw routine. Its then only a copy of the redraw procedure -
only the Redraw call changes to UpdateWindow. And: one has to keep in
mind that UpdateWindow operates with WorkArea coordinates (these are
negative and counted from top) whereas Redraw uses "normal" coordinates.
The PRMs have a good chapter with good drawings about this. And, in
addition, the clearing of the rectangles has to be done by the programmer.

To get it running as a hack You could also include the two LNIE commands
in the paint procedure for the first time.

If this runs as intended one has then a new option wich potetnially
pleases some users - Grid on/off is then possible.

Otherwise: if Your variant (wich shows a grid, but doesn't "paint" such a
thing intentionally) is working reliably and on every platform its
eventually faster than drawing hundreds of separate lines.
So its then a "trick" - and not a bad one.

>> It's not perfect. There are some glitches too if one moves the toplevel
>> window not straight in X or Y but it should be possible to find a fix.
>
> That fix is provided by Matthew Phillips. In the old routine, the start-
> and end-addresses were defined outside the WHILE more% loop. After
> having them moved to the inside, the redraw was finally perfect.

Yes. That makes sense, absolutely. It (the WIMP) always updates the new
rectangle for redraw - but the program know only about the next
coordinates if it asks and updates them - in the inner loop; otherwise one
will only plot the firstmost area again and again.

>> One thing in the User Experience can be a point to overthink: The
>> square button on the userpanel is in its "old" logic a STOP symbol
>> (tapes, CDs).
>> But Your button here is a reset scwitch. Some people may find it
>> misleading ...
>
> Again, it was Matthew Phillips who drew my attention to this as well.
> You will find a more intuitive pane in the latest update.

've seen it in v108. The new pane has the square button, but the
arrangement of the buttons on the left side is much better than before,
since it now follows a logic order.

> I really appreciate your comments and hints to improvement, and they set
> me thinking about the inner magics of the Wimp more than I ever did
> before.

Thats fine.

And I, too, learn some things or refresh long forgotten "structures", if
I write such comments. WIMP is a "riddle" and "mystery" and sometimes it
is very frustrating. But then, if it runs and does the things as
intended, its a very cool and clean and speedy desktop interface.

All the best,
SBn

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

> The original routine doesn't do a grid, too. The plot one can see is only
> "by accident". Must have to do something with the colour of the
> background and the colours of the font (I would say so).

That's exactly so. But I wouldn't call it 'by accident', it's very much
intentional: the grid is drawn by white Selwyn squares, while the 'lines'
are actually nothing else than the window background peeking through those
squares.

Since most squares need to be drawn and redrawn sooner or later anyhow -
and often with hundreds or even thousands simultaneously - I assumed that
this would be a faster approach than drawing real lines all the time as
well, something that your alternative seems to confirm. It's not noticeably
slower, but it definitively isn't faster.

(As an aside: I write and test this program on a 4té, which is so
incredibly fast that sometimes the speed of the subsequent generations
exceeds the screen refresh, resulting in seemingly stuttering oscillations,
to be compared with car wheels spinning backwards in movies.)

> The new pane has the square button, but the arrangement of the buttons
> on the left side is much better than before, since it now follows a
> logic order.

.... and the Fast Forward button now turns into the Pause symbol when
running, which should distract people from clicking the white square button
when they want to interrupt the process. On the other hand, if someone
knows a better symbol for clearing the grid, I would love to hear it.

Kind regards,
Paul

--
http://www.riscos.sprie.nl

In article <597824d483Paul@sprie.nl>,
Paul Sprangers <Paul@sprie.nl> wrote:

> On the other hand, if someone
> knows a better symbol for clearing the grid, I would love to hear it.

To answer my own question, I've drawn a small grid in the Clear grid
button. I think it is more clear now.

Kind regards,
Paul

--
http://www.riscos.sprie.nl