View previous topic :: View next topic |
Author |
Message |
Spike
Joined: 05 Nov 2004 Posts: 944 Location: UK
|
Posted: Thu Apr 23, 2009 3:56 pm Post subject: |
|
|
Urre wrote: | I doubt most will care in the end, but if you want to do things right, you would drop that requirement. Especially seeing you've already had software renderers as the main reason not to implement a bunch of graphics-specific features as part of the base spec. I'd say this is especially important if we are to see csqc really happen in engines on other platforms, like various handhelds and whatnot.
|
I was talking to div0, he suggested dithering. At 320*240 that might be a little too ugly perhaps? Not sure.
Either way, there'll need to be a fast route for default params.
But yeah, there's no way you can reasonably require csqc to support rgb blending. drawfill must support colours, but for others it doesn't really matter.
pics can be dithered I suppose. But I'm still not sure anyone would actually want that with a mod targeted for sw rendering.
Quote: |
Concerning the csqc->ssqc talk, have I got it right if I interpret your example as the first two parameters of the send function being the last two parts of the function name in the recieve function? Cause that seems pretty awesome. |
Yes, that was the idea. If the types are put in the same string as the name then you could use 7 args. Its probably simpler to keep them separate though. _________________ What's a signature? |
|
Back to top |
|
 |
Urre

Joined: 05 Nov 2004 Posts: 1073 Location: Sweden
|
Posted: Fri Apr 24, 2009 3:02 pm Post subject: |
|
|
I'm okay with either. Seems like a really cool idea. Someone tell LH to comment. _________________ Look out for Twigboy |
|
Back to top |
|
 |
LordHavoc
Joined: 05 Nov 2004 Posts: 243 Location: western Oregon, USA
|
Posted: Fri Apr 24, 2009 7:50 pm Post subject: |
|
|
I think it's easier to say "you can do anything", and then make it implementation-dependent how well it gets done.
These days even cell phones have shaders, nevermind merely blending.
So I'm disinclined to hold back anything because of software, because the number of people using it is too small.
Regarding speed - you actually can do palette lookups, real blending math in 15bit color, and then palette lookups of the 15bit colors afterward and store it back into 8bit, sure this does eat into framerate but I see no choice.
Even glquake computed such a 15bit->8bit table at load for 8bit mipmaps. |
|
Back to top |
|
 |
metlslime
Joined: 05 Feb 2008 Posts: 177
|
Posted: Sun Apr 26, 2009 9:29 am Post subject: |
|
|
where is the spec, anyway? Is it he one on the quake wiki? Is that spec actually current? (i won't ask if it's complete, since whole sections are missing ) |
|
Back to top |
|
 |
Spike
Joined: 05 Nov 2004 Posts: 944 Location: UK
|
Posted: Mon Apr 27, 2009 10:36 am Post subject: |
|
|
metlslime wrote: | where is the spec, anyway? Is it he one on the quake wiki? Is that spec actually current? (i won't ask if it's complete, since whole sections are missing :) ) |
http://www.fteqw.com/wiki/index.php?title=EXT_CSQC
That's a link to a copy of the original spec which was originally hosted on quakesrc.org's wiki.
That spec is not current, and never really was current (it always had inaccuracies). It was written as part of my initial design, in an attempt to get people to comment upon it. However, walls of text and all that means not too many people responded.
I personally failed to keep it up to date as I added additional useful bits and bobs to FTE. To be honest, not all of it should really be part of the base spec.
For the differences between implementation, that spec is favoured over any specific engine (eg: stats in FTE used "names" rather than field references when first implemented).
That spec, being work-in-progress skipped many builtin #indexes, and at no point claimed to give a definitive sys globals/fields list for a specific progs CRC. It certainly never listed any functions as mandatory, unlike DP.
At this time, FTE adheres more closely to that spec. However there are differences and additions.
Really the important difference between that EXT_CSQC preliminary spec and EXT_CSQC_1 is that the view width/height comes from parameters to the draw function, not via cvars. Nothing else that changed is really used in anything but my own test mods.
I'm trying to update the spec to EXT_CSQC_1. But so far I've probably missed half the stuff.
[url="http://fteqw.svn.sourceforge.net/viewvc/fteqw/trunk/quakec/csqctest/src/"]This is probably the most accurate documentation of EXT_CSQC_1 at the moment.[/url] But still work in progress.
I'll put my spec docs up there somewhere when its more complete, along with patches for my csqc[win/gl]quake when that is fully compliant.
The spec that is on quakedev is in no way official. Generally it is written based upon common use, rather than best-practise, thus much of it is DP specific or outdated (eg: conwidth). Accept it as a quick guide for now, and use the quakesrc.org version as more complete docs - just combine it with a working csqcdefs.qc file for your engine of choice.
Urre: as a side note, I suppose that with the clientrequest feature, the server doesn't need to support KRIMZON_SV_PARSECLIENTCOMMAND. I know someone who hates this extension enough to completely ignore it. The string builtins will probably still be needed. Just no mandatory clientcmd builtin on the server. _________________ What's a signature? |
|
Back to top |
|
 |
