Thanks!
Just arrived at work, so can paste the details on the implementation i'd prewritten on my laptop now.
The UDGs are rendered using what i've internally called 2D Grid in my code.
In the 2D Grid the screen is divided into blocks, the number of which is divisible by 8.
So on the x-axis to have 256 blocks takes 4 pixels (1024/256==4), to have 128 takes 8 pixels (1024/128==8).
Every time an individual block is drawn a single pair of triangles (in a VBO) is reused. As i've used OpenGL ES, a lot of the work is done in the shaders, including the translation (position), aspect ratio correction and colouring.
The 2D Grid can be refactored at run-time to modify the block size (which configures the size of the stored triangles in the VBO) but still conform to a screen width in blocks that is divisible by 8.
So the 2D Grid code is used to render each UDG an array of 8x8 'blocks'.
In the case of a single 8x8 text character on the screen is drawn using UDGs, which in turn are drawn using 8x8 2D Grid blocks. Each of those 2D Grid blocks is 2 triangles in a VBO 'instanced' over and over again via the shader. So one text character on screen is 64*64=4096 blocks or 64*64*2=8192 triangles.
Lessons learned
As stated before this is my first demo and challenge entry, prior to this challenge I'd only ever fiddled with a recompiled 3D Cube sample from the Mali SDK and written the 'hello triangle' sample. Pretty much everything has been learned and done from scratch.
What I brought in from the fiddling i'd done with the previous stuff was some high resolution delta timing code, and some windowing set up stuff i'd done while building upon those two things.
I'm really happy in how i've seperated things. I've got a platform.lib which calls an app specific entry point for 'setup' and contains the things dependent upon O/S, like timing, input and handling windowing. The other library is stuff thats reusable code common to everything (I'm not calling this an engine.. as per this brilliant article someone linked on DBF previously
http://scientificninja.com/blog/write-games-not-engines )
I've chosen OpenGL ES as I do hope to be able to port code across to devices like the Raspberry Pi and have ideas for some interactive stuff on tablets.
However after hitting performance issues with the onboard intel card my motherboard had, and discovering most OpenGL profiling tools require firstly, better cards and secondly full GL. I've decided the future lies in making a 'normal' GL version of my platform lib for desktop development to take advantage of profiling tools in future, and so that in future challenges more people might be able to actually run them! (I will try to stick to the methods available in both desktop OpenGL and OpenGL ES 2.0 to do this though).
As far as other performance goes, I could have probably gained some by using a VBO list per UDG and reusing that.
Going forwards, i've learned a lot, and the pixel font rendering code particularly will help if i want to write a console interface or simply show an FPS counter.
