CSQC: Global Implementation Project

Hopefully this will be short and sweet.

Target engines:

* ProQuake [even the new Flash build, barring an impossibility]
* Enhanced GLQuake/WinQuake
* TyrQuake
* JoeQuake
* Qrack
* FitzQuake
* FitzQuake SDL if possible

Assessing the difficulty/planning:



I don't know what the qclib folder is, maybe it'll be obvious as I progress.

The rest of this at a glance looks straightforward and non-problematic.

Ok ... first step. Try to build the current project.

I see this is MSVC6, which is nice because many of the engines like Enhanced GLQuake and FitzQuake 0.85 are MSVC6 so no conversion required. The qclib folder builds a qcvm.lib (QuakeC Virtual Machine, I assume) which is a project dependency library.

The GLQuake debug exe builds. The GLQuake release build doesn't build for me (the GL debug, WinQuake release and WinQuake debug versions do build) ...

Linking...
pr_bgcmd.obj : error LNK2001: unresolved external symbol _QC_RemoveProgsString
pr_csqc.obj : error LNK2001: unresolved external symbol _CloseProgs
pr_csqc.obj : error LNK2001: unresolved external symbol _InitProgs
.\release_gl\csqcglquake.exe : fatal error LNK1120: 3 unresolved externals
Error executing link.exe.

I'm using Vista at the moment and I get this complaint when I compile ...

LINK : warning LNK4098: defaultlib "LIBCD" conflicts with use of other libs; use /NODEFAULTLIB:library

I notice that #ifdef QUAKE2 stuff has CSQC code in it. I've stripped all the "QUAKE2" stuff out of ProQuake and many engines have it removed. I've never personally built the QUAKE2 build to see the differences in capabilities

[Although the apparent ability to save every level and then re-enter the levels, in particular, is a curiosity of mine.]

Quick roading testing of csqcwinquake and csqcglquake in single player and connecting to a server. No issues.

More notes ... holy hell --- The QCVM! The readme notes blow my mind. (Read the readme.txt)

The release build requires that you add a qcvm.lib dependancy. The debug build already has it added.

The ifdef quake2 stuff is not entirely interesting. But the changes are there for completeness. I admit that they might cause conflicts, but I don't see this as a major issue to anyone who understands the code a little.

And yes, I put a surprising amount of time into qclib itself, both the qcc and vm parts.

The release build requires that you add a qcvm.lib dependancy. The debug build already has it added.

Alrighty.

Self reference attack strategy

And yes, I put a surprising amount of time into qclib itself, both the qcc and vm parts.

I will likely have 3 engines done tonight.

Which leaves the future question ... how can this be tested?

I am going to be focusing on FitzQuake 0.85, ProQuake (Windows) and JoeQuake tonight.

Which leaves the future question ... how can this be tested?

Probably someone needs to make a "conformance test" mod, basically a mod that uses all the features in such a way that incorrect implementations fail visibly.

If CSQC had more documentation, I'd be using it a lot.

Unfortunately, it's fucking obscure.

I was testing it with my csqctest mod on fte's svn.
Hardly a polished mod, but then I did write it to make sure everything worked rather than as a true mod.
tweek the qc precompiler options so it doesn't depend upon extra stuff like md3 models.

If CSQC had more documentation, I'd be using it a lot.

Unfortunately, it's fucking obscure.

My hope is that if CSQC support becomes ubiquitous then it will be common place.

The 2D capabilities beat having to custom code every HUD idea into an engine. And if somehow radar and mini-maps can be done.

