Inside3D!
     

$frames and self.frame
Goto page 1, 2  Next
 
Post new topic   Reply to topic    Inside3d Forums Forum Index -> QuakeC Programming
View previous topic :: View next topic  
Author Message
Junrall



Joined: 21 Sep 2009
Posts: 136
Location: North West Oregon, USA

PostPosted: Tue Mar 09, 2010 6:45 am    Post subject: $frames and self.frame Reply with quote

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
View user's profile Send private message
Error
Inside3D Staff


Joined: 05 Nov 2004
Posts: 558
Location: VA, USA

PostPosted: Tue Mar 09, 2010 7:34 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website AIM Address Yahoo Messenger MSN Messenger
Spike



Joined: 05 Nov 2004
Posts: 944
Location: UK

PostPosted: Tue Mar 09, 2010 9:15 am    Post subject: Reply with quote

$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
View user's profile Send private message Visit poster's website
Junrall



Joined: 21 Sep 2009
Posts: 136
Location: North West Oregon, USA

PostPosted: Tue Mar 09, 2010 3:14 pm    Post subject: Reply with quote

Very cool! Razz

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
View user's profile Send private message
frag.machine



Joined: 25 Nov 2006
Posts: 728

PostPosted: Tue Mar 09, 2010 4:10 pm    Post subject: Reply with quote

Junrall wrote:
Very cool! Razz

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
View user's profile Send private message Visit poster's website
Junrall



Joined: 21 Sep 2009
Posts: 136
Location: North West Oregon, USA

PostPosted: Wed Mar 10, 2010 3:14 am    Post subject: Reply with quote

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

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
View user's profile Send private message
Downsider



Joined: 16 Sep 2008
Posts: 478

PostPosted: Wed Mar 10, 2010 3:46 am    Post subject: Reply with quote

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
View user's profile Send private message
frag.machine



Joined: 25 Nov 2006
Posts: 728

PostPosted: Wed Mar 10, 2010 12:22 pm    Post subject: Reply with quote

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

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
View user's profile Send private message Visit poster's website
Wazat



Joined: 15 Oct 2004
Posts: 732
Location: Middle 'o the desert, USA

PostPosted: Thu Mar 11, 2010 4:53 am    Post subject: Reply with quote

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
View user's profile Send private message MSN Messenger
Downsider



Joined: 16 Sep 2008
Posts: 478

PostPosted: Thu Mar 11, 2010 5:23 am    Post subject: Reply with quote

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
View user's profile Send private message
Junrall



Joined: 21 Sep 2009
Posts: 136
Location: North West Oregon, USA

PostPosted: Thu Mar 11, 2010 7:14 am    Post subject: Reply with quote

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. Smile
_________________
Good God! You shot my leg off!
Back to top
View user's profile Send private message
Spike



Joined: 05 Nov 2004
Posts: 944
Location: UK

PostPosted: Thu Mar 11, 2010 10:57 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Junrall



Joined: 21 Sep 2009
Posts: 136
Location: North West Oregon, USA

PostPosted: Thu Mar 11, 2010 3:27 pm    Post subject: Reply with quote

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! Laughing
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
View user's profile Send private message
frag.machine



Joined: 25 Nov 2006
Posts: 728

PostPosted: Thu Mar 11, 2010 4:17 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Junrall



Joined: 21 Sep 2009
Posts: 136
Location: North West Oregon, USA

PostPosted: Thu Mar 11, 2010 5:55 pm    Post subject: Reply with quote

My apologies... I'm not really having any problems. I should have mentioned that up front. Sad
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! Smile

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
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    Inside3d Forums Forum Index -> QuakeC Programming All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
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