Ok, I think I've got this right but if someone would verify/explain this to me it would be appreciated.
It's in the use of the % operator in AVS. The explanation in "expression help" doesn't make a whole lot of sense.
If I were to use 5%2 then I would get the remainder, which would be .5 right?
And reading the AVS programming guide, in the first explanation about 3d scopes, the code point=(point+1)%4 is used. How does the % operator affect this code?
It's probably a dumb question but I just didn't seem to be able to figure this one out.
Stupid noob Q.
20 posts
The modulus operator % actually gives you the remainder of the division 5/2. But it wouldn't be 0.5; its 1!
The remainder of that divison means: what is left over in order to avoid decimals?
5/2 = 2 + 1/5
Mostly this operator is used, to generate a variable that repeatedly counts to a specific value and afterwards starts with 0 again:
point=(point+1)%4 (only convenient when set in "pixel")
means that the variable point increases by one and jumps back to 0 after reaching 3:
0 1 2 3 0 1 2 3 0 1...
For example: 4 can be divided by 4 without a remainder. 5 is by 1 greater than 4; 6 is 2 greater than 4; 7 -> 3, but 8 can be divided by 4 without a rest again, and so on.
Clear?? If not, just ask again!
P.S: merry christmas
The remainder of that divison means: what is left over in order to avoid decimals?
5/2 = 2 + 1/5
Mostly this operator is used, to generate a variable that repeatedly counts to a specific value and afterwards starts with 0 again:
point=(point+1)%4 (only convenient when set in "pixel")
means that the variable point increases by one and jumps back to 0 after reaching 3:
0 1 2 3 0 1 2 3 0 1...
For example: 4 can be divided by 4 without a remainder. 5 is by 1 greater than 4; 6 is 2 greater than 4; 7 -> 3, but 8 can be divided by 4 without a rest again, and so on.
Clear?? If not, just ask again!
P.S: merry christmas
Might it be the same thing as saying:
point=point+1;
point=if(equal(point,4),0,point);
So that when point hit 4 it would revert back to 0.
point=point+1;
point=if(equal(point,4),0,point);
So that when point hit 4 it would revert back to 0.
Yes! Exactly right!
Originally posted by mIcrO_brAInThis would be the same, but
Might it be the same thing as saying:
point=point+1;
point=if(equal(point,4),0,point);
So that when point hit 4 it would revert back to 0.
point=(point+1)%4
is much faster cause its only one equation. (Probably its a imperceptible difference, but if you've got a big bunch of code it'll be worth)
it also has many other uses, because unlike the if equal combination, you can perform it on any number at any time, it doesnt have to be a count.
for example, anyNumber%2 will tell you if the number is odd, because if it is, the remainder will be 1.
the downside is, the % operator only works on integers, not decimals, so decimal precision is lost when you use it.
for example, anyNumber%2 will tell you if the number is odd, because if it is, the remainder will be 1.
the downside is, the % operator only works on integers, not decimals, so decimal precision is lost when you use it.
what f*cking genius coded the compabilities of the processor 😛
all intel coprocessors since the 8087 and all intel processors since the 80486DX (not SX) have an instruction called FPREM
this instruction does a floating point remainder. (80387 and above additionally have FPREM1, which is should be used instead)
so much about the "compabilities" of processors 😉
back to the topic:
if you want a point counter go from 0 to n-1, write p=0; into frame and p=p+1; at the end of the point block.
if n is 7, for example, p will go this way:
0 1 2 3 4 5 6
in the next frame, p is reset to 0 and the whole thing will start from the beginning.
the advantage over just writing p=(p+1)%n; at the end of the point block is that the other method is much faster , because % is a division, which is generally not that fast 😉
that's why you normally write a=b*.5 instead of a=b/2;
this instruction does a floating point remainder. (80387 and above additionally have FPREM1, which is should be used instead)
so much about the "compabilities" of processors 😉
back to the topic:
if you want a point counter go from 0 to n-1, write p=0; into frame and p=p+1; at the end of the point block.
if n is 7, for example, p will go this way:
0 1 2 3 4 5 6
in the next frame, p is reset to 0 and the whole thing will start from the beginning.
the advantage over just writing p=(p+1)%n; at the end of the point block is that the other method is much faster , because % is a division, which is generally not that fast 😉
that's why you normally write a=b*.5 instead of a=b/2;
Originally posted by TomyLobounfortunately I dont want a variable to go from 0 to n-1, I want a variable to go from 0 to n-1 then 0. However as people have pointed out it is a little poorly explained and arguably inefficient. A better line would be:
back to the topic:
if you want a point counter go from 0 to n-1, write p=0; into frame and p=p+1; at the end of the point block.
if n is 7, for example, p will go this way:
0 1 2 3 4 5 6
in the next frame, p is reset to 0 and the whole thing will start from the beginning...
frame:
point=0;
point:
...
point=if(equal(point,3),0,point+1);
And I shall modify the guide accordingly, thank you.
----- techy bit ------
On an additional and rather anal point I believe its marginally more efficient to have:
frame:
point=3
point:
..
point=if(bnot(point),3,point-1);
It draws the square backwards but of course that doesnt matter, its a lot more ugly to understand tho. Also, since I think if's are more expensive than multiplications it may be more efficient to have:
frame:
point=3
point:
..
point=point-1+bnot(point)*3;
but its pretty gosh darn ugly.
you got the point pak! 😁
i thought * is slower than if by a lot... otherwise why have if?
um....i'm very tech here but actually what Jheriko said above i always thought the same thing. I was told by someone....er...i think Shreyas told me that * is slower than if.
/agrees that if() is faster than *
(if() doesn't caclulate, but compares only)
(if() doesn't caclulate, but compares only)
Originally posted by jherikoTo do conditional processing 🤪
i thought * is slower than if by a lot... otherwise why have if?
To be honest I dont really know which is more expensive I just assumed it was 'if'. But now that I think about it its really just a jump-if-not-zero in asm... and since it short circuits you are removing some of the computation. Okay I'm sold, it probably is cheaper... but someone should really check the evallib and prove it. I'd do it myself but... well I can't really be arsed.
I've tried it out on a ridculusly numpointeds scc, and * is faster, BUT THE DIFFENECE IS SO TINY, IT DOES'NT REALLY MATTER
pwnt
wow, all that expenditure for nothing... what a waste!
It depends on the use though. If() will be faster for some things and * will be faster for others.
Each time it did the if it gained 0.00000001 fps over times.
On my PC
On my PC
you'd think avs would optimise if(a,b,0) to a*b if if was slower than a * :P