Inside3D!
     

CSQC Enhanced GLQuake Attempt #1
Goto page Previous  1, 2
 
Post new topic   Reply to topic    Inside3d Forums Forum Index -> Engine Programming
View previous topic :: View next topic  
Author Message
Baker



Joined: 14 Mar 2006
Posts: 1538

PostPosted: Sun Jan 24, 2010 12:29 pm    Post subject: Reply with quote

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
View user's profile Send private message
mh



Joined: 12 Jan 2008
Posts: 909

PostPosted: Mon Jan 25, 2010 10:49 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Teiman



Joined: 03 Jun 2007
Posts: 309

PostPosted: Tue Jan 26, 2010 10:46 am    Post subject: Reply with quote

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
View user's profile Send private message
Spike



Joined: 05 Nov 2004
Posts: 944
Location: UK

PostPosted: Tue Jan 26, 2010 12:32 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
avirox



Joined: 16 Aug 2006
Posts: 109

PostPosted: Wed Jan 27, 2010 12:25 am    Post subject: Reply with quote

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
View user's profile Send private message
frag.machine



Joined: 25 Nov 2006
Posts: 728

PostPosted: Wed Jan 27, 2010 12:52 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Sajt



Joined: 16 Oct 2004
Posts: 1026

PostPosted: Wed Jan 27, 2010 2:59 am    Post subject: Reply with quote

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
View user's profile Send private message
mh



Joined: 12 Jan 2008
Posts: 909

PostPosted: Wed Jan 27, 2010 9:57 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
metlslime



Joined: 05 Feb 2008
Posts: 177

PostPosted: Thu Jan 28, 2010 12:13 am    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    Inside3d Forums Forum Index -> Engine Programming All times are GMT
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
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