A quiet day with not too much done. IQMs got alpha support and torch model animations got fixed up a little (they now use the correct animation intervals from the MDL file, and a missing last frame in each animation was restored). Also fixed up fence textures, so I think - with the exception of the static entities bug I mentioned previously (and which I still haven't a clue about the cause of) - that makes DirectQ more or less ready for RMQ support. There are still some things missing, such as some QC extensions, but while RMQ uses them they're not mandatory.
It is however fair to warn that in it's current state DirectQ is not actually a good engine for RMQ. The main problem is with lightmap handling; while DirectQ is much better at this than GLQuake ever was, it's still too slow for RMQ requirements. That needs to wait until I move to D3D11 and put lightmaps on the GPU. Average performance is quite similar, but when lots of lights start going off DirectQ can become quite jerky owing to delays in uploading new lightmap textures to the GPU (the RMQ engine doesn't need to do this so it doesn't get these delays).
In common with the RMQ engine it also suffers quite badly from a fairly heavyweight and sluggish progs.dat and from Quake formats (in particular the BSP format) just not being built for this kind of heavy load.
Friday, February 3, 2012
Update - 2nd February 2012
Subscribe to:
Post Comments (Atom)
3 comments:
FTE has an early implementation of a JIT for QC, just converts qc opcodes to x86 opcodes at load time. there's lots of space to optimise it more though.
the abundant use of floats is what annoys me the most about qc.
(it doesn't support all the extra opcodes that fte supports, but generally runs vanilla progs well enough, although its also not well tested).
What it does show really well though is just how expensive function calls are.
RMQ uses gyro, which is really quite heavy in function calls and field references and stuff, and fteqcc doesn't know how to optimise any of that.
If I were to write fteqcc from scratch, it would be tree-based, which would be much better for moving things up and down the nodes (like reading self.foo and moving it upwards so its result can be used multiple times, instead of being recalculated for every single read).
There's a few gyro functions that would really benefit from some proper inlining.
I notice that pointcontents is called in at least 3 places per entity. At least one of those could be cached instead, and recalculated only if it moves (the Gyro_RunPhysics one). That might give a noticable speedup, especially for all those ents which are not moving at the time. Should result in 1/3rd of the calls to pointcontents even for monsters that are walking around.
Also the engine has its own waterlevel/watertype fields which could possibly be used instead, which would of course avoid that bsp walk entirely.
Regarding RMQ's vm, consider counting the runaway loops only on op_goto/op_if/op_ifnot/op_call - removing that conditional branch might help a fair amount.
A JIT for QC is something I had thought about, and I have been suspicious about gyro for a while (do all entities even need to use gyro?)
Feel free to optimize the gyro QC code MH, it is basically dormant and unmaintained since Quake Matt left the team/went and did whatever he does now. Basically projectiles and players/monsters need to be Gyro entities, or most of them. This is mostly done for increased damage feedback (you can blow monsters away with weapons) and it will be necessary once we go over the underwater combat stuff - projectiles having water resistance etc.
None of the qc coders really focused on Gyro for a long time, and if you can optimize it at the root (in qc) then go ahead.
Post a Comment