Differences between Q1, Quake World and Net codebases (qc)

Discuss programming topics for any language, any source base. If it is programming related but doesn't fit in one of the below categories, it goes here.
Post Reply
Spirit
Posts: 1065
Joined: Sat Nov 20, 2004 9:00 pm
Contact:

Differences between Q1, Quake World and Net codebases (qc)

Post by Spirit »

Since the original thread was taken over by fruitless arguing I locked it. The following is my attempt to recover the actual content. Please tell me if I missed something. Please continue using this thread for discussing this question.
JasonX wrote:What is the difference between the QuakeC codebase of Quake, Quake World and NetQuake?
leileilol wrote:Quake's a dumb client.
Quakeworld is not. It tries to extrapolate from what it recieves instead and relies more on broadcast messages.

Also Quakeworld generally strips a lot of things, so if you love particle() and punchangles, you're going to have to adjust.
r00k wrote:Dumb meaning its not intelligent in terms of latency prediction. Though, it's all i've used for quake1. Since movement/shots fired are sync'd u dont seem to notice much sub 50 ping. In QW u can run around like a freakin hippy at a nudist colony but have to wait for latency to get your shots out, which seem to come late but hit direct, something odd about that gameplay. QW mods though are WAY behind the times. CTF is not active and CA uses 1997 code :( bluh plain f'ugly.

EDIT: KTX is not a QuakeC mod, so this is the exception!
Spike wrote:the differences between the qc code is that qw mods are not generally allowed to affect the player's movement (jump heights, swim speed, etc) without asking the engine to do it for it (ie: .gravity and .maxspeed instead of dumping code in playerpostthink). This is because the client needs to match, and if it doesn't then you get juddery movement/jumps.
qw qc code avoids the use of MSG_BROADCAST. Its available, but its better to use MSG_MULTICAST (really though, you're better off using the proper extension builtin instead of directly using WriteByte).
qw qc code doesn't support particle(). there are some replacement TE_foo effects for commonly used effects, but that's pretty much just blood.
qw's te_gunshot has a count argument, resulting in a single te_foo in quakeworld where you'd have 12 separate bandwidth suckers in nq.
qw qc code permits multiple thinks on a single entity in a single frame, keeping timing more correct even with an overburdened server (other programs stealing cpu etc).
qw qc code runs players out of order (when handling packets received from the client) instead of all ents thinking in entnum order. Note that DP defaults to be more like QW here, its just a sideeffect of prediction.
svc_setview does not exist in quakeworld. spectators are an engine feature and mods do not need to do anything for them.
vanilla quakeworld does not support .spawnflags based spawn filters - it'll always act as if deathmatch 1 is set. custom qw engines have reverted to nq behaviour here.
quakeworld has userinfo stuff, which permits per-user settings and options which are readable by the gamecode. nq depends fully upon settings stored on the server.

most qw mods do not support single player (see .spawnflags comment). the server still supports all the builtins the ai uses, just that most mods lack monsters and thus lack ai too. quakeworld's traditional only-dedicated-servers stance kinda removes the need for single player support in mods.

for a full list of the differences between nq and qw (and h2) gamecode, see FTE's progstype variable. :P

in general the changes required to convert a mod from nq to qw equate to: replacing defs.qc for the qw systemdefs/systemfields/builtins, removing the .velocity changes in client.qc, particle() -> te_[lightning]blood, .punchangles->svc_big/smallkick, EF_MUZZLEFLASH->svc_muzzleflash, te_gunshot -> te_gunshot+writebyte(count), bprint(msg)->bprint(PRINT_HIGH,msg), svc_cdtrack changes, svc_intermission changes.
certain mods have additional dependancies (eg: svc_setview), but the above should cover vanilla qc.
for much of it you can use #ifdefs with fteqcc or frikqcc and write a mod that directly supports either.
JasonX wrote:(...) while being a dumb client certainly makes things easy for modding (less places to put your hands on), is the QuakeWorld codebase better for networking? Specifically, coop? Or the difference is not that big?
Spike wrote:JasonX, the gamecode is not that different between NQ and QW. The changes are really only there because they're imposed by the engine changes. Regarding qc changes, see my first post in this topic.

the quakeworld engine will give you prediction, smaller packets, and lower latencies. but vanilla lacks interpolation so can be more jerky even when playing on a server on the same machine.
vanilla quakeworld doesn't support singleplayer (ie: you need a dedicated server and to have coop enabled to stop deathmatch getting enabled), and coop is buggy too (everything spawns as if deathmatch).
different engine projects have fixed different numbers of weak points.
Improve Quaddicted, send me a pull request: https://github.com/SpiritQuaddicted/Quaddicted-reviews
Post Reply