$frames and self.frame

[Junrall]

I understand that in the following frames:

Code: Select all

$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: Select all

$frame rockrun1 rockrun2 rockrun3 rockrun4 rockrun5 rockrun6

before

Code: Select all

$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!

[Error]

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.

[Spike]

$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.

[Junrall]

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?

[frag.machine]

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.

[Junrall]

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.

[Downsider]

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.

[frag.machine]

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.

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.

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.

[Wazat]

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.

[Downsider]

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.

[Junrall]

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.

[Spike]

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.

[Junrall]

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

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.

[frag.machine]

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: Select all

self.frame = $axrun1 + self.walkframe;


You can make conditional tests using frames, too:

Code: Select all

if ((self.frame < $stand1) || (self.frame > $stand6)) { self.frame = $stand1;}


So, I really don't see why one needs to know absolute frames values.

[Junrall]

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.