Analysis of Requirements

1 Conclusions from research

Many of the graphics libraries I examined had extremely talented programmers behind them and produced impressive results. However my research has uncovered a number of issues that need to be addressed in any future attempt to write a RISC OS graphics library. In summary, these are:

• Where optimised ARM code is used, future maintenance is an issue. Ideally, low-level code should not be directly incorporated into client programs.
• A massively integrated game engine project is unlikely to gain as widespread acceptance as more generalised graphics rendering library would.
• A language-independent API is important to allow developers the freedom to choose their programming environment.
• Good documentation, tutorials and an example client application are needed to encourage developers to use a graphics library.
• It is important to get a basic graphics system working, with solid foundations, before spending ages on sophisticated rendering options. In any case, advanced rendering may prove impractical on current hardware.
• Support for older ARM6/7 based computers is important, because these still form a substantial sector of the software market. This implies adjustable rendering quality.
• On current hardware, any graphics rendering library must employ a significant amount of hand-written ARM code, to achieve a worthwhile frame-rate. Preferably the floating point instruction set should not be relied upon.

2 Proposed solution

Having looked at some of the problems surrounding graphics rendering on RISC OS, I shall outline the design of a new graphics library that addresses the points noted above.

Unlike previous statically-linked graphics libraries, it is desirable that mine should be shared between multiple programs. The manner in which shared libraries are traditionally provided under RISC OS is as modules. Taking this approach gives a number of advantages:

• Given more than one client program, a module implementation saves memory by avoiding code duplication across multiple applications.
• Graphics hardware can be supported transparently in any compliant program, simply by replacing the extension module with hardware drivers.
• Other developers could write compatible modules that implement the same set of SWIs, allowing users to choose their favourite graphics renderer. Alternatively, the programming community could co-operate on improvements to an open-source graphics library, benefitting everyone.
• The SWI interface provided by modules is language-independent, allowing use from high-level interpreted languages such as BASIC.
• Versions of the module optimised for different classes of ARM processor (e.g. those with FP co-processors) could be compiled.
• Users could upgrade their graphics library by replacing a single module. This would instantly improve all compliant programs without individual modifications.
• Keeping optimised ARM code inside modules is a Good Thing⁸, because it means that subsequent compatibility problems can be fixed centrally rather than having to decompile hundreds of archaic programs.

In fact, there is a precedent for producing different versions of a module, each tailored to a specific CPU class. The AMPlayer module is an MP3 player which comes in flavours optimised for ARM710/StrongARM (long multiply), ARM7500FE (FP co-processor), and ARM610 (no long multiply). Decoding MP3s is similarly processor-intensive to graphics rendering, and therefore requires highly optimised ARM code, where every last bit of performance counts.

Writing drivers for graphics cards such as Viewfinder would simply be a matter of producing a module that re-routed those functions accelerated in hardware; this change would be completely transparent to any client programs. Because most of the rendering functions required by a typical game will be implemented by the module, the amount of direct drawing necessary (if any) ought to be reduced to a level that is an acceptable load.

3 Deciding on an API

Rather than designing my own API for the graphics library, I decided to adopt the functional interface of Silicon Graphics' OpenGL. (For more information on OpenGL refer to section 3 of the previous chapter.) This decision was influenced by a number of factors:

• OpenGL is a true multi-platform standard, unlike Microsoft's DirectX, for instance.
• Good APIs are difficult to design - by adopting an established interface, I am free to concentrate on the RISC OS-specific implementation issues, and on the fundamentals of efficient graphics rendering.
• There is a large amount of high-quality documentation and tutorial material already available on OpenGL. This is a resource worth exploiting.
• An OpenGL implementation for RISC OS will make the task of porting graphics-oriented software from other platforms much easier.
• Because OpenGL is a relatively low-level rendering API, it is likely to attract more general support than a highly integrated game engine such as TAG.
• OpenGL lends itself well to being scaled down for slower ARM processors (it degrades gracefully), since advanced rendering features can be ignored by an implementation.
• There is a body of information available indicating which OpenGL functions are commonly used by programs and those that might reasonably be omitted from a reduced implementation.

Many of these points are also made by Lee Johnston, in his exploratory document 'Towards a 3D Graphics API / Engine for RISC OS'. [21]

The negative side of adopting a foreign graphics system is that aspects of its design may not be optimal for implementation on RISC OS computers. Some of the issues arising from this are discussed in the next chapter.

At this point a sceptical reader may ask "why not simply turn Mesa into a RISC OS module, thus giving a shared OpenGL implementation?"

As originally envisaged, modules were to be written in compact assembly language. The average size of a relocatable module is around 30KB, with the largest modules in ROM (such as Internet and WindowManager) being only 100 KB-150 KB.

At more than 1229 KB, Mesa would be the largest RISC OS module in history. Putting such a large C library into a module would be contrary to the guidelines in the Programmers' Reference Manual, which state that (amongst other qualifying criteria) "A major piece of software written for RISC OS should only be designed as a module if... it is small enough."⁹

Claiming large chunks of relocatable module area tends to cause serious heap fragmentation - even when the RMA contains large free blocks it can be difficult or impossible to reclaim the memory for other uses (e.g. for applications). In any case there is an upper limit of 16 Mb on the RMA size.

⁸  As per "1066 and all that."

⁹  There is a ROM module containing the ANSI C library, but this is not really comparable to Mesa since it is used by all C programs and it is only 35 KB in size.