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

Joined: 21 Sep 2009 Posts: 136 Location: North West Oregon, USA
|
Posted: Tue Mar 09, 2010 6:45 am Post subject: $frames and self.frame |
|
|
I understand that in the following frames:
Code: | $frame axrun1 axrun2 axrun3 axrun4 axrun5 axrun6
$frame rockrun1 rockrun2 rockrun3 rockrun4 rockrun5 rockrun6 |
axrun1 is the same as self.frame == 0 and rockrun6 is the same as self.frame == 11.
Can I delete all of the frame macros and just reference self.frame as numbers?
And if I place
Code: | $frame rockrun1 rockrun2 rockrun3 rockrun4 rockrun5 rockrun6 |
before
Code: | $frame axrun1 axrun2 axrun3 axrun4 axrun5 axrun6 |
Will axrun1 be the same as self.frame == 0 and rockrun6 the same as self.frame == 11?
Thanks in advance! _________________ Good God! You shot my leg off! |
|
Back to top |
|
 |
Error Inside3D Staff

Joined: 05 Nov 2004 Posts: 558 Location: VA, USA
|
Posted: Tue Mar 09, 2010 7:34 am Post subject: |
|
|
yes, you can delete all the frame macros and just reference the numbers.
if you place the rockrun frames before the axrun frames... then $axrun1 is no longer equal to frame 0, $rockrun1 becomes 0. _________________ Inside3D : Knowledge Is Power
Darkplaces Documentation Wiki |
|
Back to top |
|
 |
Spike
Joined: 05 Nov 2004 Posts: 944 Location: UK
|
Posted: Tue Mar 09, 2010 9:15 am Post subject: |
|
|
$frame f1 f2
$f1 = 0
$f2 = 1
$frame f2 f1
$f2 = 0
$f1 = 1
order matters.
each new frame macro that is defined has a value 1 higher than the previous one that was defined. they are all expanded by the compiler to be floating point immediates. you can use a frame macro anywhere that you can use a numeric constant, and vice versa, because that is all that they are. _________________ What's a signature? |
|
Back to top |
|
 |
Junrall

Joined: 21 Sep 2009 Posts: 136 Location: North West Oregon, USA
|
Posted: Tue Mar 09, 2010 3:14 pm Post subject: |
|
|
Very cool!
So, if the macros are deleted, then where does Quake get the ordering number of each frame? Is it based on the order of the frames in the actual model? _________________ Good God! You shot my leg off! |
|
Back to top |
|
 |
frag.machine

Joined: 25 Nov 2006 Posts: 728
|
Posted: Tue Mar 09, 2010 4:10 pm Post subject: |
|
|
Junrall wrote: | Very cool!
So, if the macros are deleted, then where does Quake get the ordering number of each frame? Is it based on the order of the frames in the actual model? |
If you delete the macros definition but still using it in your code the compiler will just complain about undefined macros "$walk1" or whatever it's the name. _________________ frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/ |
|
Back to top |
|
 |
Junrall

Joined: 21 Sep 2009 Posts: 136 Location: North West Oregon, USA
|
Posted: Wed Mar 10, 2010 3:14 am Post subject: |
|
|
frag.machine wrote: |
If you delete the macros definition but still using it in your code the compiler will just complain about undefined macros "$walk1" or whatever it's the name. |
Yep, I found that out through slice and dice techniques!
I have deleted all of the player macros and commented out all references to "$framewhatever"... and was able to compile without any errors... and, after having done this, I am still able to animate the player standing frames by using self.frame with 12 through 16. This leads me to believe that, without macros, the order of the frames within the model determines the "order number" of each frame. Is this correct?
The only downfall that I can see with using numbers rather than $frame references is that it'll be a bit harder to follow what is being animated... though, good commenting should solve this problem.
The advantage to not using frame macros is that there will be less data stored into progs.dat file... and you don't have to make sure they are listed before some code that references them. _________________ Good God! You shot my leg off! |
|
Back to top |
|
 |
Downsider

Joined: 16 Sep 2008 Posts: 478
|
Posted: Wed Mar 10, 2010 3:46 am Post subject: |
|
|
In my QC stuff I just have a function like animatePlayer (start, end, loop); and throw a comment next to it stating what the frames actually are. |
|
Back to top |
|
 |
frag.machine

Joined: 25 Nov 2006 Posts: 728
|
Posted: Wed Mar 10, 2010 12:22 pm Post subject: |
|
|
Junrall wrote: | I have deleted all of the player macros and commented out all references to "$framewhatever"... and was able to compile without any errors... and, after having done this, I am still able to animate the player standing frames by using self.frame with 12 through 16. This leads me to believe that, without macros, the order of the frames within the model determines the "order number" of each frame. Is this correct? |
Yes.
Junrall wrote: | The only downfall that I can see with using numbers rather than $frame references is that it'll be a bit harder to follow what is being animated... though, good commenting should solve this problem. |
I still don't think it's a good programming practice, but... It's up to you. It's your code.
Junrall wrote: | The advantage to not using frame macros is that there will be less data stored into progs.dat file... and you don't have to make sure they are listed before some code that references them. |
Are you running in progs.dat size problems ? Even if it's the case, you should consider using an engine with extended limits like Darkplaces or FitzQuake. If not, I don't see any advantage at all. _________________ frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/ |
|
Back to top |
|
 |
