Creating user friendly programs (1)
-----------------------------------
by Steven Flintham
------------------
The screen layout (1)
---------------------
This is the first of a series of articles (and it might be the last!)
about something I feel really strongly about - the user interface. There
are hundreds of programs around in the public domain for the 8-bit Acorn
micros which are completely ruined by pathetic user interfaces (in my
opinion anyway!). I have a friend, who shall remain nameless, who writes
programs that work perfectly but can be extremely hard/irritating to use
because of an appalling user interface.
A key element of a user friendly program is the screen layout. It doesn't
take too much effort to give your program a professional finish, and it
makes the program much more pleasant to use. This article is accompanied
by a BASIC program called "Example" which illustrates one style of screen
display.
The style illustrated is possibly the most appealing form of 3D display
which can be done on ANY BBC - although I'd love to be proved wrong! It
involves rectangles which have an offset "box" behind them to give the
impression of a simple "shadow".
The program shows the principle clearly enough, but an explanation is
never wasted! The main body of the program is just a call to the
procedures explained below.
PROCdisable and PROCenable are just there to enable and disable the cursor
and ESCAPE keys - something I might whinge about later in this series of
articles! PROCinit just sets up an error handler - there is no need to
initialise variables etc in this program.
The first really interesting routine is the function FNgxr_present. This
can be used to detect whether an Acorn Graphics Extension ROM (GXR from
now on!) is present and enabled. If you are using a Master or above, this
will always return TRUE as the GXR is built into all Operating Systems
above and including 3.20. The function should be called with a blank
screen and as it corrupts the screen, a mode change or CLS should be done
afterwards. It works by drawing a circle at the centre of the screen using
a GXR command, which will have no effect if one is not present. It then
returns TRUE if the pixel at the centre of the screen is non-blank -
something which will only happen if the GXR is present. The result of this
is assigned to the global variable gxr%.
PROCbox3d needs this global variable to be present - if you want to
"borrow" it for your own programs and you don't want to bother with the
GXR detection routine, you can just set gxr% to FALSE or remove the code
in this procedure which refers to GXR. I used a global variable because I
thought that in a long program, you don't want to have to pass a flag to
PROCbox3d every time you call it. It takes eight parameters. The first
four are the coordinates of the bottom left and top right corners of the
box surrounding the box AND its shadow - nothing is drawn outside them.
The next two parameters are colour codes (as used with GCOL) which
determine the colours to be used - experiment with them if you're not
certain, but remember that the colours will vary from mode to mode.
The final two parameters are used to place a text string centrally within
the main box. The first is a text string, which can just be "" if no text
is required, and the second is the width of a single character in the
current mode. This can be found by (actual x resolution/characters per
line)*8, but the values are listed in the procedure anyway. For the sake
of completeness, here they are again:
Mode 0 - 16
Modes 1 and 4 - 32
Modes 2 and 5 - 64 (although I really wouldn't recommend using this
procedure in these modes - they're a bit "chunky")
PROCrect_gxr and PROCrect_nogxr both draw solid rectangles in the current
colour. The first uses the GXR for that slight turn of speed, while the
second uses the time-honoured method of drawing two triangles.
Incidentally, does anyone know how to produce a general-purpose non-GXR
version of this routine which will work with GCOL 4? I've tried several
times in the past but the triangles always overlap and an inverted line
appears down the centre of the rectangle. This doesn't affect this
program, but I have a couple of other ideas which need something like
this.
PROCoutline_rect simply draws an outline "box" - it doesn't have a GXR
equivalent, as the GXR only supports solid rectangles.
You might have noticed the reference to ANY BBC above - there is a nice
style of 3D which is sometimes used on the Archimedes which relies on the
availability of grey shades - if you've seen pictures of Impression in any
magazines, you'll know what I mean. It looks a lot better than this method
if it's done carefully, and it can be provided (I think!) on the 8-bit BBC
by using a colour mode (such as mode 1) on a monochrome monitor. I haven't
tried it yet, but if there are enough people with monochrome monitors,
TV's (you can just turn down the colour on a colour set) or add-on boards
(like the SPX or Chameleon boards) to allow analogue RGB who could use
this technique (I'll judge it from the results of the questionnaire), I
might consider trying it. The only problem is, of course, that users of
colour monitors will get strangely-coloured displays - however, if you're
writing a program just for yourself, it doesn't matter - and if you're
feeling really professional you can always add a configuration option
which will redefine the colours to give a flat but non-confusing display
on colour screens.
Accompanying this article are also two PD fonts - if you have a Master,
you can just *EXEC them - everyone else will have to mess about with
*FX20,6 and then fiddle about with PAGE before *EXECing them. They are
definitely public domain, as I have got copies of them from several
sources. I can't credit the designers because their names weren't given.
Their filenames are: Bold0 (a bit over the top for a lot of text, but it
might be useful for headings), and NewFont (strange name, but very
readable - probably my favourite). Using them carefully could also help to
make your programs more presentable. If you're feeling advanced, you could
call them at various points within your program to allow headings in bold,
main text in a different font etc. Example 2 demonstrates this, but
remember that you'll still have to fiddle with *FX20,6 and PAGE before
running it if you haven't got a Master. Try something like:
*FX20,6
PAGE=PAGE+&600
CHAIN "Exampl2"
Note that Exampl2 uses PROCexec(fname$), which performs the equivalent of
*EXEC on fname$. This is done because *EXEC only feeds characters to the
VDU drivers when the program pauses for input. I know I could use *TYPE or
*PRINT, but there are subtle differences between these on various systems
(compare OS 1.20 and OS 3.20 - on OS 1.20, *TYPE just sends the file
straight to the screen but on OS 3.20, it displays all the control codes
in the |V... format). In case you were wondering, the bold font is called
Bold0 because it comes from a larger collection. I'm not sure if the rest
of the collection is PD (I have copies of these two from several sources,
so there's no doubt about them...), but if it is I will send the other
fonts to 8BS.
Anyway, that's it for now. The next article (if there is one!) will
probably concentrate on creating a nice mode 7 display.
Editor's note:
Members who own BBC B or B+ machines who are interested in obtaining the
Acorn Graphics Extension ROM may like to note that one was advertised for
sale in Issue 20. Then again, a second-hand Master 128 was also
advertised, and there are thousands (well, nearly) for sale second-hand
quite cheap these days, which would make loading fonts in a lot easier as
well.