Friday, September 10, 2010

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.


  1. So are you working on porting ioquake3 to use GLES2? It's just somebody asked about it on the Pandora forums, and obviously we'd all love to use your work.


  2. Hi Jonathan,

    Actually I spent some time working on XreaL-ET, which is based on the ioquake3 engine but including the recently GPL'ed Enemy Territory game play elements. It's backwards compatible with vanilla Quake 3 Arena, too.

    I have made enough progress to get it compiling against GLES2 and attempting to start up on SGX530 (Nokia N900), however due to differences in the GLSL language between GL2, GL3, and GLES I would need to write some pre-processor magic before being able to render anything.

  3. Definitely looking forward to this. Any word on adding mouse support? With USB host mode now available for the N900 I've got a mouse hooked up playing TeeWorlds (and others) whereby movement is done with accelerometer and look is done with the mouse.

    Makes for a seamless gameplay (and very portable with my mini mouse) :D

  4. Hi Oliver!

    I’ve found your Maemo port of Quake3 a couple of days ago. - Great work! After some minor problems with installing the pak-files (most likely because I’m a total Maemo-noob) everything runs beautiful now!
    I’ve been tinkering on a Quake3-based mod called “Monkeys of Doom” for quite a while and with time that mod has grown to an almost full-blown game. There is already a mobile version of it for older (s60v3) Symbian phones (N95, N82) with amazingly good playability, and one for the Motorola Milestone (probably running on some other Android devices too). Both are based on independent portings of idtech3, the first was made by Olli Hinkka ( ) , the second by Roderick Colenbrander ( ) .
    What I wanted to ask is if you would help me with a Maemo-version?! I’ve tested the Monkeys of Doom game-content with your port already and think both are working really cool together! Here is a short video: . I don’t think it is that much to do. Main issue is that the game loads from a different “base”-folder than Quake3 to install both games independently. If you want, I can send you some Monkeys of Doom stuff to test it yourself and see if you like it...

    Best regards & keep up the good work!

    (Sorry to post this as a comment. Couldn't find a link to pm you.)

  5. Hi Wilko,

    It looks like you have a pretty cool and fun game there. I'd be willing to help in my free time on the programming side of things.

    At the moment I'm on vacation and I will be basically offline completely for approximately the next 6 days. It's cool to see people building ontop of my N900 ioquake3 port. :-)

    Btw, I have thought about some better control systems since a friend of mine showed me an iPhone game. I feel that while the accelerometer has some inherent neatness to it, it can become difficult and frustrating to use...

    When I have some time I plan to actually write some code for this, but the basic idea (stolen completely from the iPhone game; I don't remember the name) is you have two ThinkPad style dots drawn on the screen. One is used for movement (forward/back/left/right) and the other aiming (with the help of an aiming assist.)

    The "control dots" (for lack of a better name) are contained within a finger-size circle, therefor you don't have to put your finger all over the screen and obscure the view.

    Regarding the aiming assist, well, currently it sucks. I need to do actual evaluation of the trajectory of projectiles (e.g. rockets, plasma blasts, etc) so that your rocket actually hits where the target will be, not where he was when you fired. Shouldn't be too hard.

    For weapon selection I think something like the horizontal scroll bar (for example on any modern laptop) would work quite well.

    I would like to get to the point where (at least during game play) you only need the touchscreen. Keyboard could be used during the menu, or for die-hard WASD fans. :-)

    P.S. No problem about posting as a comment. I don't believe BlogSpot has private messages. I think you did send me a message on, which I read, but didn't reply to yet. (Lazy me. :-P)

  6. Hi Oliver,

    thanks for the quick reply and for offering your help!

    One iPhone-fps with really good touch-controls (the best I know) is N.O.V.A.

    About autoaiming/autoshooting: I think that could indeed be a nice way to improve playabilty! There's a (not very well known) mod named "gotwalls" which does both pretty good already. Unfortunately it hasn't been updated for quite a while and supports only version 1.17 of Q3.

    Have a nice vacation!

  7. Hi Wilko,

    Yes, I just watched the start of the video (ridiculously slow internet here in NZ; I miss my cable connection) and that looks exactly like the game my friend showed me.

    I think that when I have some time, I will work on implementing a control system similar to this into the UI code (which is something I haven't done a lot of work with, but enough to be familiar with the code.)

    Btw sorry about the late reply; just got back this evening.

  8. Hi Oliver,
    another Maemo-noob question has come to my mind: Does the N900 support multitouch? I think that would be necessary for this kind of controls...

  9. Oh, you're right. This totally slipped my mind. We have a resistive touchscreen on the N900... therefor I would have to sacrifice one of the controls (aim/move) or rework the controls somehow...

    I know that it's possible to detect that a second finger has been placed on the screen, because you get a huge delta on the MotionNotify event (actually you can use this on a standard N900 to quickly flip through the desktop screens.)

    I think it would be possible to have a separate "fire" button (less awkward than using the proximity sensor) in addition to the aiming pad (WASD movement would probably have to come from the accelerometer.)

    But this is not true multitouch.

  10. The controls of Quake 3 for Symbian s60v3 devices work really good! That port uses the (physical) d-pad for moving and the accelerometer for aiming. I think the combination of a virtual joystick and the accelerometer could work as well. (It shouldn't cover too much of the scene of course;-)

    Here are two videos demonstrating the playability of Symbian-Q3:

  11. Hi Oliver,

    Did you find time to test that autoaim-mod already? I had a closer look on it last night and think it would indeed be a great benefit for mobile gameplay. Unfortunately I still fail to adapt it to ioQuake3...