Just been crushing some ATI bugs lately; their OpenGL driver still sucks. Well, it doesn't really suck, but in general it's the case that if you can't do something in D3D then you really shouldn't try to do it with ATI.
Meanwhile, here's some notes I've been putting together regarding requirements for running RMQ stuff. The engine pre-release is still on track for some time next week, and there will likely be an updated version of these notes included with it. These are just to give anyone who's interested in adding support a head-start.
____________________________
Without saying too much about stuff that hasn't been publicly released....................
What's been released in the 2 demos so far is only the very small tip of a very large iceberg, and really doesn't indicate in any way the full extent of what's going on.
What RMQ really needs most right now is big map support. This is absolutely mandatory and engines that don't have it will fail to load most RMQ maps. There is as-yet unreleased content that is right on the absolute maximum limits for some items so this needs to be robust and comprehensive. Think warpc and then ramp it up some.
A few DP extensions will be used but will not be absolutely required (yet, at least). Supporting them will make the game better though. DP_QC_STRFTIME is used on occasion but nothing will break if you don't have it. DP_SV_CLIENTCAMERA (not called by name in the DP source! search for clientcamera) may be needed later, but not until after the next demo is out. FRIK_FILE has been asked for and the engine has it now but it's not used yet. There may be more.
Alpha-masked texture (what I've been calling "fence textures") support isn't necessary but these textures are used in maps and they'll look better with it. They only need to be supported on brush models.
Alpha surfaces will be needed; I don't think there's any in the upcoming demo map, but they are used elsewhere. Sorting these by model is not enough, they need to be sorted by surface for RMQ.
Fast handling of sprites would be a very nice thing to have.
There's going to be a lot of horde combat and big open areas with complex geometry. Anything that renders these fast is good. DirectQ has a R_RecursiveWorldNode replacement that uses maybe 5% the CPU that ID Quake's does, so that might help (it's easily adaptable to C and doubled framerates in some places when ported to the RMQ engine).
If the maps which have already been released crush an engine then it doesn't stand a chance with the rest of this stuff. If the maps which have already been released run slowly on an engine then the rest of this stuff will crush it.
Worst-case polycounts so far were about 20,000 epoly and 30,000 wpoly, but this was on a fast-vised map. The RMQ engine can handle these counts (as well as everything else going on - sound, server, etc) at maybe 50-60 FPS on my NVIDIA GT230M so this is the kind of performance to be shooting for. Released content won't be this bad of course, so consider this an absolute upper limit.
The current QC is quite CPU-heavy; anything at all that can be done to optimize that is a good thing.
Full rotating brush model support is required. I don't think the "flicker fix" (look on Inside3D) is needed yet, but it will be in the future.
The map in the next demo will have a lot of dynamic lights and animated lightstyles by Quake standards. These are actually a quite essential part of the atmosphere, but even so, they're nowhere near as many as are present in unreleased maps. Work on the assumption that every surface in a scene is going to be dynamically lit (and there will be a lot of surfaces - the screenshots here give a good idea of the kind of complexity I mean). Fast dynamic lightmap updates are an absolute must.
Static entities, temp entities and beams limits all need to be increased. The RMQ engine effectively supports an "infinite" number of these (as in "until you run out of memory") so I can't give counts right now.
Skyboxes, fog and coloured light should be more or less standard by now. The FitzQuake fog standard is the fog implementation of choice and will give the intended result. Content will run without them, but you won't be seeing it the way the creators intend.
Lava and slime textures are intended to glow through fog.
The maps are designed with fullbright colours and overbright lighting in mind, so certain areas might look wrong if an engine doesn't support these.
The RMQ protocol is basically just the FitzQuake protocol with some minor modifications (angles and coords are transmitted as full floats); this may be changed more further down the line. Implementing the FitzQuake protocol now will be a good idea.
No CSQC requirements yet and the engine doesn't have it yet.
____________________________
That's about it so far.
Thursday, November 4, 2010
RMQ Support - Implementation Notes
Posted by
mhquake
at
12:02 AM
Subscribe to:
Post Comments (Atom)
3 comments:
A link to the map so I could test it would be great. PM me on I3D if you don't want to put it up publicly. :)
Post a Comment