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.
[...] the use of writable Texticons for the setting of the grid-siz
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. ...
this is what I'm now working on. The next update should automatically
choose the optimal cell size, together with the optimal grid size ...
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.
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
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.
https://www.youtube.com/watch?v=6avJHaC3C2U&t=262s
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.
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?
By the way, how do you count those null polls?
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 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 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.
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.
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.
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...)
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.
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.
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.
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".
Eventually You could have a look at this :
DEF PROCredraw(wh%)
SYS "Font_SetFont",cell%
[... etc...]
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.
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.
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.
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.
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.
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.
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.
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).
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.
On the other hand, if someone
knows a better symbol for clearing the grid, I would love to hear 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:
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...
In message <5976c58cd9News03@avisoft.f9.co.uk>
on 5 Oct 2021 Martin wrote:
In article <sji2ks$fsg$1@solani.org>,
Sebastian Barthel <naitsabes@freenet.de> wrote:
Am Tue, 05 Oct 2021 15:44:04 +0100 schrieb Martin:
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...
I'm not sure that's quite right. The description of the mask on
page 3-117 of the printed RISC OS 3 PRMs distinguishes between some
events which are completely masked out (e.g pointer
leaving/entering window, lose/gain caret) and others which will
merely be queued, these being window redraw, mouse click, and key
press.
Mind you, I have never experimented with this, however, and there
is a note underneath that says "the bits which are marked 'queue
for later handling' stop the Wimp from proceeding, i.e. it stops
all other tasks too".
In most software you decide which events you're never going to need
(e.g. poll word non-zero, pointer leaving window) and mask them
out. The most important thing is to mask out null events when you
don't need them. Receiving all the possible null events should
only be done if you are doing something intensive and want to
remain responsive with multitasking. It is also important to poll
the Wimp frequently enough during this. I mainly use Wimp_PollIdle
if there is a regular activity to do, like updating a clock, or
every 25cs while dragging is occurring, so as to support the Drag
and Drop protocol, autoscrolling of windows, etc.
This thread takes me back a bit (? a lot)
In the late 1960s I knew John Conway in Cambridge, and we played his new
game using counters on sheets of squared paper.
He would be amazed and delighted that it is still being played 50 years later,
in a more modern form.
Rosemary
In the late 1960s I knew John Conway in Cambridge, and we played his
new game using counters on sheets of squared paper.
Thats a very interesting comment.
And thats why its good if RISCOS gets a new version too; from time to
time. And this should be as usable as possible (there are some minor "glitches" in its current state), but actual its already usable and one
can get a good impression of the power of these 4 little rules that are behind all the fancy gliders and sliders and oscillators.
I can't stop modifying my program.
The most important improvement is that I introduced memory blocks,
instead of two-dimensional arrays. My experience is that memory blocks benefit greatly from getting compiled ... - a 40
times speed gain!
Improvements:
- Much faster.
- Largest grid is now 400 x 400.
- Shapes may be moved around the grid using the cursor keys, with or
without Shift held down.
- Cell shape toggle and Grid toggle, by Adjust clicking on the pane, are swapped. The new location is more intuitive, I think.
- The Random button reflects the cell shape.
http://www.riscos.sprie.nl/sprang.riscos/Downloads/GoL.zip
There are some more speed uprgrade possible, if You try to change the
check procedure. At the cost of readability of the code.
At the start of the program - for a new users first time run - its
absolutely necessary that he can click and play around easily with the "elements". On my screen I would say a 96x64 resolution of the grid is a
good starting point.
Eventually there also could be a second icon for the grid button, too.
One with broken/interrupted lines in it ( - - - - - ) ( - - - - ).
Or a little painted checkmark in the lower corner of the gridsymbol.
Thanks for bringing this to the massive audience :)
Eventually You could also announce the next version (or this one here)
in the comp.sys.acorn.announce and ROOL - its a major step forward.
In article <skmb39$bsm$1@solani.org>,
Sebastian Barthel <naitsabes@freenet.de> wrote:
There are some more speed uprgrade possible, if You try to change the
check procedure. At the cost of readability of the code.
I really wouldn't know how to speed up that routine, short and simple as
it already is.
What I *am* thinking about, is to assign a single bit to
each cell, rather than a byte. This might speed up things, only if it wouldn't cost extra time to calculate the individual bits involved. But
even when it would slow down the program marginally, it would
definitively need 8 times less memory. However, I first have to think
about a short and effective routine that sets and reads single bits.
Eventually You could also announce the next version (or this one here)
in the comp.sys.acorn.announce and ROOL - its a major step forward.
Don't you think that people who read the comp.sys.announce will also
read this group?
Thanks for the feed back, very much appreciated!
{...} the inclusion of an if then statement wich checks if the maximum
of three neighbor cells has been reached already and if so leave the procedure immediately. There should be an optimal place for such a
thing and eventually an maximum of such if-then structures since they
also a need an amount of time. And, its effeciancy depends on state of "filling" of the complete board. E.g. an if c >= 3 then endproc after
the 4th line of if's could be an interesting place for such a structure.
In article <sku720$lfp$1@solani.org>,
Sebastian Barthel <naitsabes@freenet.de> wrote:
{...} the inclusion of an if then statement wich checks if the
maximum of three neighbor cells has been reached already and if so
leave the procedure immediately. There should be an optimal place
for such a thing and eventually an maximum of such if-then
structures since they also a need an amount of time. And, its
effeciancy depends on state of "filling" of the complete board.
E.g. an if c >= 3 then endproc after the 4th line of if's could be
an interesting place for such a structure.
I've thought about making the routine more efficient for many hours, especially about avoiding the duplication of calculations, as you
noticed in your comment. But avoiding duplicate calculations can't be
done without introducing a lot of overhead. The experience with the
extra if-then statements as described above discouraged me from even
trying.
A good example is my attempt to store each cell in a bit, rather
than in a byte. Unfortunately, we don't have a bit operator for
memory blocks, such as the ? for bytes, or the ! for words. Setting
or clearing a particular bit 'n' in a particular byte can be done
rather easily by adding or subtracting 2^n to or from that byte. But
reading a bit is another matter. After a lot of brain crunching I
managed to compose a nice little recursive routine that does the job.
The necessary memory could then be reduce with a factor 8 indeed.
However, the bit-approach slows the program down to such degree, that
I had no other choice than forgetting about it completely.
Hence bit 'n' of byte 'b' is set if (b AND (2^n)) is not zero, or
preferably (b AND (1<<n)).
In article <f2600c8259.tigger@bc63.orpheusinternet.co.uk>,
Nick Roberts <tigger@orpheusinternet.co.uk> wrote:
Hence bit 'n' of byte 'b' is set if (b AND (2^n)) is not zero, or
preferably (b AND (1<<n)).
On 28/10/2021 08:34, Paul Sprangers wrote:
In article <f2600c8259.tigger@bc63.orpheusinternet.co.uk>,
Nick Roberts <tigger@orpheusinternet.co.uk> wrote:
Hence bit 'n' of byte 'b' is set if (b AND (2^n)) is not zero, or
preferably (b AND (1<<n)).
Or maybe:
b%>>n% AND 1
This always returns 1 or 0 and is a tiny bit faster. ;-)
Moreover, in spite of Nick's and Steve's elegant bit operators, theA little while back Martin Avison and I worked on providing bit and byte
result is still noticeably slower than the version based upon bytes.
A little while back Martin Avison and I worked on providing bit and byte arrays for BASIC via a CALL. They were great for saving memory, but
there was a significant penalty in speed over using indirection.
Accessing bits in just BASIC is very much slower again.
Setting and reading bits in computer memory seems so fundamental, that it's weird to find out that it isn't easy at all (well, it may be easy, but unexpectedly time consuming). Thank you for sharing your thoughts and experience.
But a compiled language, particularly C which was designed to twiddle
bits as efficiently as possible, can mean the reduction in the amount of memory passing through the data cache more than makes up for the
additional arithmetic instructions needed. So using bits may be a lot
faster than bytes for large amount of data
No doubt that's true. The need of learning C is something that I postponed
to my retirement. Now that I am, I find it even difficult to remember the common Wimp things in Basic. Erm... any recommendation for a good start for
C in RISC OS?
On 05/11/2021 09:27, Paul Sprangers wrote:
No doubt that's true. The need of learning C is something that I postponed to my retirement. Now that I am, I find it even difficult to remember the common Wimp things in Basic. Erm... any recommendation for a good start for C in RISC OS?
I don't have any specific recommendations, but Wimp programming is a lot easier in C than BASIC. Wimp calls in BASIC take blocks of memory and you have to know offset and type of each field to use with indirection
operators. In C each call takes or returns a C structure which contains
named and typed fields, meaning you don't have to remember offsets, and
the compiler can check you've used the correct type.
Well, you can make C just as hard as BASIC if you make all the calls using _kernel_swi or similar! For an example of that approach (not recommended) see the series by Paul Johnson in Archive many years ago.
If you use OSLib, or a higher-level library like Desk, DeskLib or Steve Fryatt's SFLib, then I would agree, C is easier than BASIC.
On 07/11/2021 20:12, Matthew Phillips wrote:
Well, you can make C just as hard as BASIC if you make all the calls
using
_kernel_swi or similar! For an example of that approach (not
recommended)
see the series by Paul Johnson in Archive many years ago.
If you use OSLib, or a higher-level library like Desk, DeskLib or Steve
Fryatt's SFLib, then I would agree, C is easier than BASIC.
So, it comes down to the quality of the library you use then. Perhaps,
if you have a good quality BASIC library then C is not so much easier. ;-)
For desktop applications with BASIC I would recommend using the Toolbox,
and most of those structure problems disappear. I am happy to write my
own library, but AppBasic is the obvious suggestion for a general
library, and it has excellent tutorials.
On 07/11/2021 20:12, Matthew Phillips wrote:
Well, you can make C just as hard as BASIC if you make all the calls using >> _kernel_swi or similar! For an example of that approach (not recommended) >> see the series by Paul Johnson in Archive many years ago.
If you use OSLib, or a higher-level library like Desk, DeskLib or Steve
Fryatt's SFLib, then I would agree, C is easier than BASIC.
So, it comes down to the quality of the library you use then. Perhaps,
if you have a good quality BASIC library then C is not so much easier. ;-)
For desktop applications with BASIC I would recommend using the Toolbox,
and most of those structure problems disappear. I am happy to write my
own library, but AppBasic is the obvious suggestion for a general
library, and it has excellent tutorials.
I'm not sure using Toolbox overcomes the problem I've described, it
still requires a set of rich data types, which BASIC can't do.
In message <smaru5$130f$1@gioia.aioe.org>
Steve Drain <steve@kappa.me.uk> wrote:
On 07/11/2021 20:12, Matthew Phillips wrote:
Well, you can make C just as hard as BASIC if you make all the calls
using _kernel_swi or similar! For an example of that approach (not
recommended)
see the series by Paul Johnson in Archive many years ago.
If you use OSLib, or a higher-level library like Desk, DeskLib or
Steve Fryatt's SFLib, then I would agree, C is easier than BASIC.
So, it comes down to the quality of the library you use then. Perhaps,
if you have a good quality BASIC library then C is not so much easier.
;-)
For desktop applications with BASIC I would recommend using the Toolbox, >>and most of those structure problems disappear. I am happy to write my
own library, but AppBasic is the obvious suggestion for a general
library, and it has excellent tutorials.
Another one to consider is Dr Wimp for the same reasons.
In message <sm98a9$72b$1@dont-email.me>
on 7 Nov 2021 druck wrote:
On 05/11/2021 09:27, Paul Sprangers wrote:
... The need of learning C is something that I
postponed to my retirement. Now that I am, I find it even difficult
to remember the common Wimp things in Basic. Erm... any
recommendation for a good start for C in RISC OS?
I don't have any specific recommendations, but Wimp programming is a
lot easier in C than BASIC.
Well, you can make C just as hard as BASIC if you make all the calls
using _kernel_swi or similar! For an example of that approach (not recommended) see the series by Paul Johnson in Archive many years ago.
If you use OSLib, or a higher-level library like Desk, DeskLib or Steve Fryatt's SFLib, then I would agree, C is easier than BASIC.
See https://www.stevefryatt.org.uk/risc-os/wimp-prog for Steve's
tutorial on Wimp programming in C.
After clicking and looking around there (YT) the next best step is to get
a GOOD book to learn the basics. There are many(!) books. And no one knows wich the BEST may be.
In message <sm98a9$72b$1@dont-email.me>
on 7 Nov 2021 druck wrote:
On 05/11/2021 09:27, Paul Sprangers wrote:
... . Erm... any
recommendation for a good start for C in RISC OS?
I don't have any specific recommendations, but Wimp programming is a
lot easier in C than BASIC. Wimp calls in BASIC take blocks of memory
and you have to know offset and type of each field to use with
indirection operators. In C each call takes or returns a C structure
which contains named and typed fields, meaning you don't have to
remember offsets, and the compiler can check you've used the correct
type.
Well, you can make C just as hard as BASIC ...
If you use OSLib, or a higher-level library like Desk, DeskLib or Steve Fryatt's SFLib, then I would agree, C is easier than BASIC.
See https://www.stevefryatt.org.uk/risc-os/wimp-prog for Steve's
tutorial on Wimp programming in C.
Dear all,
Version 1.13 of !GoL is ready for download.
Apart from some bug fixes, a new logo, a larger grid, and a far more intuitive manipulation of the grid dimensions, !GoL can now also read some
of the many alien Life file formats. A lot of time has been put into the extraction of the 700+ patterns from the official Life Lexicon library (https://bitstorm.org/gameoflife/lexicon/). As a bonus, the program comes with 3 other archives, one of which contains the shapes that Chris Taylor included in his magnificent !MacroLife. The manual is partly revised.
Download: www.riscos.sprie.nl/sprang.riscos/Downloads/GoL.zip
Kind regards,
Paul
when editing a new grid, if the chosen shape is a square, it is not
drawn correctly and the window must be refreshed "manually".
This problem disappears if we use circles.
Dear all again,
At the risk that everyone will yawn, I herewith announce another update of the Game of Life, version 1.14.
FYI, on a separate note, each time you post 'New prog: Game of Life'
here, you are actually creating a new thread, as opposed to posting on
your original thread. This causes havoc with threaded displays.
In article <spg7f0$uo7$1@dont-email.me>,
Sniffer <sniffer@dewberryfields.co.uk> wrote:
FYI, on a separate note, each time you post 'New prog: Game of Life'
here, you are actually creating a new thread, as opposed to posting on
your original thread. This causes havoc with threaded displays.
Really? That's not what I see here. All postings are grouped within the
same single thread.
As I understand things, I would have started a new
thread when announcing something on comp.sys.announce - and I don't want to abuse that one for minor updates only.
Latterly your posts of updates have been
appearing in their own thread. I need to see what's going wrong at my
end as I have been following with interest.
In article <sphlnj$t9f$1@dont-email.me>,
Sniffer <sniffer@dewberryfields.co.uk> wrote:
Latterly your posts of updates have been
appearing in their own thread. I need to see what's going wrong at my
end as I have been following with interest.
I don't think there's anything wrong at either side. You seem to use Thunderbird on Windows for accessing the news groups, while I use Pluto on RISC OS. I guess both systems have their own defaults of displaying and grouping threads and posts - defaults that probably may be user adjusted...
even using Google Groups (which c.s.a.apps belongs to) to display
postings shows separate threads for 'Re: New prog: Game of Life'.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 79:07:34 |
| Calls: | 6,658 |
| Calls today: | 4 |
| Files: | 12,203 |
| Messages: | 5,333,083 |
| Posted today: | 1 |