I so far have seen no network dependent changes (and don't expect to). In theory, every Quake should be able to support this (even FlashQuake, haha). In practice, the only trick will be figuring out how to compile the qcvm.lib on all these other platforms.

I was testing it with my csqctest mod on fte's svn.
Hardly a polished mod, but then I did write it to make sure everything worked rather than as a true mod.
tweek the qc precompiler options so it doesn't depend upon extra stuff like md3 models.

I think I'll go get that now.

http://fteqw.svn.sourceforge.net/viewvc ... z?view=tar

Stupid questions part #1:

I open up fteqccgui (both 2770 and 3443) and I see ...

#pragma sourcefile csprogs.src
#pragma sourcefile ssqc.src

... so now I'm thinking I click "compile" and each of those separate QuakeC sources will compile to probably a csprogs.dat and ssqc.dat (possibly?)

But instead I get

Source file: progs.src
progs.src:1: warning: Unknown pragma 'sourcefile'
progs.src:2: warning: Unknown pragma 'sourcefile'
Progs should run on any Quake executor
12 strofs (of 1000000)
1 numstatements (of 524288)
1 numfunctions (of 16384)
1 numglobaldefs (of 32768)
1 numfielddefs (0 unique) (of 2048)
31 numpr_globals (of 65536)
Writing progs.lno
384 TOTAL SIZE
Writing progs.lno
Compile Complete

numtemps 0
2 warnings

What am I doing wrong and is there some special way I need to compile this?

And part 2 ... once I get the 2 <whatever>.dat compiled progs, do I put them in a gamedir like expected or do they get a special subfolder.

Future reference material: Avirox's tutorial viewtopic.php?t=1560

In that thread i uploaded a file which you can use to compile CSQC GUI from. It's not as feature rich as Spike's CSQC mod, but it will at least let you know that the basics are working.

Also the csprogs.dat goes in the same folder as the (qw)progs.dat.

One day I should upload my test of Damascus, which taps CSQC to a much greater extent..

In that thread i uploaded a file which you can use to compile CSQC GUI from. It's not as feature rich as Spike's CSQC mod, but it will at least let you know that the basics are working.

Also the csprogs.dat goes in the same folder as the (qw)progs.dat.

One day I should upload my test of Damascus, which taps CSQC to a much greater extent..

From Spike's csqctest, what do I need to do to get the csprogs.dat to compile? I'm getting 1 kb progs.dat (that can't be right?) with that unknown "pragma sourcefile" issue above with fteqcc and fteqccgui.

/Meanwhile, I am trying your source

compile your own fteqcc. later versions contain an extension to build multiple progs.dat from multiple src files with a single compile.
alternatively, compile twice, with: fteqcc -srcfile csprogs.src
and: fteqcc -srcfile ssqc.src
Most of my qc source code depends upon fteqcc features nowadays, and I apologise for that. But it shouldn't need a special VM for it. But qclib would run that all even if it did. :)

Once compiled, place the csprogs.dat and progs.dat on the server in the gamedir.
csprogs.dat will also be required on the client, as csqcwinquake does not support file downloads (actually, the client will copy it to "csprogsvers/%x.dat". where %x is the hex value of the progs crc, so a single gamedir can support multiple crcs. Both FTE and DP will autodownload directly into the cache leaving the client's default csprogs.dat unmodified. This means you can connect to servers without affecting your own. But like I say, csqcwinquake doesn't support downloading, and the easiest way to work around this is to just replace the gamedir's csprogs (you can then copy out of the cache from one computer to another easily enough). Once the csprogs.dat has been loaded once, you can run that version without the csprogs.dat itself on the client computer, only the cached version. So you can revert back to the old one after you first run it. Mneh, its awkward. Implement downloading!

I just noticed, you'll need to remove entries from QSG_Extensions in pr_bgcmd.c

compile your own fteqcc. later versions contain an extension to build multiple progs.dat from multiple src files with a single compile.
alternatively, compile twice, with: fteqcc -srcfile csprogs.src
and: fteqcc -srcfile ssqc.src
Most of my qc source code depends upon fteqcc features nowadays, and I apologise for that. But it shouldn't need a special VM for it. But qclib would run that all even if it did.

Once compiled, place the csprogs.dat and progs.dat on the server in the gamedir.
csprogs.dat will also be required on the client, as csqcwinquake does not support file downloads (actually, the client will copy it to "csprogsvers/%x.dat". where %x is the hex value of the progs crc, so a single gamedir can support multiple crcs. Both FTE and DP will autodownload directly into the cache leaving the client's default csprogs.dat unmodified. This means you can connect to servers without affecting your own. But like I say, csqcwinquake doesn't support downloading, and the easiest way to work around this is to just replace the gamedir's csprogs (you can then copy out of the cache from one computer to another easily enough). Once the csprogs.dat has been loaded once, you can run that version without the csprogs.dat itself on the client computer, only the cached version. So you can revert back to the old one after you first run it. Mneh, its awkward. Implement downloading!

I just noticed, you'll need to remove entries from QSG_Extensions in pr_bgcmd.c

Ok.

Btw, I'm got Avirox's to compile. As long as I have something. I'll compile my own fteqcc here in a bit.

Update: Ok, I guess I'll have to do the compiling fteqcc myself thing now.



I get this with the csqcglquake.exe when running csqcglquake -game gui -window with the Avirox csprogs.dat I compiled using the standard issue fteqcc.

I put the csprogs.dat in quake/gui folder and used -game gui

I remember creating a topic about movement prediction in CSQC.

How can that be done without modification to Quake's network protocol?

Well, I can imagine it could be done, but you'd end up chopping about every few frames..

tbh, most of the tests I made with csqctest were done with temporary code in the relevent places.
Tbh... stick with avirox's code for the most part. :)