Now if you load the templates using the Wimp Extension you must specify
sprites% as the sprite area (not +1 as for the wimp sprite pool)
Your program must not load sprites for opton/optoff, radioon/radiooff
into the wimp sprite pool because the user will likely have the ones that
they want loaded, and will not apreciate having them replaced, however if
you must use non-standard versions
you may load them into your private sprite pool though this is not
recomended because your application will look out of place with the rest of the desktop.
You must not use alternatives for any filer, device or application icons.
(Even in your own sprite area) You must not include the default versions
of any sprites. This is because:
a) Often only a low resolution version is supplied so VGA monitor users
have to re-load the ROM sprites.
b) The user may have loaded their own custom versions of the sprites
c) The sprites are already loaded, re-loading them causes duplication
and results in memory wastage
If possible your task should re-load it's sprite file whenever there is
a mode change. Whenever there is a mode change the WIMP broadcasts
message number &400C1 (Mode_Change) when you recieve this you should
read the new mode eig value and load whichever sprite file is applicable
The code to do this would be:
SYS "Wimp_Poll",,block% TO reason%
CASE reason% OF
WHEN 0
...
WHEN 17,18
IF block%!16=&400C1 THEN
SYS "OS_ReadModeVariable",-1,4 TO ,,x%
SYS "OS_ReadModeVariable",-1,5 TO ,,y%
IF x%=1 AND y%=1 THEN OSCLI "IconSprites <App$Dir>.!Sprites22"
IF (x%=2 AND y%=2) OR (y%<>x%) THEN OSCLI "IconSprites <App$Dir>.
!Sprites"
ENDCASE
It is also necessary to re-load the sprites into the private sprite area
not just the wimp sprites. After the mode change the wimp sends redraw
messages to all open windows, so the sprites will be updated on screen
without any intervention from your task.
Some old applications such as some old applications from DoggySoft, Black
Hole 2 and various other programs have thier logos stored as a large sprite loaded into the wimp sprite pool. This must not be done, on pre Risc PC
machines you cannot easily see how much memory is being used by the wimp
sprite pool. I typically find that about 300-600k is used up!!! This is
largely because of large company/program logos and duplications of ROM
sprites.
Windows
-------
It is unfair on users if in each application they use there is a completely different window that performs a standard function like changing a font,
printing a file etc.. If possible you should use the templates described
in the RISC OS style guide, from Acorn.
Default action buttons & action buttons: These should not have a button
type of menu, this makes the button slab in whenever the pointer is over
them. This is confusing and looks awful. You must only ever have one
default action button per window, otherwise things get confusing for the
user.
All new applications developed should use the 3D look, if you must support
RISC OS 2 then you can use the Wimp Extension or Interface manager or
you can supply 2 sets of templates, one 2D one 3D. Your program should
also check if the 3D byte of CMOS RAM is set, RISC OS 3 users may not wish
to use the 3D desktop.
Outline fonts
-------------
You aren't supposed to use outline fonts in windows but many people do.
Outline fonts mess up if the mode is changed from an EGA mode to a VGA
mode, their height either halves or doubles. You must NOT use outline fonts on a windows title bar, this severly messes up and is severly hissed at by Acorn. You can use outline fonts in your menus but is is quite complicated to do and is best avoided.
If using fonts you should stick to standard ROM fonts, you can be sure
that everyone has these. I recomend that you only use a few different type
styles.
For body text use Homerton.Medium at 12pt
For headings use Homerton.Bold at 24pt
For large titles use Trinity.Bold ate 46pt
For writeable icons use Trinity.Medium at 12pt
Texture mapping
---------------
On the Risc PC is you supply a sprite called tile_1 in your private sprite
area or in the wimp sprite pool then this will be used as a tile in all
your windows backgrounds. If you want tiled window backgrounds on RISC OS
3.1 or 2 then you must supply the sprite and do the tiling in your redraw
procedure. This is slightly tricky, an easier way to do it is before you
create any icons in your windows create one icon displaying the tile
sprite and then copy it left, right up and down until the window is fully
tiled. This means that the WIMP handles all the redrawing of the window and
makes the template file a bit larger.
An example of this is in our disc magazine, Risc Mag's control panel a grey
version of the logo is tiled in the background.
Error Boxes
-----------
You should if possible use the standard WIMP error box. If you require a
custom error box then do not use those provided by the Wimp Extension,
make a copy of the ROM error box template into your own sprite file and
customise that. To use this file you should open the window in the center
of the screen and then call Wimp_Poll in the same procedure, (Not your main
polling loop). The mouse should also be restricted to the window.
The error box supplied with RISC OS 3.5 (Risc PC) is much much better than
the RISC OS 2/3 one. In some of our programs, we have duplicated this
window and use this as a report box. I advise that you do the same if at
all possible.
Star Commands
-------------
If your task is a module then you may wish to provide star commands to
perform various functions. These commands should be provided so that
other programs (and programmers) can interface directly with your task,
there should always be an equivelant way of carrying out the functions
provided from a desktop interface. Users should not be expected to use the
command line, RISC OS is a WIMP operating system, the user should not have
to leave the desktop and the command line should be alienated from them
as much as possible.
Games
-----
When writing games I would like to ask you not to do anything stupid. Do
not try to speed up any hardware components such as the ROMS, it was
possible to speed the ROMs up from 4 to 8 mega herz but on RISC OS 3 this
call was made invalid and many games stoped working. When you need to
write to memory, validate the addresses first, no not assume that, for
example, screen memory will always lie at &8000. It is likely to be moved
on new machines.
You should make your game work in an EGA mode, like 12 or 15 and a VGA mode
such as 28 or 32. You should check to see if VGA modes are valid each time
the game runs and provide high resolution versions of the graphics and
have two versions of the code because the pixel and OS unit resolutions
are different. It is recomended that you use Acorn's Games modes module,
this provides both VGA and EGA modes that have the same X and Y sizes in
OS units so you do not have to rewrite your code for VGA and EGA modes.
If possible your game should run completely in the desktop, if this is not
possible then it should at least install to the icon bar and alow the users
to set the game options from here before clicking on the icon to start the
game.
System Sprites
--------------
If you must use the system sprite area (You don't know how to use the SWIs)
then don't try to load sprites directly into memory. It is VERY unlikely
that the user will have any sprite memory set up, so either use the star
command
*ChangeDynamicArea -SpriteSize xxxk
or the SWI
SYS "OS_ChangeDynamicArea",3,amount TO ,bytes%
amount is the amount of memory you require, in bytes, bytes% is the amount
of memory being allocated. If this is insufficient then report an error.
With the star command the values are in kilobytes, using the SWI the values are in bytes.
You must clear the sprites away when you are finnished and free the memory
used. If your program is multi tasking then you should put an alias on
then star commands *Snew and *Sloadso that no other program or user can
clear your sprites away whilst you are trying to use them. To do this you
can use the commands:
*Set Alias$Snew Error There are sprites still being used in the system
sprite area
*Set Alias$Sload Error There are sprite still being used in the system
sprite area
And when you are finnished, restore the commands using:
*UnSet Alias$Snew
*UnSet Alias$Sload
Configuration
-------------
Programs should never make assumptions about the configuration of a users
machine, and if they find it configured wrongly then they must NEVER
re configure it to suite their own purposes. They may however ask the user
for confirmation before they change any preconfigured values, make sure you let the user know exactly what you are about to do. The exception to the
above rule is if your program is, for example a start up managing
application, it may override the boot option to make sure it gets run, when being installed.
Reservations
------------
Most people are aware of Acorn's policy of name registration. Most authors
of PD software think that the policy does not apply to them. I will explain:
For every program you write you must register the application name, any
system variable and any file types it uses with Acorn, even PD programs.
TO make an reservation you should write off for a copy of the !Allocate
program from Acorn. You simply fill in a few details and then send the
file back and they check that your names are unique and allocate any file
types and then write back.
It is incredibly annoying to have several programs fighting over which of
them is going to load a file, all claiming that it belongs to them.
