Quake 3 qgl API

I'm sure having the qgl API made sense at some point in time (GL 1.x) however now it's just a pain for doing any kind of porting. The qgl API is a set of function pointers which are initialized by the renderer to point to the real gl API functions (or logging wrappers.) e.g. glClear() becomes qglClear()

I think the original reason for this was logging GL calls (a valid reason, at the time) and handling extensions. IMHO logging could be implemented easier using a GL tracing library (there are a few; Google) and GREMEDY_string_marker for renderer specific messages (begin of function foobar(), etc.)

Actually this is what Robert is doing for XreaL-ET branch, however it's not on the mainline branch yet. I think I'll cherry pick these changes over before doing more work on GLES2 for XreaL. Otherwise the qgl API is going to turn GLES2 support into a massive ifdef mess...

I am quite interested to see what kind of performance SGX can get out of a real VBO optimized renderer.

Mother Nature's a cold hearted bitch...

Unfortunately due to the EU airspace being closed because of the volcanic ash cloud I wasn't able to make it back to Helsinki; I ended up getting stuck in Hong Kong for a night (which was kind of cool; apart from the exceptionally expensive Airport Hotel.)

Yeah, I was lazy and got the closest place, optimistically thinking this might only last a day or two. Finally I decided to get a flight back to New Zealand rather than stay for an unknown period of time in Hong Kong. I don't even want to think about the number of timezones I've crossed in the course of this fiasco... I'm sure the jet-lag will hit hard.

Finnair are offering a refund for unused tickets (once they get around to processing it) so hopefully I will get at least some of my airfair back.

Oh, and if I never hear the words "final boarding call" or "passengers on flight..." again, it will be far too soon.