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

Joined: 21 Sep 2009 Posts: 136 Location: North West Oregon, USA
|
Posted: Tue Apr 27, 2010 6:22 am Post subject: 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:
Code: | 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: | 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! |
|
Back to top |
|
 |
Lardarse

Joined: 05 Nov 2005 Posts: 243 Location: Bristol, UK
|
Posted: Tue Apr 27, 2010 3:14 pm Post subject: |
|
|
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. _________________ <ekiM> Son, you're writing data structures your CPU can't cache. |
|
Back to top |
|
 |
Spike
Joined: 05 Nov 2004 Posts: 944 Location: UK
|
Posted: Tue Apr 27, 2010 7:14 pm Post subject: |
|
|
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'. _________________ What's a signature? |
|
Back to top |
|
 |
Junrall

Joined: 21 Sep 2009 Posts: 136 Location: North West Oregon, USA
|
Posted: Tue Apr 27, 2010 9:59 pm Post subject: |
|
|
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! |
|
Back to top |
|
 |
Spike
Joined: 05 Nov 2004 Posts: 944 Location: UK
|
Posted: Tue Apr 27, 2010 11:13 pm Post subject: |
|
|
constants can be packed as '1 2 7' if you wanted to pass 3 floats. :) _________________ 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
|