RANT: What's wrong with CSQC

Discuss CSQC related programming.
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: RANT: What's wrong with CSQC

Post by Spike »

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.
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: RANT: What's wrong with CSQC

Post by Baker »

goldenboy wrote:Edit: The RMQ implementation was done by Spike, and supports basic HUD stuff at least. RMQe is based on Quakespasm, so it should be possible to add the CSQC stuff to Fitzquake-like engines from there, if anyone could be arsed.
In theory the fact that RMQ engine is open source is a plus.

But for an engine modder to implement and test the implementation, would require a functional CSQC source for testing.

And the RMQ CSQC QuakeC is to the best of my knowledge closed source.
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: RANT: What's wrong with CSQC

Post by Spike »

yeah, I really should point out that the rmqe source is a 3rd implementation of csqc. and once again, it expects a different layout to the system fields. this is because its a work-in-progress, except its not really in progress any more.
the specific cause is that its trying to reuse the ssqc builtins that it can with csqc, including entity fields and things (in a vauge attempt to get traceline working - a necessity if you're going to do things like chasecams eventually).
there's no easy way around that. which is why csqcwinquake used fte's qclib for its vm, which can remap entity fields however it needs.
but on the other hand, maybe the rmqe defs should have been the ones to be standardized - its not like the other engines really care that much, even if they might moan about it.
goldenboy
Posts: 924
Joined: Fri Sep 05, 2008 11:04 pm
Location: Kiel
Contact:

Re: RANT: What's wrong with CSQC

Post by goldenboy »

In theory the fact that RMQ engine is open source is a plus.

But for an engine modder to implement and test the implementation, would require a functional CSQC source for testing.

And the RMQ CSQC QuakeC is to the best of my knowledge closed source.

There never was an official RMQ CSQC progs. The project splintered right before anyone got to that. All we did was make some designs and plans for a HUD, and we never could agree on anything.

I think I tested CSQC in RMQ using avirox' example CSQC menus, and those worked well. These days I would suggest gnounc's cleancsqc as a first test case. I think it contains mostly a simple example HUD and not much else, so it might just work.
ceriux
Posts: 2230
Joined: Sat Sep 06, 2008 3:30 pm
Location: Indiana, USA

Re: RANT: What's wrong with CSQC

Post by ceriux »

would be cool to see something like fitzquake with csqc in it.
toneddu2000
Posts: 1395
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy

Re: RANT: What's wrong with CSQC

Post by toneddu2000 »

frag.machine wrote:Let's say we voted for skeletal models and ragdolls this week. One of our talented modellers will cook a very simple public domain model (let's keep it into CC/GPL territory guys, credits obviously will be given) to be used as the target artwork fo the challenge, and we the coders will have to figure out (with the help of the engine coders) how to make things work and, eventually, how to make things that weren't expected with the new knowledge.
I'm in. As you can see I tried hard and hard to accomplish advanced tasks with skeletal animation in csqc but with less (or none) results. I laugh a bit when someone (with a little of arrogance, I must say) proclames: "CSQC tutorials are everywhere".
1)For CSQC, community doesn't need a 2 lines tutorial. It needs a guide from the ground up which explains why CSQC was invented by Spike, HOW and WHERE IS MELTED into the engine (let just talk about FTE, for a moment) with the server part, what are the main concepts (Skeletal animations,menus, player prediction, etc.) that it's possible to achieve with DETAILED example in csqc, and what can NOT be obtained with that
2)Regarding skeletal animations, stuff like this will just NOT work! If anyone made it work, he's (or she's) pleased to let the community aware of it.

I will (as anyone here I think) try to achieve my goals even between a detailed guide, but, of course, I'm not so sure I'll be able to pursue my inspirations! :D

BTW: You can use Xonotic Erebus model , I used that for my tests, it's fine
Meadow Fun!! - my first commercial game, made with FTEQW game engine
LordHavoc
Posts: 322
Joined: Fri Nov 05, 2004 3:12 am
Location: western Oregon, USA
Contact:

Re: RANT: What's wrong with CSQC

Post by LordHavoc »

