I'm overdue an update so here we go.
I've been spending parts of the last week or so working on a GL 3.x port of Quake 2. This was not something I'd intended to do, and it's probably not something I'll release, but it is functionally complete and I've done a full run through the game using it. The main purpose behind it was to get some practice in a relatively safe environment with some of the newer OpenGL features.
I still think that much of OpenGL is quite insane, but at this level most of the more objectionable parts go away - even dynamic vertex buffers actually become usable and well-performing rather than an ill-conceived pile of junk. I'll probably continue on and off with some more GL 3+ features (VAOs, separate shader, explicit attribute binding locations) as it's good exercise to shake oneself out of one's comfort zone a little and to get a different perspective on things. It also gives me a large block of working code if I ever decide to lift over some of it to RMQ as options.
A large portion of time went into the Dreaded Clipping Bug. I now have a fix that works in maybe 99% of cases using some code stolen from Quake 2 - a grand total of 3 characters! It involves a subtle but definitely noticeable physics/movement change, however, so I need to work out some further details on it before I can call it satisfactory.
The clipping bug itself comes from a false positive detection of the case where the physics code needs to check for a player going up a step; I am now absolutely certain of that. What I'm also certain of is that it's a bug from id's original Quake code as I've reproduced it in maybe 5 or 6 other engines (and have also reproduced my fix for it in those too).
The fix? Find the call to ClipVelocity in SV_FlyMove and change the last parameter from 1 to 1.01 - that's all. But like I said, this changes general movement in a manner that feels closer to Quake 2 than it does to Quake, so it needs some further tuning before I can feel totally happy with it.
I've also done some work on reducing the CPU load of RMQ's QC, and have found a case where a SV_HullPointContents call can be replaced with a faster path. As this is a fairly common case it translates to a good performance increase. That's just a matter of detecting if we're checking hull 0 and num 0 and if so sending it through Mod_PointInLeaf instead (as hull 0 is the drawing hull replicated as a clipping hull it should work out as the same result, but runs a good deal faster).
That's about all for this batch of work.
Wednesday, March 21, 2012
Wednesday 21st March 2012
Subscribe to:
Post Comments (Atom)
5 comments:
That's pretty interesting stuff about the clipping bug. I hope you're are able to get it squared away. I really liked the movement in Q2, though it's definitely not appropriate for Q1.
Speaking of...the other day I was really craving some Q2, but the tragically few source ports available are not very good. I was thinking to myself "if only there was a DirectQ for Q2"...a little later I found that there was. I tried it out but it really wasn't what I was looking for (I realize it's not some official big project).
IMO GL rendered Q2 looks like trash. Software rendered Q2 looked great. Unfortunately I can't run in that mode at 1080p on my rig for several reasons (incorrect FOV, AMD artifacts and crashes, etc.)
Sometimes I wish Carmack would just spend 30 minutes and tweak these old games for new hardware :(
GL Q2 mainly looks like rubbish because it trades off a bit of precision in it's textures in order to get some extra lighting range. Result is that textures look washed out and a lot of the colour information is lost - basically anything over 127 in any of the colour channels gets clamped.
It also rather agressively downsamples many textures to make it run well on the 8mb Voodoo 2 cards of the day (which had 4mb framebuffer memory and 2mb dedicated per texture unit).
Neither of these are needed on modern hardware; in fact as soon as the original TNT came out they had already become obsolete. We had proper unified video RAM so there was no per-texture unit limit, and we had the ability to do a 2x modulate so we could use that instead of losing the bit of precision.
Other issues were the way it clamped texture sizes to 256x256 (Voodoo 2 again) and it's incredibly bad dynamic lighting implementation.
The Q2 code I'm playing with now is OpenGL and I've no intention of making radical changes to it (like removing or toning down coloured lights, for inst), but I have resolved all of these and - in fact - it also uses some ideas cross-pollinated from my D3D11 code.
It's also incredibly fast.
It's also incredibly unfinished too - video modes are one area where Q2 really didn't work out too well, and that needs to be addressed, for example.
Some day I may release it as some kind of experimental thing, but for now it's not high on my priority list.
3.x Core profile or compatibility? I'm interested in looking at a GL3 Core profile renderer for Q2. (Actually all of the quakes :) )
Compatibility for now; I may go core with it as time goes on but compatibility makes porting in stages easier. The only non-core stuff really left is some client-side arrays for some objects (beams, sprites, nullmodel) though, plus a downlevel version of GLSL.
Compatibility definitely makes porting easier. Going core with an SDL project also means going to SDL 2.0, which is still not totally stable/problematic. :/
Post a Comment