Re: RANT: What's wrong with CSQC
Posted: Fri Jul 04, 2014 1:56 pm
a few lesser-known notes:
qc-friendly docs were going to be released alongside the reference implementation.
the reference implementation was going to be the csqcwinquake engine (so named because of the project file, was meant to be sw+gl) that you can google for if you care. And yes, NQ. Nothing to do with busses.
it was going to be a mostly complete implementation, but was going to omit things that required too many engine changes (like skeletal objects, which need skeletal models first).
it was going to be able to use prediction (but only when driven by csqc).
I ported fte's csqc stuff over to it, started fixing up the issues (and reevaluating parts of it in the process). except I got bored. and dp's implementation got released. and used. and it was incompatible. and meh. but mostly I got bored and paranoid about how it would be received.
I assume most of it works. however, its not a readable reference, so its kinda pointless. its also quite invasive. networking changes are kinda bad too, but at least they're meant to only apply when csqc is active.
it later resurfaced when I gave a copy to xavior when he was trying to add csqc to ezquake.
I've cleaned up FTE's code quite a bit since then, as well as made concessions to try to support some dp-isms that don't break other stuff (hopefully...). I really don't remember how much of it was implemented, there appear to be a number of notable 'TOFIX' tags lying around in it though. So don't expect it to work with any mod not explicitly written for it...
I kinda regret trying to support anything but huds with it. hud-only csqc support would have been easy, useful, portable, and completable. there would have been all sorts of nightmares with trying to do anything advanced like entities (beyond using them just for field space), but at least it would have served as a gateway to a more complete implementation.
yeah, most engines would still not support 3d stuff, but at least csqc hud support would have been a nice easy thing to drop into a project and could have been widespread now.
if someone with lots of motivation wants to go through it and finalise it, feel free. or rework it to gut all but huds, again feel free. there are actually a few mods that it can be tested against now, so hurrah for that, or someone could make a decent diff from rmqe.
the problem I find is with motivation, and keeping it for long enough to finish it. everything always ends up as a race against time eventually.
qc-friendly docs were going to be released alongside the reference implementation.
the reference implementation was going to be the csqcwinquake engine (so named because of the project file, was meant to be sw+gl) that you can google for if you care. And yes, NQ. Nothing to do with busses.
it was going to be a mostly complete implementation, but was going to omit things that required too many engine changes (like skeletal objects, which need skeletal models first).
it was going to be able to use prediction (but only when driven by csqc).
I ported fte's csqc stuff over to it, started fixing up the issues (and reevaluating parts of it in the process). except I got bored. and dp's implementation got released. and used. and it was incompatible. and meh. but mostly I got bored and paranoid about how it would be received.
I assume most of it works. however, its not a readable reference, so its kinda pointless. its also quite invasive. networking changes are kinda bad too, but at least they're meant to only apply when csqc is active.
it later resurfaced when I gave a copy to xavior when he was trying to add csqc to ezquake.
I've cleaned up FTE's code quite a bit since then, as well as made concessions to try to support some dp-isms that don't break other stuff (hopefully...). I really don't remember how much of it was implemented, there appear to be a number of notable 'TOFIX' tags lying around in it though. So don't expect it to work with any mod not explicitly written for it...
I kinda regret trying to support anything but huds with it. hud-only csqc support would have been easy, useful, portable, and completable. there would have been all sorts of nightmares with trying to do anything advanced like entities (beyond using them just for field space), but at least it would have served as a gateway to a more complete implementation.
yeah, most engines would still not support 3d stuff, but at least csqc hud support would have been a nice easy thing to drop into a project and could have been widespread now.
if someone with lots of motivation wants to go through it and finalise it, feel free. or rework it to gut all but huds, again feel free. there are actually a few mods that it can be tested against now, so hurrah for that, or someone could make a decent diff from rmqe.
the problem I find is with motivation, and keeping it for long enough to finish it. everything always ends up as a race against time eventually.