Spike wrote:
LordHavoc wrote:LordHavoc rant time:
Way back in 1999 there was this magical thing called the Quake Source Mailing List, where great ideas were discussed by several people, most of whom didn't go on to make any engines, the idea of CSQC was floated on there and I was more or less the key architect on that discussion.
which I wasn't really aware of.
This sounds like a critical failure, and I won't claim that CSQC was "co-designed" anymore with this bit of news, I'm frankly shocked that you didn't do your research though.
Spike wrote:
In essence the only true spec for EXT_CSQC is the FTEQW source code, this is a terrible situation on the whole, and darkplaces' implementation still does not quite match because I haven't finished comparing every code path and attempting to correct the (now entrenched) brokenness in the darkplaces implementation, which isn't really [515]'s fault.
but what was [515]'s fault is that when he had no idea what the thing was meant to do, he didn't try contacting me.
as far as I'm aware, he also never even tried running csqctest either - the only csqc mod at the time that was written explicitly to test the various parts of the engine (admittedly this made it clumsy as a base mod, but would have been ideal for [515]). out of curiosity, did you ever try running it?
[515] never told me about csqctest, and given the implementation he submitted I doubt he knew of it either, what was the process of finding this "csqctest" back then? if it only lived on the fteqw svn and had no proper web page then I can see how he missed it.

I can squarely blame every quality problem with the initial CSQC implementation in darkplaces on the lack of a proper website to document it, as a rule I do not look at other engines when implementing an extension spec, this prevents confusion of implementation details and ownership.

The spec is the standard, and the feature is to be implemented to the spec, exactly as stated in the spec, if the spec is shoddy then you get what happened with EXT_CSQC, so I blame the spec, not [515] for how he interpreted it.
Spike wrote:the spec was never really intended to be complete and concise, if only because the spec was in flux and really was not anywhere near finalised. I was hoping for feedback and itterative improvement. what I got was an alternative engine implementation that was usable for nothing but huds.
The only bit of feedback I remember I got was about stats from you, that strings+floats should be sent as they are instead of casting to a float. I made that change. DP still requires people to claim that their datatypes are integers in order to send floats.
I'm still not sure on the status of that, except that whatever the case I won't be breaking compatibility with existing csqc mods. As I recall I corrected the names of these constants in the headers? The enum values won't be changing as that would break existing mods. Existing mod compatibility always trumps any discussion of bugs.
Spike wrote:
On the whole I deeply regret not implementing CSQC first (it was my idea after all), as I think my documentation would've turned out a lot better (as proven by the relative clarity of dpextensions.qc), and would have been more conscious of the design differences between NQ and QW engines (where EXT_CSQC was designed around QW engines and throws NQ under the bus).
I'd written stuff to run qc on behalf of the client before I even had any internet access other than emails (in a hacky way that later formed the basis of FTE_MULTIPROGS), way back in my NQ engine. That qc vm was the first thing that got added to what later became FTE, when I started a QW engine. Claiming that it was exclusively your idea is unhelpful, ultimately it was based on q3 with its separate network/render entities but with all pointers removed.
This raises troubling questions about the fractured community of engine developers, you weren't even aware of the QSML discussions?

CSQC was supposed to be the greatest thing since sliced bread, back in 2000, not waiting for the Quake3 source to come out to provide guidelines on design for it. At least now I know why you waited so long.
Spike wrote:ext_csqc was written by someone working on a QW engine who also had significant understanding of NQ. Every single feature considered the possibility of implementing it in an NQ engine, although yes, it did expect a few changes like increasing the engine's internal temp-entity limit. Any QuakeWorldisms that would need to be supported were intended to be either fairly trivial to implement (like the input log+sequence acks), or trivial to stub (like userinfos, or alpha+sizes in software rendering engines). If it had been QW-centric, it would have used completely separate player+non-player entities!
Also, 'co-designed by both of us'. Yup, NQ under the bus... You're contradicting yourself.
It is unfortunate that you were unaware of the QSML discussions, and accordingly I will no longer claim that it was co-designed.

Regarding throwing NQ under the bus - look at all the things EXT_CSQC does that disagree with NQ engines: relying on infostrings (which do not exist in NQ engines), multicast (again does not exist), lacks chase_active support (present in NQ), ignores GAME mode in the protocol (SP/COOP/DM) which affects whether rankings are shown on the hud (a very undesirable thing in singleplayer).