Urre

Joined: 05 Nov 2004 Posts: 1073 Location: Sweden
|
Posted: Mon Apr 27, 2009 10:52 am Post subject: |
|
|
Spike wrote: | Urre: as a side note, I suppose that with the clientrequest feature, the server doesn't need to support KRIMZON_SV_PARSECLIENTCOMMAND. I know someone who hates this extension enough to completely ignore it. The string builtins will probably still be needed. Just no mandatory clientcmd builtin on the server. |
That is indeed a valid point. I quite dislike using it as well. _________________ Look out for Twigboy |
|
Back to top |
|
 |
metlslime
Joined: 05 Feb 2008 Posts: 177
|
Posted: Tue Apr 28, 2009 9:38 am Post subject: |
|
|
so i'm just reading through this, and I realize that some of the spec is obsolete so some of these questions may be moot.
- why require vid_conwidth and vid_conheight cvars for the extension? Since cvars are a user-facing feature, and aren't consistent across engines, it would be better to have csqc-facing feature like globals or builtins to fetch the window size.
- i see you have to add engine ents every frame before drawing; is this true for csqc entities too?
- the capitalization and prefixes of function names seems very inconsistent in the spec, is that how they are implemented? (CSQC_*, csqc_*, cs_*, R_*, CL_*, etc.)
- is the CSQC vm active when playing back a demo?
- the function "isserver" implies that, when running a listen server or single-player game, mods are encouraged to use cvars as a client-server communications technique. Is the nework protocol clunky enough that a modder wouldn't want to use it?
- why expose R_ClearScene to the qc? Do you forsee a desire for mods to NOT clear the scene, resulting in intentional hall-of-mirrors effects? Or is this intended to clear the entity list? And if so, does this mean you don't have to clear the entity list between frames if you don't want to?
- why have both DrawCharacter and DrawString? Is it because qc has no easy way to cast a number to a single-character string?
- why have CL_is_cached_pic and CL_free_pic, does the quakec need to be in charge of resource management?
- is the assumption that the scene and HUD use the entire window regardless of user's viewsize preferences? Or should the engine handle viewsize transparently to the csqc?
- is it correct to say that if a ssqc wants to send custom information to a csqc, it has to send it in the form of entities? i.e. entities are the only sendable data type?
- is there any way for csqc to send custom messages back to the server?
- what's the difference between CSQC_UpdateView and CSQC_Draw?
- why is SendEntity a .float instead of a .void()?
Oh, here's a feature idea i just had: Allow the csqc to override certain engine effects, such as particle() and the various temp effects/beams. So if the csprogs.dat exports certain named functions, the engine will call those instead of running its own hard-coded effects. This would include the ability to spawn individual particles and give them velocities and stuff. |
|
Back to top |
|
 |
