Forum

Passing Several Variables - How Many Is Too Many?

Discuss programming in the QuakeC language.

Moderator: InsideQC Admins

Passing Several Variables - How Many Is Too Many?

Postby Junrall » Tue Apr 27, 2010 6:22 am

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: 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!
User avatar
Junrall
 
Posts: 191
Joined: Mon Sep 21, 2009 12:27 am
Location: North West Oregon, USA

Postby Lardarse » Tue Apr 27, 2010 3:14 pm

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.
Roaming status: Testing and documentation
User avatar
Lardarse
 
Posts: 266
Joined: Sat Nov 05, 2005 1:58 pm
Location: Bristol, UK

Postby Spike » Tue Apr 27, 2010 7:14 pm

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'.
Spike
 
Posts: 2892
Joined: Fri Nov 05, 2004 3:12 am
Location: UK

Postby Junrall » Tue Apr 27, 2010 9:59 pm

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!
User avatar
Junrall
 
Posts: 191
Joined: Mon Sep 21, 2009 12:27 am
Location: North West Oregon, USA

Postby Spike » Tue Apr 27, 2010 11:13 pm

constants can be packed as '1 2 7' if you wanted to pass 3 floats. :)
Spike
 
Posts: 2892
Joined: Fri Nov 05, 2004 3:12 am
Location: UK


Return to QuakeC Programming

Who is online

Users browsing this forum: No registered users and 1 guest