View previous topic :: View next topic |
Author |
Message |
Baker

Joined: 14 Mar 2006 Posts: 1538
|
Posted: Sun Nov 22, 2009 11:51 am Post subject: CSQC Modification Questions For Spike |
|
|
Spike, fairly early in the year real life managed to suck up about all available time for several months and at least for a while I'll have some free time.
Your CSQC WinQuake prototype, which since it is even software compatible is globally Quake compatible, could you run down a short list of the features or capabilities this will give to QuakeC for an engine using the modification?
The goal in asking this question is to be able to "sell" to existing QuakeC modders, in particular in the NQ community but maybe some parts of the single player community as well, the basic CSQC features if a new "standard" baseline modified engine platform existed.
And the main reason I ask, being somewhat weak on QuakeC myself and having never written CSQC for DarkPlaces or FTEQW or Nexuiz, I have a fuzzy understanding of some of the benefits of CSQC as far as concrete specifics go and I'd like to be to explain them, especially in the form of "now you can do this, this and this". |
|
Back to top |
|
 |
mh

Joined: 12 Jan 2008 Posts: 909
|
Posted: Sun Nov 22, 2009 1:42 pm Post subject: |
|
|
Seconded. I'd like something like this as well. So far all I've really seen of CSQC amounts to what's basically tech-demos, but I have a vague notion that it would allow a mod to call a lot of client-side code and access a lot of client-side objects (sorta like the client VM in Q3A).
However, my engine's architecture is sufficiently different from vanilla Win/GL that implementing CSQC on it would be quite non-trivial. If I'm going to go down that route I'd like to know exactly what I'm getting for my time/work investment, and that it's actually something that would be used. _________________ DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines |
|
Back to top |
|
 |