Spike
Joined: 05 Nov 2004 Posts: 944 Location: UK
|
Posted: Tue Apr 28, 2009 10:37 am Post subject: |
|
|
metlslime wrote: | so i'm just reading through this, and I realize that some of the spec is obsolete so some of these questions may be moot.
|
- why require vid_conwidth and vid_conheight cvars for the extension? Since cvars are a user-facing feature, and aren't consistent across engines, it would be better to have csqc-facing feature like globals or builtins to fetch the window size.
*this was already changed in ext_csqc_1. width and height are now parameters to CSQC_Draw.
- i see you have to add engine ents every frame before drawing; is this true for csqc entities too?
*Yes, entities are added by a mask. You can add both sets of ents in a single call.
- the capitalization and prefixes of function names seems very inconsistent in the spec, is that how they are implemented? (CSQC_*, csqc_*, cs_*, R_*, CL_*, etc.)
*CSQC_ functions are system functions called by name from the engine. Any other prefixes should be stripped.
- is the CSQC vm active when playing back a demo?
*Yes. But it may not be the csprogs that it was recorded with, if that one is not known to the client (loaded via hash).
- the function "isserver" implies that, when running a listen server or single-player game, mods are encouraged to use cvars as a client-server communications technique. Is the nework protocol clunky enough that a modder wouldn't want to use it?
*Its more for admin interactions. Note that there is no 'islocalclient' on the server.
- why expose R_ClearScene to the qc? Do you forsee a desire for mods to NOT clear the scene, resulting in intentional hall-of-mirrors effects? Or is this intended to clear the entity list? And if so, does this mean you don't have to clear the entity list between frames if you don't want to?
*Clearing the scene is defined as wiping the entity list and resetting view properties to defaults. Renderview resets nothing. This allows you to, for instance, draw the main view, flip the angles, and draw a reverse view. But yeah, that's flawed because then you get a second view model. It does not blank the screen. Depth is cleared as part of rendering the scene.
You can just draw 2d stuff without clearing anything instead if you want a 2d game.
- why have both DrawCharacter and DrawString? Is it because qc has no easy way to cast a number to a single-character string?
*Basically.
- why have CL_is_cached_pic and CL_free_pic, does the quakec need to be in charge of resource management?
*Simple reason: menu.dat has them.
2d stuff is an derivative of the menu's 2d stuff. They use the same builtins internally.
- is the assumption that the scene and HUD use the entire window regardless of user's viewsize preferences? Or should the engine handle viewsize transparently to the csqc?
*CSQC is expected to handle viewsize itself. Clearscene sets the view to the viewsize view, but HUDs are awkward.
Personally I think the engine's hud should always draw as size 100, but without any backgrounds (eg: qw hud, or DP transparent hud).
This is a matter of contention.
- is it correct to say that if a ssqc wants to send custom information to a csqc, it has to send it in the form of entities? i.e. entities are the only sendable data type?
*Entities, stats, and stuffcmds.
- is there any way for csqc to send custom messages back to the server?
*Clientcommands+krimzon_sv_parseclientcommand was the intended way. See the above few posts for a cleaner way.
- what's the difference between CSQC_UpdateView and CSQC_Draw?
*Nothing, they're meant to be the same function, and have the same name.
- why is SendEntity a .float instead of a .void()?
*The server is permitted to reject sending of an entity to a given client, for some reason. Mostly for error handling. A compound entity that depends upon other ents that were removed can state that it should not be sent.
Quote: |
Oh, here's a feature idea i just had: Allow the csqc to override certain engine effects, such as particle() and the various temp effects/beams. So if the csprogs.dat exports certain named functions, the engine will call those instead of running its own hard-coded effects. This would include the ability to spawn individual particles and give them velocities and stuff. |
In the case of shotgun puffs/blood, a csqc ent can do things more efficiently, more reliably, and adhere to pvs/phs. Lightning beams can also be more efficient when they don't have to be sent 10 times a second. Explosions are already handled pretty well.
The only reason to provide access to temp entities is for legacy mods. Basically there's no advantage to it. Only potential abuses (nexuiz already abuses temp ents using a DP extension, which cannot be proxied cleanly). _________________ What's a signature? |
|
Back to top |
|
 |
Chris
Joined: 05 Aug 2006 Posts: 78
|
Posted: Tue Apr 28, 2009 7:00 pm Post subject: |
|
|
could csqc_1 ever assimilate menuqc into it and get rid of menuqc all together? |
|
Back to top |
|
 |
Urre

Joined: 05 Nov 2004 Posts: 1073 Location: Sweden
|
Posted: Tue Apr 28, 2009 9:40 pm Post subject: |
|
|
Chris: no, because menu qc stays loaded between map changes, whereas csqc does not.
Spike: please don't abide with menu qc's weird design (concerning the resource management among other things), update menu qc instead. _________________ Look out for Twigboy |
|
Back to top |
|
 |
