CSQC Enhanced GLQuake Attempt #1

[Baker]

My time is sketchy the next few days, but regardless this is definitely a significant first step towards "more".

Now that I understand the fundamentals of the engine part of it and since now I can run the csprogs.dat, I can now look at the csqc source.

Just the possibilities of being able to code HUD type stuff in CSQC is something I consider major ... it is difficult to really imagine the possibilities but they are huge.

The Quake HUD is great for Quake, but sucks for total conversions and sbar.c is a pain.

Yes in the current state of csqcwinquake, there are some things that need overcome, incompleteness and such but when I do get time to continue the porting effort and double checking everything and adding it to a modified FitzQuake 0.85 and a modified JoeQuake, I can imagine this gaining tremendous momentum.

Allowing QuakeC coders to make their own HUDs and forth ... even the idea of being able to tweak HUDs without recompiling an engine is extremely compelling. I mean we've been stuck with the Quake HUD and the "hipnotic" Quake HUD forever. I can imagine even in the context of Quake some very great HUDS that in the past weren't worth bothering to think of that could be possible now after all the issues are worked out.

[mh]

Stupid question: is there any reason why a separate csprogs.dat is even needed at all? Could csqc functionality not be included in a standard progs.dat which is accessible in SP games via an extern, and in MP by calling PR_LoadProgs?

I may be missing something obvious here, but I'm thinking that this approach would make wider implementation much easier for everyone.

[Teiman]

Stupid question: is there any reason why a separate csprogs.dat is even needed at all? Could csqc functionality not be included in a standard progs.dat which is accessible in SP games via an extern, and in MP by calling PR_LoadProgs?

I may be missing something obvious here, but I'm thinking that this approach would make wider implementation much easier for everyone.

Heres a good reason for you:
Some mods are already colliding with the limits of the progs.dat format.

[Spike]

quake is archetectuarly a multiplayer game, even in single player.
it is somewhat desirable to ensure that mutliplayer can be tested in single player as far as possible.
yes, it would be easier to implement it into the engine, although the engine is only half the effort.

With the full range of optimisations in frikqcc, fteqcc, or even qfcc, progs limits are not really a concern, imho.
It might be plausable to make a simple version that just switches globals and edicts around based on whether its meant to be csqc or ssqc that is running, but its hardly elegant.

[avirox]

I'm wondering if this project can be translated to the PSP after it's working. That would make the possibilities on that platform so much more. Keep up the good work!

[frag.machine]

Stupid question: is there any reason why a separate csprogs.dat is even needed at all? Could csqc functionality not be included in a standard progs.dat which is accessible in SP games via an extern, and in MP by calling PR_LoadProgs?

I may be missing something obvious here, but I'm thinking that this approach would make wider implementation much easier for everyone.

I was thinking about the same thing other day, something like this could be used:

Code: Select all

@clientside
void (float foobar) myClientSideFancyCode =
{
// here goes the code
};


Where the @clientside notation tells to the compiler (and thus to the engine) that this function should be executed in the client scope, and both SVQC and CSQC can coexist in the same binary file (and even the same source code).

[Sajt]

You could always keep a directory of "common" QuakeC files, each used by both CSQC and SVQC (included in both progs.src).

Otherwise you're starting to approach UnrealScript and "replication" which can get extremely complicated...

[mh]

Stupid question: is there any reason why a separate csprogs.dat is even needed at all? Could csqc functionality not be included in a standard progs.dat which is accessible in SP games via an extern, and in MP by calling PR_LoadProgs?

I may be missing something obvious here, but I'm thinking that this approach would make wider implementation much easier for everyone.

I was thinking about the same thing other day, something like this could be used:

Code: Select all

@clientside
void (float foobar) myClientSideFancyCode =
{
// here goes the code
};


Where the @clientside notation tells to the compiler (and thus to the engine) that this function should be executed in the client scope, and both SVQC and CSQC can coexist in the same binary file (and even the same source code).

That's pretty much the way I was thinking as well, either tagging functions or using a namespace to enforce separation.

[metlslime]

well, the client and server entry points are different, so why not let them share the same namespace/scope/whatever? There might be a handful of functions that are useful to both. I guess they would have a different set of globals, though.

Anyway, i suppose the main issue that someone already mentioned is that if there is an engine-enforced limit to code size (or number of Xs), then combining them means you hit that limit a lot sooner. On the other hand, only custom engines will support csqc so they could just raise the apporporiate limits to eliminate that issue.