Cvar Simplification
Moderator: InsideQC Admins
3 posts
• Page 1 of 1
Cvar Simplification
The Quake cvar system requires at least 3 places to set up a cvar.
1) Define the cvar like r_whatever = {"r_whatever", 0, CVAR_SERVER}; or some variation.
2) Add it to .h file
3) Register it.
I'm been blue-skying with another approach. The first of this obvious.
But inherently this single point definition method will be possibly a fair performance hit:
The Cvars_Get stuff will have to cycle through all cvars, find the location and return the variable in string form or float form. Every time.
Now one natural solution to this would onerously be something like this:
But that is a lot more work than desired. Just to have the equivalent of something like view_idle_scale.value available.
Right now, I'm thinking of an inline function. I don't really know what the compiler limits are with those, but I bet the compiler does
Either it works or it doesn't
Maybe something like ...
And then writing some #define to generate these sort functions on the fly within a statement.
I'm not sure if what I am thinking here can aesthetically be achieved in a non-burdensome way. But it is worth a shot.
1) Define the cvar like r_whatever = {"r_whatever", 0, CVAR_SERVER}; or some variation.
2) Add it to .h file
3) Register it.
I'm been blue-skying with another approach. The first of this obvious.
- Code: Select all
cvars_t cvars[] =
{
{"fov_x", "60" },
{"fov_y", "0" },
{"aspect", "1.33333" },
{"znear", "0.1" },
But inherently this single point definition method will be possibly a fair performance hit:
- Code: Select all
if (Cvars_GetFloat("view_idle_scale"))
{
vec3_t angles_idle = {0,0,0};
// Modify angles a bit
angles_idle[PITCH] -= Cvars_GetFloat("view_idle_scale") * sinf(Host.WorldClock * Cvars_GetFloat("view_idle_pitch_cycle")) * Cvars_GetFloat("view_idle_pitch_level");
angles_idle[YAW] -= Cvars_GetFloat("view_idle_scale") * sinf(Host.WorldClock * Cvars_GetFloat("view_idle_yaw_cycle")) * Cvars_GetFloat("view_idle_yaw_level");
angles_idle[ROLL] -= Cvars_GetFloat("view_idle_scale") * sinf(Host.WorldClock * Cvars_GetFloat("view_idle_roll_cycle")) * Cvars_GetFloat("view_idle_roll_level");
VectorAdd (angles, angles_idle, angles);
The Cvars_Get stuff will have to cycle through all cvars, find the location and return the variable in string form or float form. Every time.
Now one natural solution to this would onerously be something like this:
- Code: Select all
static float* view_idle_scale = Cvars_GetFloatAddress ("view_idle_scale");
But that is a lot more work than desired. Just to have the equivalent of something like view_idle_scale.value available.
Right now, I'm thinking of an inline function. I don't really know what the compiler limits are with those, but I bet the compiler does
Maybe something like ...
- Code: Select all
static inline float* Cvar_MagicAddress_view_idle_scale (void)
{
static float* myaddress = Cvars_GetFloatAddress ("view_idle_scale");
return myaddress;
}
And then writing some #define to generate these sort functions on the fly within a statement.
I'm not sure if what I am thinking here can aesthetically be achieved in a non-burdensome way. But it is worth a shot.
The night is young. How else can I annoy the world before sunsrise?
Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
-

Baker - Posts: 3666
- Joined: Tue Mar 14, 2006 5:15 am
Re: Cvar Simplification
most compilers ignore the 'inline' keyword. if you're using gcc, 'static' functions are more likely to be inlined than inline functions.
Q2 used Cvar_Get throughout, with the result saved somewhere if performance was required. The primary advantage of doing so is that it then means renderers can consistantly get/register cvars independantly of each other/the engine, while with the Q1 aproach if its registered then its data must be at the given location.
(basically, cvar_get accepts name, default value, flags, etc, and returns a pointer to the cvar, if it doesn't already exist then its created, otherwise its merely returned, so Cvar_Find with register capability).
If you really need to, you can perform a binary search on cvar names or just use a hash table in order to accelerate your Cvar_Find functionality, but if you're doing it more than once per map, you're better off caching the address.
Try:
#define LOCALCVAR(n,d,f) static cvar_t *n; if (!n) n = Cvar_Get(#n, d, f)
float somerandomfunctionthatreturnssomevalue(void)
{
LOCALCVAR(myvar, "defaultvalue", CVAR_SOMEFLAGS);
return myvar->value;
}
will define a cvar, register it the first time the function is execed, and be reasonably speedy the other times, while hiding what its doing away from prying eyes.
Requires C99/C++ though.
Or you could use a constructor in C++ to create the cvar when it comes into scope (or just use static to make that scope a bit more global), though you'd need some decent methods.
imho preprocessor magic isn't really any worse than classes, so long as you don't use it in public APIs...
Q2 used Cvar_Get throughout, with the result saved somewhere if performance was required. The primary advantage of doing so is that it then means renderers can consistantly get/register cvars independantly of each other/the engine, while with the Q1 aproach if its registered then its data must be at the given location.
(basically, cvar_get accepts name, default value, flags, etc, and returns a pointer to the cvar, if it doesn't already exist then its created, otherwise its merely returned, so Cvar_Find with register capability).
If you really need to, you can perform a binary search on cvar names or just use a hash table in order to accelerate your Cvar_Find functionality, but if you're doing it more than once per map, you're better off caching the address.
Try:
#define LOCALCVAR(n,d,f) static cvar_t *n; if (!n) n = Cvar_Get(#n, d, f)
float somerandomfunctionthatreturnssomevalue(void)
{
LOCALCVAR(myvar, "defaultvalue", CVAR_SOMEFLAGS);
return myvar->value;
}
will define a cvar, register it the first time the function is execed, and be reasonably speedy the other times, while hiding what its doing away from prying eyes.
Requires C99/C++ though.
Or you could use a constructor in C++ to create the cvar when it comes into scope (or just use static to make that scope a bit more global), though you'd need some decent methods.
imho preprocessor magic isn't really any worse than classes, so long as you don't use it in public APIs...
- Spike
- Posts: 2892
- Joined: Fri Nov 05, 2004 3:12 am
- Location: UK
Re: Cvar Simplification
Q1 needs to walk the cvar list for Cvar_Set(Value) already. DirectQ does the C++ self-registering cvars thing but the registration function needs to check if Zone memory is up yet (and init it if not) because these run before the program entry point. It seems as though you can register cvars at any time you want, even while a map is running, so Q2's Cvar_Get should be do-able. Beware of Cmd_AddCommand - it allocates the cmd_t on the Hunk so if you add one while a map is running it's memory will be wiped in Host_ClearMemory. Or just put them in a different memory area (or just malloc them).
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for
-

mh - Posts: 2292
- Joined: Sat Jan 12, 2008 1:38 am
3 posts
• Page 1 of 1
Who is online
Users browsing this forum: No registered users and 1 guest