Here's an interesting problem. By default Quake runs at a maximum of 72 FPS, and all physics, sound, input, rendering, etc can run no faster than this rate.
Now, it's common in modified engines to find a host_maxfps (or some variation on that name) cvar which allows the maximum to be adjusted. It's also common for to adjust this upwards in multiplayer.
However, a problem arises when someone who is primarily active in multiplayer uses a singleplayer map or mod, and has their max FPS set to above 72.
Because Quake's physics are framerate dependent, running at faster than 72 FPS in singleplayer causes things to start behaving really strange. Really really strange. This can be observed on the first elevator in e1m1, the first YA secret in e1m4, and practically anywhere else.
Sometimes it can even kill you - check out the elevator from the river up to the GA area in e1m1, for example.
This is obviously undesirable, but what's the solution? Decoupling the server framerate from the client framerate is one option, but that's fraught with danger. At the very least it would require extensive testing and mistakes being made along the way.
What I'm thinking here is to lock singleplayer games to a maximum of 72 FPS, irrespective of the value of the max FPS cvar. The problem is avoided, multiplayer fans can still set it for multiplayer games (and it's value won't be stomped over if they ever switch to singleplayer), and nothing gets broken.
Any opinions or feedback on this proposal are welcome,
Sunday, January 23, 2011
To 72 FPS or not to 72 FPS, that is the question
Posted by
mhquake
at
8:11 PM
15
comments
Monday, January 17, 2011
...And back to RMQ!
Today I've been back at RMQ as some bugs and issues came up which needed addressing. It's kinda schizophrenic but let's see how things go.
One was a crash bug when an MDL doesn't have a valid skin set, which actually did happen (by design) in one of negke's speedmaps.
Another was a cleanout and restoration of sanity to some FRIK_FILE stuff. RMQ is retaining the old handles-based filesystem, so this just amounted to adding Sys_FileOpenAppend and tidying up some functions a little.
The third was an upgrade of shaders used by the engine to full OpenGL 2.0 spec. Previously I had used the old GL_ARB_shader_objects extension, but there was some trouble on certain cards. I've decided for reasons of stability that if shaders are going to be used at all they should be used properly. If nothing else, GL_ARB_shader_objects is an old extension that has long since been superseded, and may lack proper compatibility and/or stability with certain hardware. Things just feel more solid and reliable this way.
If your 3D card doesn't support OpenGL 2.0 there is still a non-shader path, of course. GeForce FX users note: these cards will be forced to the non-shader path owing to their very poor performance with shaders (especially high-precision floats which are needed by the liquid shader).
Posted by
mhquake
at
9:39 PM
0
comments
Non-Power-Of-2 Texture Support
Just a few words on this. The differences are subtle but they do exist; a great example is the window in the Easy hall of the Start map. Unfortunately I haven't been able to get a screenshot that suitably demonstrates it (and JPG compression would wreck it anyway) so you'll just need to take my word for it.
The main one that you'll notice is that the stained glass lines are crisper and sharper, with no fuzziness. Colours also don't suffer from the "bleaching" that bilinear resampling causes.
Another advantage is that it saves some texture memory on account of not having to pad certain textures. This was necessary because the fuzziness I mentioned is a very noticeable artefact on 2D GUI textures in particular; compare the main menu image in an engine that supports padding with the same image in an engine that doesn't and you'll see what I mean.
Anyway, even though D3D does have better hardware capabilities checking than OpenGL, I've decided to err on the side of caution a little. Non-power-of-2 texture support is only going to be available on 3D cards that support Shader Model 3 and above (something that it seems impossible to check for in OpenGL... sigh). This means that the specific cards that caused problems in OpenGL (GeForce FX and certain ATIs from the same time) won't get them. I also create a texture and ensure that it's OK, just to be absolutely certain. This last was something I did in RMQ too, but OpenGL wasn't throwing any errors there either.
If you don't support non-power-of-2 textures you'll still go through the old paths, of course.
All in all, while it seems a shame to have to bring up the old OpenGL vs D3D thing again, this is definitely one area where D3D gives the programmer what he actually needs to properly implement a feature in a rational and predictable way.
Posted by
mhquake
at
12:16 AM
0
comments
Sunday, January 16, 2011
FRIK_FILE is done
This is deeply nasty code, but I've managed to bring some measure of sanity to it. Many things wrong with the original implementation, so strap in cos it's going to be a bumpy ride.
First thing was that DirectQ doesn't use the old handles-based filesystem that FRIK_FILE depends on (the main reason why it wasn't implemented before), meaning that I needed to either reimplement the handles system just for this, or rewrite it to use FILE * pointers. I actually did both, first of all a reimplementation of the handles system to ensure that it compiled OK and cohabited cleanly, then a rewrite for FILE *.
Secondly, and as anybody who's implemented FRIK_FILE knows, opening a file in append mode is messy. First it tries to open it in read mode, then if it succeeded it reads it into a temp buffer (allocated in the zone, with all the size limits that implies), then it reopens in write mode, writes out the temp buffer if necessary, then returns. Yuck. It surely wasn't that difficult to write a Sys_FileOpenAppend, was it? Anyway, switching it to FILE * restored a huge chunk of sanity there, and as a bonus I got Sys_FileOpenAppend for RMQ.
The end result is now MUCH cleaner (and therefore more maintainable) than the original, with the only piece of semi-mess remaining from that part of the code being the use of a -1 to signify a file open failure. Unfortunately that's a compatibility requirement, but on the whole it's Not Too Bad.
There's still quite a bit of ugliness (and dependency on ugliness from the original ID Quake) in the code overall, but I'm going to suck it down for now.
Posted by
mhquake
at
11:42 PM
0
comments
DirectQ Update - 16th January 2011
First update for a good while because I've been sick - swine flu is a total pain, but I reckon if I'm going to get it I'm better off getting it now rather than just before I'm due to go on holiday or something.
Anyway, while the rest of the RMQ team are working on the point release, and now that I've got pretty much all of the engine requirements for that done, I'm going to be picking up some slack with DirectQ. Obviously if an RMQ requirement comes up it'll need to take priority, but for now I'm taking a change of scenery.
This will also give me the opportunity to bring on some RMQ features into DirectQ, which is quite cool. These will include the long-awaited FRIK_FILE.
Hopefully it'll finally coalesce into Release 1.8.7; this has been some time coming, and was delayed towards the end of last year so that I could focus on RMQ (among other things) as well as nail down the final feature set that I need to bring on.
Some other changes worth noting:
- I've re-enabled non-power-of-2 texture support. This was present in an older version, but used a more compatible (but less functional) "conditional" support, whereby non-power-of-2 textures couldn't be mipmapped and had other restrictions. This version uses the less compatible version, but only where supported by your hardware. I also had this in the released RMQ engine, but it caused trouble with OpenGL drivers (and is the cause of the "white textures" bug some folks got). D3D is stricter about hardware support of features so it's safe to do in DirectQ.
- I'm going to bite the bullet and lock SP games (and MP games if you're running a listen server locally) to a max of 72 FPS. This is something I feel is necessary owing to the number of MP players who are used to running with a higher maxfps doing the same in SP games and then complaining about weird physics. It won't affect running with non-local servers, i.e. dedicated servers or someone else's listen server. I'm also going to lock it if recording a demo (for the speedrunning crew).
- Mouse input has been totally overhauled (again!) and is now considerably smoother.
- I'm reverting the default protocol to 666 (FitzQuake). The previous protocol experiments were fun for sure, but they did cause some incompatibilities, particularly with demos. The RMQ protocol will eventually become the new default, but that's nowehere near nailed down yet, so until then I've come to believe that it's not really suitable for use in a more general purpose engine.
The other main thing I was talking about towards the end of last year was D3D11. OK, sooner or later I am definitely going to make the move; that's a given, because hardware support for the older D3D9 features is eventually going to die out, and there will come a time where everybody (or at least everybody who would use DirectQ) is on a D3D11-capable platform. I'm still waiting for the tipping point to come, but I suspect that it will happen (or start to happen) over the next year or two. Until then, my previous talk of going to D3D11 for 1.9 was a little premature. I may yet do a Quake II port as a learning experience though.
Posted by
mhquake
at
8:50 PM
4
comments