Wazat
Joined: 15 Oct 2004 Posts: 732 Location: Middle 'o the desert, USA
|
Posted: Thu Mar 11, 2010 4:53 am Post subject: |
|
|
Wait, are frame macros stored in the progs? I assumed they were like #defines, replaced during compilation and not stored in the compiled progs.dat. _________________ When my computer inevitably explodes and kills me, my cat inherits everything I own. He may be the only one capable of continuing my work. |
|
Back to top |
|
 |
Downsider

Joined: 16 Sep 2008 Posts: 478
|
Posted: Thu Mar 11, 2010 5:23 am Post subject: |
|
|
frag.machine wrote: | Are you running in progs.dat size problems ? Even if it's the case, you should consider using an engine with extended limits like Darkplaces or FitzQuake. If not, I don't see any advantage at all. |
I think frame macros are annoying to type out and would rather memorize numbers. Just my preference, but yeah. |
|
Back to top |
|
 |
Junrall

Joined: 21 Sep 2009 Posts: 136 Location: North West Oregon, USA
|
Posted: Thu Mar 11, 2010 7:14 am Post subject: |
|
|
Downsider wrote: | frag.machine wrote: | Are you running in progs.dat size problems ? Even if it's the case, you should consider using an engine with extended limits like Darkplaces or FitzQuake. If not, I don't see any advantage at all. |
I think frame macros are annoying to type out and would rather memorize numbers. Just my preference, but yeah. |
Nope, not running into any size problems with progs.dat... I tend to fall back to the old-school days when smaller was better/faster. I suppose I don't have to worry about that so much now days.
I do use Darkplaces a lot... and DirectQ too. I haven't been able to use standard Quake since I moved over to 64bit Windows.
I am using the frame macros at the moment. It's nice to quickly see what I'm working with.... but, on the other hand, it can get a little confusing when trying to remember what frame is represented by what number. I'll play around with both numbers and frames and decide which I am comfortable with.
Thanks to you guys I now have a better understanding as to how QC looks at frames. Much appreciated.  _________________ Good God! You shot my leg off! |
|
Back to top |
|
 |
Spike
Joined: 05 Nov 2004 Posts: 944 Location: UK
|
Posted: Thu Mar 11, 2010 10:57 am Post subject: |
|
|
Replacing frame names with straight numbers is generally not advised. Any sort of 'magic number' is generally not advised.
If you don't like $frames you can use precompiler defines instead (in frikqcc or fteqcc).
for giving names to increasing numbers, frame macros are useful.
for giving names to arbitary numbers, #defines are useful.
for making your code look like its been decompiled, for making it unreadable, for making the reader have to guess, straight numbers are useful!
progs size hasn't really been an issue since frikac first added optimisations (aka fixes) to frikqcc. _________________ What's a signature? |
|
Back to top |
|
 |
Junrall

Joined: 21 Sep 2009 Posts: 136 Location: North West Oregon, USA
|
Posted: Thu Mar 11, 2010 3:27 pm Post subject: |
|
|
Spike wrote: | Any sort of 'magic number' is generally not advised. |
I totally agree with this... and am not messing around with "magic" or "made-up" numbers. I'm trying to understand the functionality of some of the QC code... I'm not trying to cause self.health = BRAIN_ANEURYSM!
for making your code look like its been decompiled, for making it Spike wrote: | unreadable, for making the reader have to guess, straight numbers are useful! |
Yep, I agree with this too... however, comments can go a long way, but can make the code look messy and then unreadable.
I'm going to stick with the macros, as it seems what most people prefer and as you mentioned... progs.dat size shouldn't be an issue any more. _________________ Good God! You shot my leg off! |
|
Back to top |
|
 |
frag.machine

Joined: 25 Nov 2006 Posts: 728
|
Posted: Thu Mar 11, 2010 4:17 pm Post subject: |
|
|
Junrall wrote: | I am using the frame macros at the moment. It's nice to quickly see what I'm working with.... but, on the other hand, it can get a little confusing when trying to remember what frame is represented by what number. I'll play around with both numbers and frames and decide which I am comfortable with. |
And why should you need to remember the value of every frame ? Unless you're using both approaches at the same time (which may be the actual root of your problems), there's absolutely no need to know that, say, $run1 = 123 or something like that.
You can make direct arithmetic operations combining frames and numbers:
Code: |
self.frame = $axrun1 + self.walkframe;
|
You can make conditional tests using frames, too:
Code: |
if ((self.frame < $stand1) || (self.frame > $stand6)) { self.frame = $stand1;}
|
So, I really don't see why one needs to know absolute frames values. _________________ frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/ |
|
Back to top |
|
 |
Junrall

Joined: 21 Sep 2009 Posts: 136 Location: North West Oregon, USA
|
Posted: Thu Mar 11, 2010 5:55 pm Post subject: |
|
|
My apologies... I'm not really having any problems. I should have mentioned that up front.
I am only trying to confirm some ideas I had about frames and how models are referenced through QC with and without the macros. So, the need to know that $run1 = 123 is purely curiosity.
In truth, I'm toying around with an idea of a sort of "hub" function for frames. It isn't really dependent on whether I use frame macros or frame values. Though, after playing around with this stuff for the past week, I prefer the frame macros for readability.
Again, it is just purely curiosity on my part, and wanting to learn what the standard practice is. I feel that sticking with the macros will be the best choice!
I do appreciate all of your responses and willingness to share your knowledge and insights. And hope that my curiosity and thoroughness does not rub anybody wrong. _________________ Good God! You shot my leg off! |
|
Back to top |
|
 |
|