Since darkplaces is an NQ engine, many differences exist in how these aspects were implemented, which led to a fair bit of trouble for you as I recall (chase_active especially), the decisions on most of this were made directly by [515] and I do not know the specifics.
Spike wrote:edit: the 2d drawing functions were based upon menuqc, which was Black's work iirc. Not allowing code reuse between menuqc (which has no real access to the state of the game) and csqc would have been suicide. This included using the same DP-only keycode constants as menuqc, which means handicaps like being unable to tell which alt key was pressed. For completeness, these 2d functions are basically wrappers around glquake's Draw_Pic function, with a few extra arguments that throw software renderers 'under a bus'. If the full spec had ever been finalised, it would have contained a clause to allow software renders to ignore rescaling or tinting/blending.
the lack of scaling in software rendering combined with the abuse of vid_conwidth is another miss-step dating back to csqc's menuqc/dp concessions that is harmful to adoption.
vid_conwidth is a can of worms because it affects CSQC and menuqc, which I never intended (but Black and [515] apparently thought it should), there's no real opportunity to fix it now, even though I would like to, the only change I have planned is at some point adding a vid_conwidthauto cvar that computes it from the screen aspect ratio (vid_conheight*vid_width/vid_height/vid_pixelheight) and changing the default vid_conheight to 360 (to match the fact that most people have 16x9 monitors now).

If I had my way, csqc and menuqc would have used vid_width coordinates, much simpler.
Spike wrote:
To be clear on one point, DarkPlaces exists to be the ultimate stable platform for Quake modders who want to go beyond the origins of Quake and make standalone games as well as mods, it is not an experimental engine on the whole, so quite often you see experimental features appear in other engines first, and have a bit of time to mature, then darkplaces implements similar functionality (written from scratch) with stability and standardization as the goal.
from my perspective, DP is the fixed-function pipeline of Quake. If you want to achieve something, you need to use some specific shader keyword or cvar for it (chase_active, anyone?). Yes, it has extensions, but if you want to avoid the id1 directory (including homedir issues), 'you' still need to edit the engine to do it.
the 'standardization' part only applies when its a DP standard.
the 'stability' part is a hinderance, in that DP is so stable that its API is never updated to actually be useful, and limits what you can achieve with it. the fact that you're no longer working on it very much other than bugfixes does at least help not create new crashes.
Stable is necessary for people to actually use an engine for new projects without consulting with the engine author every day, but I'll spare you that rant.

Even if you choose to disregard them, extensions are standards documents and are implemented in other engines (for example TomazQuake), this is what I mean by standards, I don't see how that is DP-specific? They succicinctly define all expected functionality in a nicely written description and often include example code for how they should be used.

With that definition in mind, where is the EXT_CSQC standard so that I can make darkplaces match it?

Regarding chase_active, this is an NQ feature that users find precious, so I do not accept the idea of removing the feature even if EXT_CSQC does not support it, if there is an alternative approach to how to handle it in CSQC then I'm interested in discussion about that.
ceriux
Posts: 2230
Joined: Sat Sep 06, 2008 3:30 pm
Location: Indiana, USA

Re: RANT: What's wrong with CSQC

Post by ceriux »

i'm not exactly sure if i agree with you toneddu2000, when theres too much info my brain kind of gets melty i have problems paying attention. i kind of like the qc tutorials we already have, but id like the csqc tutorials to be just like them, but with better comments explaining what each line is doing. if there is some kind of equation explain what its doing and why.

when theres too much jibberish mixed with a tutorial it becomes hard to follow. the extra information is nice... but i become lost in it.

as an example this : http://sourceforge.net/p/fteqw/code/HEA ... idiots.txt

it has way too much going on. i downloaded the text file and i read and read and read all the information in there is lost among all the non nessisary information.. (not that its not a good tutorial/document)

i like to see an example and a semi detailed comment about whats going on in the specific line. its much more straight forward and leaves a lot less to shift through.
toneddu2000
Posts: 1395
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy

Re: RANT: What's wrong with CSQC

Post by toneddu2000 »

i'm not exactly sure if i agree with you toneddu2000
Well, internet is a free place, every opinion is accepted! :D
id like the csqc tutorials to be just like them, but with better comments explaining what each line is doing. if there is some kind of equation explain what its doing and why.
yeah, me too
it has way too much going on. i downloaded the text file and i read and read and read all the information in there is lost among all the non nessisary information.. (not that its not a good tutorial/document)
I think Spike and LordHavoc make only a mistake. They think normal people are all genius like them! :lol:
I'm making a (I hope) detailed documentation about making games with Darkplaces engine and I would like to spend a big chunk of time on csqc.
But I need (as anyone else) steady points. My biggest issue is skeletal animation. I can't make a model animate in client side. It stands still or it makes jitter movements. Another thing is passing entity (not only player) from ssqc to csqc.
i like to see an example and a semi detailed comment about whats going on in the specific line. its much more straight forward and leaves a lot less to shift through.
Completely agree
Meadow Fun!! - my first commercial game, made with FTEQW game engine
ceriux
Posts: 2230
Joined: Sat Sep 06, 2008 3:30 pm
Location: Indiana, USA