Chris
Joined: 05 Aug 2006 Posts: 78
|
Posted: Wed Apr 29, 2009 1:56 am Post subject: |
|
|
I know that Urre, but that one ability why can that not carry over to just a component of csqc?
Besides then it'd much more easily be able to interface with the game logic code... |
|
Back to top |
|
 |
Spike
Joined: 05 Nov 2004 Posts: 944 Location: UK
|
Posted: Wed Apr 29, 2009 7:38 am Post subject: |
|
|
If the csprogs was loaded when there was no map, you'd be able to draw 3d scenes in the background, etc, so there is certainly an advantage to using csqc as a full menu.
csqc implements the same 2d drawing stuff as the menu simply for greater code reuse (it implements the same ssqc builtins for the same reason, supposedly).
menu.qc is not my spec to change.
Thinking about it, I don't like the 'predraw' function field either. Should be customdraw, and the csqc should need to do the addentity itself. :/ _________________ What's a signature? |
|
Back to top |
|
 |
Chris
Joined: 05 Aug 2006 Posts: 78
|
Posted: Wed Apr 29, 2009 8:10 am Post subject: |
|
|
so it sounds like you are more for than against csqc implementing the same concepts as menuqc? Is this a possibility?
As for the predraw thing I use it often enough and think it works nicely. It conceptually makes sense, where as the equivalent of render channels which is how I feel csqc is being pushed towards is a bit more difficult to grasp to people new to csqc and it could get a bit confusing. Although it definitely is nice in theory.
As for the csqc spec it sounds very feature heavy for new stuff already. Is there anything that you feel is really missing from csqc thus far outside of whats already been mentioned in this thread? |
|
Back to top |
|
 |
Spike
Joined: 05 Nov 2004 Posts: 944 Location: UK
|
Posted: Wed Apr 29, 2009 3:21 pm Post subject: |
|
|
Chris wrote: | so it sounds like you are more for than against csqc implementing the same concepts as menuqc? Is this a possibility?
|
The csprogs is closed and reloaded on each and every map change.
When the client disconnects, the csprogs is shut down entirely.
The csprogs *could* gain a feature where it is loaded at client start with a dummy environment, yes. But why, when the menu can do that too?
The advantage of the menu is that it is not shut down over map changes, and thus gets a chance to arbitrate scores and things.
Its not so far fetched that an engine could call CSQC_Init when it first starts up, and then uses calls to CSQC_WorldLoaded for each map change.
This would not actually violate the original spec, nor the revised one. Its just that WorldLoaded was not even part of the original spec.
Quote: |
As for the predraw thing I use it often enough and think it works nicely. It conceptually makes sense, where as the equivalent of render channels which is how I feel csqc is being pushed towards is a bit more difficult to grasp to people new to csqc and it could get a bit confusing. Although it definitely is nice in theory.
|
It was intended that you could interpolate/animate/project your model/origin based on direction and velocity in there. And that when your function returns, the ent is added to the lists.
One of the things csqc provides is that an entity can be added multiple times (and explicit addentity does not trigger predraw).
This allows adding segmented q3 models with a single entity. Although more likely to be used with powerup shells (q3 quads).
The code to do this is just ugly.
Quote: |
As for the csqc spec it sounds very feature heavy for new stuff already. Is there anything that you feel is really missing from csqc thus far outside of whats already been mentioned in this thread? |
Yeah, it has all these features, and you still can't do what you want with it!
But really, what's missing from it? For one, finalisation is missing. And that won't happen until I have a vanilla engine with nothing but csqc support in it.
Perhaps the most important thing is that think functions are missing. Movetypes/physics is intentionally missing. It was meant to be a separate extension at the time. This means that physics are not run. Nothing moves automatically.
Unfortunately, think functions are part of physics (yes, different movetypes get different think behaviour - MOVETYPE_PUSH with self.ltime). And because there's no physics, there's no thinks.
This isn't a fatal problem, as you can just use predraw and run custom physics/projection/thinks there. But still... _________________ What's a signature? |
|
Back to top |
|
 |
Spike
Joined: 05 Nov 2004 Posts: 944 Location: UK
|
Posted: Wed Apr 29, 2009 3:37 pm Post subject: |
|
|
And MVD control would be nice. _________________ What's a signature? |
|
Back to top |
|
 |
|
|
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
|