Spike
Joined: 05 Nov 2004 Posts: 944 Location: UK
|
Posted: Sun Nov 22, 2009 4:24 pm Post subject: |
|
|
Simple stuff:
custom huds. models on huds. team/flag status. button counters.
extended score boards/results (accuracy stats, favoured killees, captures, defends, etc).
inventory systems (eg: prydon gate could use a proper mouse cursor for its menus).
team/class/observer menus (particuarly customtf).
Secondary views (rear view mirror for quake rally, guided rockets, etc).
client side gibs (600 of them without clogging network, etc, nail grenades, semi-persistant ents).
client side spawning of particles (think hipnotic's bridges).
enforced fov/angles (flashbangs/magic-mushroom effects), locked view points (top-down mods, etc).
potentially better network performance (csqc allows sending nail start points and times, without constantly updating nails/rockets, so its much more compact).
next map selection menus (eg: nexuiz).
'proper' access to client-side cvars, for user-specific settings (eg customtf class works on all customtf servers, not just the one with frik_file enabled).
client-specific entity sending (enemy spies can have your team's colourmap for you, and thiers ffor thier team).
More complex things:
Custom player prediction code. And, urm, prediction code in the first place. :)
Unlagged shooting animations and other client-side prediction.
Client side cursors.
torch effects (dlights that don't lag behind the view angles).
Current dp/fte extensions:
Better animations (separate upper/lower sequences, etc with md3s/tags, without always breaking network compatibility).
Particle based effects. Glowing eyes, smoke rising from recently fired guns.
specific powerup shells.
Pending extensions:
clientside ragdoll, so the network doesn't die from sending bone positions.
Basically the idea of csqc is to give the modder access to parts of the engine that were previously unavailable to them (primarily the hud/config menus). Secondly, to provide access to features available to more modern games (yes, akin to q3a's cgame).
For the QC modder, it is not required that you actually manage any entities in csqc, but you do have to direct the engine to draw what it knows about.
Using CSQC does not actually mandate SSQC changes. DP requires all clients use csqc if the server has a csprogs, but that's not really intended by the csqc spec. Its perfectly viable to connect multiple different clients, some using csqc, others not. But you can also kick players if they are not using it, of course.
The engine supports both csqc and ssqc entity sending. csqc ents get the csqc versions, and clients without csqc get the ssqc fallbacks. Its entirely possible to provide effects compatible with either sort of client, without wasting bandwidth to provide for the other, and without even checking to see if the server+client supports csqc. :)
For the engine modder, it requires seperation of renderer and client. You must be able to draw multiple scenes (some without the world, ie: overlays) in order to provide the csqc with full control over the view. This will be the biggest issue for mh, and was the hardest part I found to get it stable with winquake too.
But the major major problem is that the qcvm needs separating to support two VMs running at once. I achieved this by reusing fte's qclib. Which is not the cleanest code around, but does get the job done, so the csqc winquake port has two separate qcvms inside. One is the old that supports all the qccx hacks. And one is the new, for running csqc itself (note that the csqc qcvm should ideally block most qccx hacks anyway).
Network changes are also required, in order to provide the csqc with notifications about changes on the server, so the mega-gibbings and stuff can work. Note that the provided code uses a versioning system, so it is entirely possible that the csqc mechanisms will result in a reduction in bandwidth spikes, assuming its used to do so (just do it with nails and you'll not spam people off nq servers).
Even without csqc-specific mod changes, the patch will extend stats to 32bit, so no more 255 ammo/health caps.
Engines must provide a compatible 2d interface. This does admittedly require stretching (which I don't think my sw version provided, but nearest pixel is conformant). Blend mode arguments are a DP extension, and its not required that they are even present... Unless you're using DP as a client. :/
I don't think mh will have any real issues with 2d stuff. just code cleanliness.
CSQC support in an engine is not trivial. It will make a lot of changes, and interact with code present in 90% of modified engines in some incompatible way or another, that a straight tutorial for adding support will be near impossible, and will be looong. Any such tutorial will need to branch into choice of base engines.
My csqc winquake engine thus does not support model interpolation, but should include comments saying which fields to read from in order to pass the information along to the renderer. _________________ What's a signature? |
|
Back to top |
|
 |
avirox
Joined: 16 Aug 2006 Posts: 109
|
Posted: Sun Nov 22, 2009 4:38 pm Post subject: |
|
|
Join Megatf COOP (74.54.186.230:27500) using FTE and you can see some practical uses of CSQC in action. What coop currently has:
GUI class menus with descriptions of each class (WIP)
Real-time Experience Points HUD item (top-right)
Reload bar
Experience Point notification images
Misc GUI menus replacing silly centerprint ones
.. probably some other things I'm forgetting, too
I'm currently working on using physics stuff with CSQC, but that's a little more in depth I suppose. If you'd like I can show you a tech demo of my project Damascus which is a top-down Diablo style mod with mouse-controlled movement and attacking, etc.
Given the right amount of dedication, CSQC can do wonders where other quake mods have fell into mediocrity. My current plans revolve around a Streets of Rage coop mod for quake primarily using CSQC for special moves (key inputs), health bars, and random generated physics. |
|
Back to top |
|
 |
frag.machine

Joined: 25 Nov 2006 Posts: 728
|
Posted: Sun Nov 22, 2009 6:59 pm Post subject: |
|
|
One thing that could turn CSQC really useful is the ability to process unknown network messages. Basically, if it's not a regular message, the C code gives to CSQC a chance to process it before assuming a network error and disconnecting. Actually, the same is true to the server side of the engine.
EDIT: neat ideas of features aside, CSQC needs badly of complete, consistent and objective documentation - maybe more than a simple reference implementation over stock GLQuake. _________________ frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/ |
|
Back to top |
|
 |
mh

Joined: 12 Jan 2008 Posts: 909
|
Posted: Sun Nov 22, 2009 7:12 pm Post subject: |
|
|
Right now I'm wondering how possible it would be to selectively implement parts of CSQC. How modular is it? Or is it even designed that way? The way I read things is that you essentially have to rip apart and reconstruct almost the entire client side of your engine, and that's quite a daunting prospect. Being able to build it up in layers and bolt on bits would definitely increase the possibility of me taking it on. _________________ DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines |
|
Back to top |
|
 |
Spike
Joined: 05 Nov 2004 Posts: 944 Location: UK
|
Posted: Sun Nov 22, 2009 9:33 pm Post subject: |
|
|
mh, logically you could provide a seperate entry point and provide only 2d/stat/string builtins.
the full spec, however, logically has a single function which is called each frame, which does everything else... Well, there are some input and network notifications too, but that's the general ideal, its just a bit lazy.
The way the rendering is set up, is that the client calls the csqc to draw the entire screen.
frag.machine:
http://fteqw.svn.sourceforge.net/viewvc/fteqw/trunk/specs/ext_csqc_1.txt
let me know if there are any omissions. _________________ What's a signature? |
|
Back to top |
|
 |
Baker

Joined: 14 Mar 2006 Posts: 1538
|
Posted: Mon Nov 23, 2009 1:32 am Post subject: |
|
|
avirox wrote: | Join Megatf COOP (74.54.186.230:27500) using FTE and you can see some practical uses of CSQC in action. What coop currently has:
GUI class menus with descriptions of each class (WIP)
Real-time Experience Points HUD item (top-right)
Reload bar
Experience Point notification images
Misc GUI menus replacing silly centerprint ones
.. probably some other things I'm forgetting, too |
I'll connect and check it out. The idea of the HUD and the centerprint and more or less managing the 2D graphics has a lot of appeal.
/Is hoping is in the CSQC WinQuake. I am not a fan of sbar.c because the Quake HUD obviously isn't appropriate for a great many things and would like centerprint to be more "flashy" without having to write up some sort of centerprint markup scheme. |
|
Back to top |
|
 |
frag.machine

Joined: 25 Nov 2006 Posts: 728
|
Posted: Mon Nov 23, 2009 3:10 am Post subject: |
|
|
I've already stumbled on this document in a number of Quake wikis. Can we assume this version as up-to-date with the FTEQW code ? I'll study it more carefully. _________________ frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/ |
|
Back to top |
|
 |
Spike
Joined: 05 Nov 2004 Posts: 944 Location: UK
|
Posted: Mon Nov 23, 2009 10:26 am Post subject: |
|
|
That's the spec for EXT_CSQC_1. Documented behaviour supposedly matches FTE exactly.
It also matches the csqc winquake port. But that does have a couple of incomplete parts/omissions (from what I remember, mostly sounds).
There are a couple of fixmes still.
Looking at it now, there are additional features in the server which are not documented (handling prediction and availability).
Note that this is a later version of the csqc spec than the one present in DP. Not all features are present in DP, and not always compatible when they are. The DP differences are not documented here.
It is possible to target DP or FTE/csqc-winquake with the same csprogs, but FTE will warn if you use DP's defs (or indeed anything that is not 'standard' - your definition of standard may vary... but will attempt to load), and DP will outright reject anything that is not DP specific. _________________ What's a signature? |
|
Back to top |
|
 |
Baker

Joined: 14 Mar 2006 Posts: 1538
|
Posted: Mon Nov 23, 2009 11:50 am Post subject: |
|
|
Spike wrote: | That's the spec for EXT_CSQC_1. Documented behaviour supposedly matches FTE exactly.
It also matches the csqc winquake port. But that does have a couple of incomplete parts/omissions (from what I remember, mostly sounds).
There are a couple of fixmes still.
Looking at it now, there are additional features in the server which are not documented (handling prediction and availability). |
Annoying question #1 ... I hate to ask this one, yet it is essential ..
Spike or Avirox, do either of you have a simple or at least not high level expertise QuakeC source that can be used with the experimental WinQuake?
Something light enough to be understood, but still useful.
Again, I hate asking this question but hopefully there is one.
Maybe something simple like standard Quake single player with an altered HUD or some other thing. Or standard DM with an altered HUD or altered something else CSQC-like that is fairly close to "normal" so QuakeC familiar but CSQC unfamiliar people can immediately "get it".
And if there isn't one, that's ok too ... I'm trying to think of how to advance the "cause" further. |
|
Back to top |
|
 |
Spike
Joined: 05 Nov 2004 Posts: 944 Location: UK
|
Posted: Mon Nov 23, 2009 12:33 pm Post subject: |
|
|
there's a csqc hud on fte's svn in csqctest. it doesn't match the normal one exactly however, as it takes some short cuts (weapons don't flash when you get them), but it could be extracted and rehoused in a more bare csprogs. _________________ What's a signature? |
|
Back to top |
|
 |
avirox
Joined: 16 Aug 2006 Posts: 109
|
|
Back to top |
|
 |
mh

Joined: 12 Jan 2008 Posts: 909
|
Posted: Mon Nov 23, 2009 5:09 pm Post subject: |
|
|
That's all interesting, and it's good that there's some kind of off-line mod to test with while developing. Obviously one can't be running a debug build, having to connect, and having stuff like transient network conditions (or even getting one's ass handed to one) interfering with testing.
It seems as though the major initial grief to get over is reworking PR_ExecuteProgram to be able to peacefully run both client and server progs without the one interfering with the other. Any tips on that? Having to provide a second progs interpreter in the engine seems kinda silly to me. _________________ DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines |
|
Back to top |
|
 |
Spike
Joined: 05 Nov 2004 Posts: 944 Location: UK
|
Posted: Mon Nov 23, 2009 8:04 pm Post subject: |
|
|
the PR_ExecuteProgram in qclib is able to run multiple instances at once (actually multiple progs in each instance too, but mneh).
I just chose to not port the server to use that instead too. FTE itself uses only qclib.
But here's a gotcha: qclib adapts progs internals slightly. It will break any mod that uses extensive qccx hacks. Accessing the hidden internals of the engine is prevented. So this would break any mod that depends upon that info (ie: anything written for proquake...).
This reason, and the fact that the code changes were already extensive, resulted in me using two separate vms for the csqc-winquake port.
It shouldn't be all that hard to switch to qclib exclusively, though I confess that saved games might not be so straight forward. Mostly its a case of including the different header and changing the function names, adding extra instance arguments as required.
For DirectQuake, just stick your qcvm globals in a class. :P
There's a lot of code changes, regardless of the method, however. _________________ What's a signature? |
|
Back to top |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2004 phpBB Group
|