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

Joined: 14 Mar 2006 Posts: 1538
|
Posted: Sun Jan 24, 2010 12:29 pm Post subject: |
|
|
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. _________________ Tomorrow Never Dies. I feel this Tomorrow knocking on the door ... |
|
Back to top |
|
 |
mh

Joined: 12 Jan 2008 Posts: 909
|
Posted: Mon Jan 25, 2010 10:49 pm Post subject: |
|
|
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. _________________ DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines |
|
Back to top |
|
 |
Teiman
Joined: 03 Jun 2007 Posts: 309
|
Posted: Tue Jan 26, 2010 10:46 am Post subject: |
|
|
mh wrote: | 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. |
|
Back to top |
|
 |
Spike
Joined: 05 Nov 2004 Posts: 944 Location: UK
|
Posted: Tue Jan 26, 2010 12:32 pm Post subject: |
|
|
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. _________________ What's a signature? |
|
Back to top |
|
 |
avirox
Joined: 16 Aug 2006 Posts: 109
|
Posted: Wed Jan 27, 2010 12:25 am Post subject: |
|
|
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! |
|
Back to top |
|
 |
frag.machine

Joined: 25 Nov 2006 Posts: 728
|
Posted: Wed Jan 27, 2010 12:52 am Post subject: |
|
|
mh wrote: | 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: |
@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). _________________ frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/ |
|
Back to top |
|
 |
Sajt
Joined: 16 Oct 2004 Posts: 1026
|
Posted: Wed Jan 27, 2010 2:59 am Post subject: |
|
|
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... _________________ F. A. Špork, an enlightened nobleman and a great patron of art, had a stately Baroque spa complex built on the banks of the River Labe. |
|
Back to top |
|
 |
mh

Joined: 12 Jan 2008 Posts: 909
|
Posted: Wed Jan 27, 2010 9:57 am Post subject: |
|
|
frag.machine wrote: | mh wrote: | 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: |
@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. _________________ DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines |
|
Back to top |
|
 |
metlslime
Joined: 05 Feb 2008 Posts: 177
|
Posted: Thu Jan 28, 2010 12:13 am Post subject: |
|
|
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. |
|
Back to top |
|
 |
|