Contents Previous chapter Next chapter

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:

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:

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:

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."9

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.

8  As per "1066 and all that."

9  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.

Contents Previous chapter Next chapter