I am deeply unhappy about the current implementation of projection transformations, particularly where parallel projections are concerned:
It seems certain that the eye coordinates to screen
coordinates mapping required by parallel projection could be
done more efficiently and with less potential loss of
accuracy if it were hard-coded rather than set up as a
general matrix transformation. In fact I am very tempted to
abandon the whole idea of allowing arbitrary matrix commands
(especially GL_LoadMatrix) to affect the current
projection matrix. If projections could only be set up using
GL_Ortho or GL_Frustum, then client
programs would be protected from sticking their noses into a
potentially dangerous area, and much better internal
implementation would be possible.
With hindsight, I would have written the bulk of the library in C, except for a few key components such as transformations and low-level rendering functions.
This does not merely reflect a personal weariness of assembly programming. but also the fact that in recent months I have become more aware of how to help C compilers generate efficient code, whereas previously I simply blamed the compiler when I did not obtain good results: An experienced C programmer can do a lot to help register allocation, and minimise argument passing overhead and access costs to variables.
If a floating point library were available then it ought to possible to create a version of the module that does not use the FP instruction set (hence avoiding the overhead of invoking the emulator), yet uses floating point arithmetic internally. Unfortunately I do not have access to such a library, because emulation is the preferred software floating point system under RISC OS.
The performance improvement would be that the selection of hardware/software FP would be made once only, when the module was loaded, rather than on the basis of each individual instruction.
And finally, this project is self-evidently unfinished. Which is a pity, as I thought it looked quite promising.