Re: RANT: What's wrong with CSQC

Post by ceriux »

My biggest issue is skeletal animation. I can't make a model animate in client side. It stands still or it makes jitter movements. Another thing is passing entity (not only player) from ssqc to csqc.
have you messed with these?

Code: Select all

entity self;
entity other;
entity world;
float time;
float cltime;
float frametime;

.float frame;
.float frame1time;
.float frame2;
.float frame2time;
.float lerpfrac;

.entity tag_entity;
.float skeletonindex;

.float jointtype;

.float baseframe;
.float baseframe2;
.float baseframe1time;
.float baseframe2time;
.float baselerpfrac;
.float basebone;
.float bonecontrol1;
.float bonecontrol2;
.float bonecontrol3;
.float bonecontrol4;
.float bonecontrol5;
.float subblendfrac;
.float basesubblendfrac;

i think most if not all of those are for clientside players/boned players.

i personally plan to use md3 if im able to get csqc players working. i dont believe they're boned. but after that what i think is going to be really hard is csqc enemies o.O .. i want my game to run as smoothly as possible if im ever able to get it up and going.
LordHavoc
Posts: 322
Joined: Fri Nov 05, 2004 3:12 am
Location: western Oregon, USA
Contact:

Re: RANT: What's wrong with CSQC

Post by LordHavoc »

ceriux wrote:have you messed with these?
Not that darkplaces is being discussed here necessarily, but most of those fields won't do anything in darkplaces, never even heard of most of them.
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: RANT: What's wrong with CSQC

Post by Spike »

@LordHavoc
LordHavoc wrote: With that definition in mind, where is the EXT_CSQC standard
Keep asking that, maybe you'll finally get an answer other than 'what's the point', but I doubt it. Its not like you'd actually break compatibility with existing dp-only mods anyway.
http://triptohell.info/moodles/fteqcc/csqcsysdefs.qc is what I'd currently point people to.
Yes, I kept it somewhat terse, because a) I cba typing lots. b)
ceriux wrote:when theres too much jibberish mixed with a tutorial it becomes hard to follow. the extra information is nice... but i become lost in it.
note that baseframe and fiends are documented in there. while I really can't say how long they've had a description for (probably not that long), they have at least been listed for quite some time, which is how come ceriux knows about them. hurrah, documentation in action, right? meh, you're hard to please.
while we're on this subject, fteqcc won't complain/warn about duplicate builtins unless the arguments/types return errors. presumably this means that you can compile it alongside whatever dp-specific csqc defs.qc file you currently use to see many the ways that dp differs, at least in terms of argument counts anyway. vararg builtins will always be messy though, I suppose. still, its one quick check anyway.

chase_active is a disgusting hack. you can't set the cvar set to 1 because then the engine will hack stuff randomly, and while you can set it to 0, you then can't use the cvar to see the user's intention beyond saved configs or endgames. imho the only way to cleanly implement it is to disable it when csqc is running just so that its possible to set it without breaking everything. yes, I'm a bit of a perfectionist. yes, this doesn't help with motivation. its fun like that.
infokeys were never needed - nq always had a concept of certain userinfos even if it never had a concept of gluing them all into a single block. really the only difference it would have made would have been 50 builtins instead of 1.
multicast is only needed if you're doing evil things, like using NQ mods in a QW engine. That sort of thing *REALLY* needs message termination to stop xonotic from blowing up. multicasts are the obvious solution there. They're also quite handy for other things, like not wasting quite so much bandwidth, but hey.
The GAME_ mode is provided through serverkey, just like svc_clientname is provided through getplayerkeyvalue (yeah, that was badly named). Its just decomposed back into coop and deathmatch settings. Its quite annoying that NQ and DP don't give more info than that. Limitations are limitations, but it doesn't stop the API from returning what it knows. infostrings are not actually exposed to csqc, except through FTE_STRINGS, and even then they're not actually tied to other parts of the api (which is a shame really, because it would have made getting key bindings much more sane... menuqc compat).
I'd reply to the rest of your post, but frankly I shouldn't have replied to that part either. plus I want to go sleep.

@ceriux:
baseframe etc control the 'early' bones in a skeletal model, stopping on the bone named by basebone. These are typically the legs. This allows you to control the frame blending for the torso and legs independantly by using the appropriate fields. Think of it as two models, like an md3... just folded into separate fields on the same entity and with lots of shared properties like origin and angle...
these are not useful for md3s.

