Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / Player rotation issue

Author
Message
mr Handy
17
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 14th Nov 2014 10:49
Hi guys! I am trying to make basic player controls: player rotates and then moves, top-down view. Sometimes the rotation is incomplete, like 173 instead of 180 degrees. Sometimes it is okay... what is wrong with the code?



Scorpyo
22
Years of Service
User Offline
Joined: 26th Aug 2002
Location: italy
Posted: 14th Nov 2014 13:26
try to use ang# instead of ang
mr Handy
17
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 14th Nov 2014 14:33
Float in object angle will cause a DBP bug at


Rudolpho
19
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 14th Nov 2014 15:01
What kind of bug would that cause, object angle y() certainly returns a float?

mr Handy
17
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 14th Nov 2014 15:31
Equation of floats bug.

Quote: "certainly returns a float?"

3D precision is pretty inaccurate (even in 3ds max) so it may return slightly different float angle.

So you will eternally wait to move.

http://www.garagegames.com/community/forums/viewthread/133760

Just try the code with ang#.

Anyway even if it worked it doesn't solve my OP issue

TheComet
17
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 14th Nov 2014 15:45


What's the point of this check? Only move the player once the target angle is reached?

Mathematically, curveangle never reaches object angle y(). It asymptotically approaches it, but will never equal the target value.

I like offending people. People who get offended should be offended. -- Linus Torvalds
Rudolpho
19
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 14th Nov 2014 16:22
Quote: "3D precision is pretty inaccurate (even in 3ds max) so it may return slightly different float angle."


So just do something like this instead then:


mr Handy
17
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 14th Nov 2014 20:42
Quote: "So just do something like this instead then:"

Sorry, dude, I would not use approximate rotation values.

Quote: "What's the point of this check? Only move the player once the target angle is reached?"

Yes!

Quote: "Mathematically, curveangle never reaches object angle y(). It asymptotically approaches it, but will never equal the target value."

Unless ang is integer. If you take a look at the code, you can see that object is rotated by rounded integer value ang, not exact float value given by curvevalue.

I suspect something wrong with atanfull part

Rudolpho
19
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 14th Nov 2014 21:19
You don't want to use approximations and instead opt to use truncated integers...? That's quite a large approximation in my book; basically equivalent to a theta value of 0.999....
If what you're worried about is that the ang# value will come up short of the corresponding object angle, you can just set it to the object angle once it is close enough to it.

Anyway, I'll take a look at your code after dinner.

TheComet
17
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 14th Nov 2014 21:42
Quote: "Yes!"


Then do what Rudolpho said earlier:


I like offending people. People who get offended should be offended. -- Linus Torvalds
mr Handy
17
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 14th Nov 2014 21:50 Edited at: 14th Nov 2014 22:09
@Rudolpho
Frankly, your solution works well - I have not noticed incomplete rotation bug (yet?...), but it is IMO a dirty code solution. Because there should be equation. edit: and it cause anlge values like 6.06613411946e-006 (should be 0!)

Maybe you guys can came up with a better solution?

edit: atanfull is OK, curveangle sometimes "stops" a lot before the final value...

James H
18
Years of Service
User Offline
Joined: 21st Apr 2007
Location: St Helens
Posted: 14th Nov 2014 22:07
At the risk of stating the obvious it looks to me that on occasion the result is out by 9 degrees every time the undesired angle becomes apparent, what needs identifying first of all is when these occasions occur, there appears to be some correlation with the result and the rotation direction. What I am seeing is that rotation in a clockwise direction produces the undesired angle while an anticlockwise direction will produce the desired angle. By adding +1 to object angle y parameter of the line that returns the resulting angle to be used, the opposite becomes true - that is the undesired angle is produced by rotating in the anticlockwise direction.
Therefore it would make sense to add a check that returns the rotation direction ie clockwise or anticlockwise, just before the return angle is calculated. Following this check, based on which direction was in process, you can simply make another condition that chooses between the actual angle the object is situated at or the actual angle object is situated at +1 degree, as previously described.
I suspect that 1 degree is 1 iteration of the calculation(ie speed of 10) and that the undesired result reflects this with 9 as its already losing 1 degree; its almost as though in the anticlockwise direction its calculating 1 to 359 rather than from 0.
I hope the nonsense I just wrote makes sense, am not good with terminology or explaining clearly.
mr Handy
17
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 14th Nov 2014 22:21
Looks like a bug, because there should not be any additional checks.

James H
18
Years of Service
User Offline
Joined: 21st Apr 2007
Location: St Helens
Posted: 14th Nov 2014 22:31 Edited at: 14th Nov 2014 22:40
Could well be - Maybe you could try out Matrix1Util_07 of IanM`s MatrixUtil plugin as that has atanfull also, can`t test myself right now, but at least if Ian has same bug(his helpfiles say is same as dbp but uses double float for result), you at least have a better chance of getting it fixed if it is a bug.

Edit: NVM, am using dbp and am at a stage in a project where I dont want to lose my rythm so wasnt prepared to close and install the plugin - anyway I checked my plugin user folder and I am already using his plugin - perhaps the dbp variation gives different results as to what I described earlier. When I`m done with current project I will remove plugin and retest if you havent already compared the 2 commands results.

Edit2: Ok I lost my place anyway lol, so took opportunity and just checked it and dbp variation throws exact same results
mr Handy
17
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 14th Nov 2014 22:47
No, it is not atanfull! It is the curveangle, and its clockwise bug. Only thing I made so far - reversed that bug to counter-clockwise by flooring ang#

James H
18
Years of Service
User Offline
Joined: 21st Apr 2007
Location: St Helens
Posted: 14th Nov 2014 22:58
Cool, glad you have it sorted
Rudolpho
19
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 14th Nov 2014 23:49
Glad to hear you solved it
Here is a modified version of your code that I think works as desired (as well as proper indentation )


mr Handy
17
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 15th Nov 2014 00:13
Thanks! Now the only problem left - actually, the curveangle itself... I think better I replace it with my own function.

Rudolpho
19
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 15th Nov 2014 00:28
Cheers, here's the curveangle implementation used by the DBPro function if you want to dissect it:


Ortu
DBPro Master
17
Years of Service
User Offline
Joined: 21st Nov 2007
Location: Austin, TX
Posted: 15th Nov 2014 03:37
Quote: "if targetAngle# < 0.0 then targetAngle# = wrapvalue(targetAngle#)"


Shouldn't this just be wrapped regardless? What happens if it goes over 360.0?

Couldn't it just be trimmed down to

targetAngle# = wrapvalue(atanfull(keystate(k_r) - keystate(k_l), keystate(k_f) - keystate(k_b)))

Rudolpho
19
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 15th Nov 2014 11:18
To be honest yes, I don't know why I didn't just do it like that.

Login to post a reply

Server time is: 2025-05-12 10:40:59
Your offset time is: 2025-05-12 10:40:59