Home | Forums | What's new | Resources | |
ANGLE interpolation |
vreuzon - Feb 11, 2003 |
vreuzon | Feb 12, 2003 | ||||
Let me clarify the problem by adding some incorrect code:
Code:
As you can guess, interpolate_angle is the function I'm trying to implement. Taleon : I think I can't use an integer division beacause ANGLES are not integers. I don't know what a cast from ANGLE to int would look like because int is signed and ANGLE is not. Antime : Not only when i_angle gets small. I think it never works. Ok for the one time calculation of reused elements. TakkaIsSilly : Yes, I think I'll eventually use the shift operator, but I'd like to have an exact solution, just in case it is fast enough... not to mention the use of quaternions... I think ANGLE is seen like a float by the compiler. Right ? |
antime | Feb 12, 2003 | ||||
Your code works fine. Small testapps are good for confirming whether something works or not:
Code:
The only thing you have to make sure is that you get the datatypes right. Fortunately GCC for SH2 uses the same types as most 32-bit CPUs, so there's only the user-defined types left to figure out. (SGL defines ANGLE as a Sint16 and Sint16 is defined as a signed short.) |
TakaIsSilly | Feb 12, 2003 | |||
I've checked as well, and ANGLE is indeed a Sint16... This is somewhat strange... since this means angles are to be mesured measured from -pi to pi, not 0 to 2*pi (0 to 360) as decribed in the documentation. Anyway, this matters little, pi and -pi are basicly the same angle so value operations are carried out as expected. The compiler will treat it like an integer as well ... Yet, division based on shift will work correctly only on the values 0x0000 to 0x7FFF, since higher values are signed. |
vreuzon | Feb 12, 2003 | |||
I may be wrong, but when the / operator is used with signed int, the sign is treated a special way. ANGLE beeing signed 16 bits internaly does not give its "negative" values (which are not representing negative angles) the same meaning as in a true signed 16 bits int (Are negative values using two's complement, one's complement, or what ?). That makes me think it won't work for all values, especially for those representing negative values in normal int16. But there might be some magic in it... I'll try to test it using slPrintHex. |
vreuzon | Feb 12, 2003 | |||
takaissilly : ok. I had not seen your last post before I answered. I'm not sure whether there's an error in the doc or not. There might be no relation between the represented angle's sign and the potential ANGLE sign (int16 sign). |
antime | Feb 12, 2003 | |||
I think I see what you mean. An easy fix is to change the interpolation function to use unsigned shorts. TakaIsSilly: I think GCC specifies that right-shifting signed values will use arithmetic shift. It's however something that must be kept in mind when porting to/from other compilers and platforms. But in any case, micro-optimizing is a bit unnecessary here as the division only has to be carried out once; store the result of (f_angle - i_angle)/nstep and for each loop iteration calculate i_angle+step*step_angle. You can also avoid the multiplication by just adding step_angle to i_angle and accumulating the result. |
vreuzon | Feb 12, 2003 | ||||
I'll try it :
Code:
Ok for you ? |
Reinhart | Feb 13, 2003 | |||
The SGL has some math related fonctions, including angle conversion ... It is in the SGL Developer's manual reference nearly page 100. Maybe you have already check and it's not usefull for your purpose. Another idea come to me ... Can something like toFIXED(N) can do the trick ? It is what I use to get integer value ? Please don't flame if I'm completely off topic |
vreuzon | Feb 13, 2003 | |||
Using sine/arcsine and cos/arcos is another way to do the interpolation using FIXED, but it would be much longer to convert angle to 2 lengths, interpolate the 2 lenghts and go back to ANGLE. But it might be much easier. |