with quake3-style md3 player models, you need to use either multiple entities all moving together, or one entity with multiple calls to addentity. csqctest used the former option (see http://sourceforge.net/p/fteqw/code/HEA ... playerm.qc for some code that loads+animates q3 player models (even parsing the animation.cfg file) - it works out the animation to use based upon the player entity's .frame field. it should also work just as well in dp except obviously for shaders. afaik, openarena's models should load fine though it too. obviously the weapon models are wrong/random, but there's not much you can really do about that unless you know someone willing to get off their arse and make a raygun for you instead...).

decent animations for enemies can be hard on account of quake monsters stepping different distances each frame. this makes foot sync messy.

@leileilol
it might be useful. really it comes down to animations. whatever you do, the qc code needs to know what animations are available to it, and to choose them properly. there's two ways to do legs, either twisting at the hip, or using 4-way blending for forward+back animations.
I suppose I ought to provide code for either possibility, but that's going to make the code more ugly than it needs to be. which is bad(convoluted) if its ever used as an example.
toneddu2000
Posts: 1395
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy

Re: RANT: What's wrong with CSQC

Post by toneddu2000 »

ceriux wrote:have you messed with these?

Code: Select all

entity self;
entity other;
entity world;
float time;
float cltime;
float frametime;

.float frame;
.float frame1time;
.float frame2;
.float frame2time;
.float lerpfrac;

.entity tag_entity;
.float skeletonindex;

.float jointtype;

.float baseframe;
.float baseframe2;
.float baseframe1time;
.float baseframe2time;
.float baselerpfrac;
.float basebone;
.float bonecontrol1;
.float bonecontrol2;
.float bonecontrol3;
.float bonecontrol4;
.float bonecontrol5;
.float subblendfrac;
.float basesubblendfrac;
Thanks, ceriux, well, I've messed with some of these! But as LordHavoc stated, some of them are not even mentioned in Darkplaces
The problem is that maybe I should direct all my energies on FTE first. Because the only documentation I found is written by Spike and then port all the stuff to DP.
Just a question Spike: Has this example ever worked for you?
In particular this function

Code: Select all

void() mycsqcpredrawfunction =
{
if (!self.skeletonindex)
self.skeletonindex = skel_create(self.modelindex);
self.frame1time = time;
self.frame2time = time;
self.frame = 0;
self.frame2 = 1;
self.lerpfrac = 0.5;
skel_build(self.skeletonindex, self, self.modelindex, 0, 0, 0, 1);
}; 
Here it says:
The code above will create a skeletal object for the entity, and fill it with animation data (firstbone, lastbone set to 0 means 'all bones').
And with which version of FTE? Because I would like to start from there.
And can you please tell me what is the purpose of predraw function? Is it tied to every skeletal entity? Is it running at every frame? Thanks and sorry for the little off-topic (but not so off :) )
Meadow Fun!! - my first commercial game, made with FTEQW game engine
ceriux
Posts: 2230
Joined: Sat Sep 06, 2008 3:30 pm
Location: Indiana, USA

Re: RANT: What's wrong with CSQC

Post by ceriux »

toneddu i think predraw is explained in here : http://sourceforge.net/p/fteqw/code/HEA ... idiots.txt
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: RANT: What's wrong with CSQC

Post by Spike »

the predraw method (and by method, I mean function stored in a field) is invoked by the addentities function (just before the engine implicitly calls addentity on the entity for you - note that in FTE you can inhibit the engine's auto addentity call by returning TRUE, giving you a chance to revert temporary field changes or whatever).
because addentities is called each frame, the predraw function is also called each frame too, for each entity.
this gives you a chance to edit the fields to interpolate or extrapolate the entity as you feel fit before it is submitted to the renderer, with exact timing info and stuff.
naturally, you can use it as a second think function, but often you'll get smoother results by using it exclusively instead of .think.

I'll make a mental note to actually test the example when I've more time on my hands, I don't see any obvious reason why it wouldn't work. I was messing with skeletal objects yesterday so I know skel_build works in that mod at least.
be aware that a fixed lerpfrac 0.5 will blend two separate animations in a way that you might percieve as buggy. I believe I wrote it that way to invoke some curiosity. fte now has a 'modelviewer' command that you can use to check what the engine sees in the model, in terms of frames and framegroups and skins and bones and stuff. its rudimentary but gets the job done. note that DP doesn't necessarily see the same thing for all model formats - fte strictly sees what is in the model, while in my experience DP has a tendancy of unpacking framegroups and throwing away the animations.
Post Reply