========================================================================                                  Self-Assigned Tasks                                       as a Learning Process                      by John Collett Ed: Check the first part of this piece in MD26. This one covers a series of programming tasks that John set himself as a way of exploring Amos - creating sprites, palette tool, requestor box and piano keyboard.  (( 27 )) (( 27 )) (( 27 )) (( 27 )) (( 27 )) (( 27 )) (( 27 )) (( 27 )) Once I had mastered the basic moves using the Amos Editor - entering, running, changing, and saving a program - and sampled the delights of one or two of the more accessible accessories, I set out on a systematic exploration, intending to work through the Guide chapter by chapter. Obviously some of this had to be done, and some of the necessary learning occurred. It was a bit frustrating though, since I was not working towards the tangible goal of a useful or at least amusing program. So I have been setting myself specific and non-trivial targets: "I shall now produce an Amos program which will ...." As soon as one such task is finished, I set myself another. I am well into this process now, and am finding it to be an excellent way of learning about the commands, and at least some of the special features of Amos and its accessories. To date, I have completed half a dozen specific tasks, and have plans for several more. One or two of them may have a purpose other than being a learning activity - they might even in themselves be useful in the future - but I know that superior programs for similar purposes already exist in other languages, and almost certainly already exist in Amos, though I haven't yet explored any Amos Public Domain disks. Am I wasting my time, like re-inventing the wheel? Why bother to write programs if others already exist to do the same job? To be honest, I have never been fully believed that retracing the steps already trodden by others is a waste of time, or that "re-inventing the wheel" necessarily means that the time involved could have been more profitably spent. There was a time when I could have quoted chapter and verse of current theories of learning, but I got a bit tired of the changes. No sooner had I more or less understood the latest "in" theory, than it was out of date. I began to think they were a bit like buses - if you miss one, don't worry, another one will be along soon. (Though actually, from my memory of London buses, you have to wait quite a while, and then three arrive at once.) So I have at the moment no idea of how my learning strategy fits in with current theories - and does it matter anyway? But I am very sure that the method I have adopted for this particular and fairly substantial learning task is yielding a satisfactory rate of learning, an adequate degree of understanding, and an extremely high level of personal satisfaction.  Task Number 1  Create a set of sprites, twenty or so.  Place them on the screen, all at once,  Have them move, one at a time, a certain distance. For someone who had never really come to grips with sprites in other Basics, this really was outrageously ambitious as a first task, but I had had a look at the Sprite Editor and thought I could handle it. I had looked at the introduction to the chapter called "Hardware Sprites", and had been completely taken in by words like "amazing features", "at your fingertips", "complete control", "blindingly fast", "dozens of sprites", and "effortlessly manipulate". In my heart of hearts, I surely didn't believe a word of it, but their confident tone made my set task look a bit trivial. I plunged in. My sprites would be a set of numbers and letters, of which the following is a very poor imitation:    _   _   _   _     _   _   /\  |_> /  | \ |_   |  | |  _| /--\ |_> \_  |_/ |_   |  |_|  _|                 They were to be a bit more colourful than this, and based on a reasonable font. I thought that a complete set of such numbers and letters might be useful in all kinds of future screen applications. The necessary steps appeared to be to draw each letter in the Sprite Editor, and save it in a Sprite Bank. That seemed a bit tedious, so I examined the Sprite Grabber instead - "The Sprite Grabber allows you grab (sic) a list of sprite images out of any IFF format picture." There is mention of "using your favourite drawing package", and so I was soon in the familiar territory of DeLuxe Paint. The letters A to J and digits 0 to 9 were soon typed in, enlarged, and outlined, and the screen was saved. I got to work with the Sprite Grabber, and it was all so much easier than I had expected. A couple of clicks and a rubber-band rectangle round each item was all it took, and I had soon created twenty sprites, ready to be stored. Click on the icon indicating ".ABK to disc", supply a destination and name for the new sprite bank, and it's done. Back to the Sprite Editor to check that it would recognize my new Sprite Bank and behave as promised. All was well. Now all I needed was a program to use those sprites, and its key line was clearly going to be SPRITE n,x,y,i. In simple terms, n is the identification number of the sprite on the screen, x and y its position, and i the image number as stored in the bank. The full story is much more complex, occupying four or five pages of the Guide, and going into "Computed Sprites" (to get up to 64 instead of the usual limit of 8), combining sprites, sprite colour registers, and so on. It doesn't all have to be understood. The main steps of the program I wrote were: Open a screen Borrow the procedure INIT_SPRITES (Guide, p.151) to fix colours. Load the Sprite Bank For j = 1 to 20  SPRITE ...  Place each sprite in position. NEXT For j = 1 to 20  Select each sprite for movement  For p = x1 to x2  SPRITE etc.  From start to end position  Next Next It all worked absolutely as planned, though the movement is too fast to watch, and I haven't yet bothered to slow it down. That wasn't a part of the task. Nothing succeeds like success, and I was ready to try something else.  Task 2 - Palette Tool While working on Task 1 I had tried opening screens in various modes, and had played around with the colour settings. I had already decided that I didn't like the on-off flashing of the cursor, and killed it with Flash Off. The cursor itself was not needed either, and that was suppressed with Curs Off (which I suppose makes the Flash Off redundant anyway). It was already clear that these preliminary settings were going to be needed regularly, and I wrote a small separate patch containing them, ready for loading into any future program. Which colours should I set as my default? The usual four? But I might need 8, 16, 32 ... What I needed, and this became Task Number 2, was a Palette tool. Now I know I've already got three or four such tools. That wasn't the point. I was simply looking for a non-trivial, purposeful exercise. Colour setting was the starting point, but I soon got into mouse control, the use of sliders, and a few more things besides. It was a less ambitious task than the first, and that had gone astonishingly well, so I was full of confidence. In the first version I set up a 4 * 4 set of cells to display the colours, and gained familiarity with Box, Bar, and Set Paint commands, with a few irrelevant explorations of things like patterns and borders. Then I needed three sliders for adjusting each of the Red, Green, and Blue colour settings, and though I tried using the supplied VSLIDER command, I soon decided to do without it. The supplied demo slider programs work, but I found the behaviour of the VSLIDER and HSLIDER commands a bit unpredictable when I tried to apply values of my own to the position, size and total parameters. (I must be misunderstanding parts of page 104.) Then I got into using the the Zone commands : Reserve Zone, Set Zone, and Mouse Zone. Why wasn't there something like this in earlier Basics? So often in the past I have needed to know if the Mouse was clicked within a given box, and have had to use a procedure to determine when the mouse is clicked, the x and y values of the pointer position, and whether that position lies between given pairs of x and y values. The Zone commands make it unbelievable easy. Say you want to set up a column of ten boxes, and then want to know which of them is selected by a mouse click. Reserve Zone 10 For i = 1 TO 10  x = 20 : y = 10 + i*20  Box x,y to x + 40,y + 16  Set Zone i,x,y to x + 40,y + 16 Next Z = Mouse Zone Z returns the number of the clicked box. With this tool, the task was easy. Click on a colour you want to adjust, and then on any of the RGB values that need changing. As you click, the colour changes, right before your very eyes. I know, you've seen it all before - but it was a useful and satisfying exercise. I am particularly pleased with the final touch. At the end of each session, all settings are stored as a single string in a temporary file in the exact format required by the Amos Palette command. It can very easily be loaded into any other program, or, of course, the palette program itself can be used as it stands as an Accessory within any other program. It's powerful stuff.  Task 3 I moved directly on to a much more compact Deluxe Model of the Palette program, including swapping colours and setting ranges of colours (like the DPaint colour tool, for example). It handles 4, 8, 16 or 32 colours, which has given me a chance to try out some interesting equations to determine the size and position of the displayed colour samples. For this version I made the significant addition of having the colour gadget occupy its own window, so that when the tool has been used, it disappears, and whatever was behind it is redisplayed. So I had to explore at least WindSave, WindOpen, and WindClose, and also looked into things like Window, WindOn, WindMove, WindSize, Title Top, Title Bottom (nice ideas), and Border. One by one, more and more Amos commands were ticked off the list.  Task 4 - Requestor Box The Zone commands were so easy to use that I couldn't resist the simple task of designing a requester box, also in its own window. I now have a procedure which carries a prompting message and two choice texts as its arguments, and produces :  ---------------------------- | Prompting text | | ---------- ---------- | | | Choice 1 | | Choice 2 | | | ---------- ---------- |  ---------------------------- Some nice arithmetic was involved in having the exact location of the elements determined by the relative lengths of the three messages. It was all too easy, and so I took the opportunity to explore various fancy effects with a few more Amos commands such as Get Fonts, Window Font, Shade and Pattern, and to look more closely at the similarities and differences between the two text placement methods "Print At(x,y)" (text as text) and "Text x,y,t$" (text as graphics).  Task 5 - Piano Keyboard This was all fine, my learning was making good progress, and I looked for something different for the next task. Sound and Music was an untouched area, so I decided to draw a piano keyboard, and write a program to play any note which is clicked on, until a "Quit" signal, and then play back the entire tune which has just been "composed". This task turned out to be much more demanding, and one or two problems have yet to be solved. Drawing the key board is easy - just a series of black and white "bars" of suitable size and position. I use "Set Zone" for each key to determine when it is clicked, which presents a problem because of the relative position of black and white notes. Page 173 of the Guide: "Note that ZONE only returns the first zone at these co-ordinates - it won't detect any other zones which lie inside this region." But half of each black note zone lies inside two white note zones, and I still haven't found a good solution to this. My current version has the white zones limited to that part of the keyboard which lies between the near edge of the black keys and the near edge of the white keys, and if you click on the white bits which lie between the black keys you get no response. I'll have to do better than that. The Play command produces a tinny sort of sound, but it can be greatly improved by using the Shape command, if you can handle it. I borrowed a patch from the Guide to get a reasonably piano-like sound. An array is set up for storing the set of notes as they are selected, and those notes are later played back in sequence. The PLAY command is at the heart of it all, with its three arguments [voice,] pitch, and delay. "Delay" is "silence between notes", and I haven't yet worked out a way of controlling the length of the notes themselves, assuming it's possible. Until I can do that, there is little chance of producing anything resembling real music, but I'll carry on exploring.  ==================== That's it. I've said what I set out to say. I hope I have given some further idea of what it's like to those of you who haven't yet tried Amos, some encouraging ideas to beginners, and at least a sense of friendly familiarity and shared pleasures to those who have already gone a little further.  (( 27 )) (( 27 )) (( 27 )) (( 27 )) (( 27 )) (( 27 )) (( 27 )) (( 27 ))