Passing Several Variables - How Many Is Too Many?
Moderator: InsideQC Admins
5 posts
• Page 1 of 1
Passing Several Variables - How Many Is Too Many?
My new QC pastime has been separating out chunks of code and grouping it into separate qc files. As I'm doing this I'm trying to modularized some of the redundancy into functions... hopefully making it easier/faster to add new items, weapons, monsters.
Currently I'm looking at modularizing item creation, but am wonder if there will be a gain in doing so. Here is an example
Original code for spawning shell boxes:
Not a whole lot there, but when you have several other items that are created in the same way there tends to be some redundancy that can be handled with one function.
Here is the same thing using a single function that can be used to create any item:
For me, this looks cleaner... and it will definitely reduce the number of lines of code to spawn several item types. However, I'm passing seven variables to the function CreateItem.
When does the number of variables being passed become a hindrance?
Currently I'm looking at modularizing item creation, but am wonder if there will be a gain in doing so. Here is an example
Original code for spawning shell boxes:
- Code: Select all
void() item_shells =
{
self.touch = ammo_touch;
if (self.spawnflags & WEAPON_BIG2)
{
precache_model ("maps/b_shell1.bsp");
setmodel (self, "maps/b_shell1.bsp");
self.aflag = 40;
}
else
{
precache_model ("maps/b_shell0.bsp");
setmodel (self, "maps/b_shell0.bsp");
self.aflag = 20;
}
self.weapon = 1;
self.netname = "shells";
setsize (self, '0 0 0', '32 32 56');
StartItem ();
};
Not a whole lot there, but when you have several other items that are created in the same way there tends to be some redundancy that can be handled with one function.
Here is the same thing using a single function that can be used to create any item:
- Code: Select all
void() item_shells =
{
if (self.spawnflags & WEAPON_BIG2)
CreateItem("maps/b_shell1.bsp", "shells", '0 0 0', '32 32 56', IT_SHELLS, 40, ammo_touch);
else
CreateItem("maps/b_shell0.bsp", "shells", '0 0 0', '32 32 56', IT_SHELLS, 20, ammo_touch);
};
For me, this looks cleaner... and it will definitely reduce the number of lines of code to spawn several item types. However, I'm passing seven variables to the function CreateItem.
When does the number of variables being passed become a hindrance?
Good God! You shot my leg off!
-

Junrall - Posts: 191
- Joined: Mon Sep 21, 2009 12:27 am
- Location: North West Oregon, USA
I don't know about being a hinderance, as such, but older compilers (pretty much anything other than FrikQCC or FTEQCC) have a limit of 8 function parameters. The 2 compilers that I mentioned can exceed this limit by using tricks involving global variables (which it handles behind teh scenes). Builtin functions have a hard limit of 8 parameters, though.
If I remember correctly, passing 1 variable to a function has the same overhead as passing 8 to a function, so don't worry about using all 8.
I will say, though, that if you wanted to be really clean, then instead of ammo boxes using .aflag you could have the correct .ammo_* field store that number. This would simplify the item pickup code, at the expense of making the item creation code more complicated.
It might be worth just passing model, netname, absmin, absmax, and possible touch function, and then specify the "payload" of the item just after that function call.
If I remember correctly, passing 1 variable to a function has the same overhead as passing 8 to a function, so don't worry about using all 8.
I will say, though, that if you wanted to be really clean, then instead of ammo boxes using .aflag you could have the correct .ammo_* field store that number. This would simplify the item pickup code, at the expense of making the item creation code more complicated.
It might be worth just passing model, netname, absmin, absmax, and possible touch function, and then specify the "payload" of the item just after that function call.
Roaming status: Testing and documentation
-

Lardarse - Posts: 266
- Joined: Sat Nov 05, 2005 1:58 pm
- Location: Bristol, UK
more than 8 arguments has an extra penalty, as its emulated.
with fteqcc and the '-tfte' argument, the first two arguments are really cheap.
Its not worth packing floats together into vectors, unless you are passing constants.
Tbh, 9+ variables isn't too bad, its just two extra copies instead of 0 if there were no args or 1 if it was one of the first 8.
An extra instruction or two really isn't going to make any difference, so long as your inner loops are kept simple...
Spawn code specifically is really not performance driven.
So yeah, the limit is 'however many it takes before the random list becomes unreadable'.
with fteqcc and the '-tfte' argument, the first two arguments are really cheap.
Its not worth packing floats together into vectors, unless you are passing constants.
Tbh, 9+ variables isn't too bad, its just two extra copies instead of 0 if there were no args or 1 if it was one of the first 8.
An extra instruction or two really isn't going to make any difference, so long as your inner loops are kept simple...
Spawn code specifically is really not performance driven.
So yeah, the limit is 'however many it takes before the random list becomes unreadable'.
- Spike
- Posts: 2892
- Joined: Fri Nov 05, 2004 3:12 am
- Location: UK
Lardarse wrote:I will say, though, that if you wanted to be really clean, then instead of ammo boxes using .aflag you could have the correct .ammo_* field store that number. This would simplify the item pickup code, at the expense of making the item creation code more complicated.
It might be worth just passing model, netname, absmin, absmax, and possible touch function, and then specify the "payload" of the item just after that function call.
I agree with not using .aflag... as it's not very descriptive. I am using ammo_amount... but after reading your response I think I like ammo_payload better... or maybe just "payload" to shorten it.
I will also be adding ammo_payload to each of the weapons as well... should help with handling ammo checks and distribution.
Spike wrote:So yeah, the limit is 'however many it takes before the random list becomes unreadable'.
Lol, when I first toyed with this idea I did have a couple of functions that were a confusing list of passed variables! I think I'll stick with about 7 or 8 variables at most.
Now that I have had several hours of a break, the CreateItem function doesn't look so bad after all.
Spike wrote:Its not worth packing floats together into vectors, unless you are passing constants.
I had thought about doing this for another "hair-brain" idea.
Why constants only?
Good God! You shot my leg off!
-

Junrall - Posts: 191
- Joined: Mon Sep 21, 2009 12:27 am
- Location: North West Oregon, USA
5 posts
• Page 1 of 1
Who is online
Users browsing this forum: No registered users and 1 guest