Improvement suggestions

#1 Agreed.

The problem here is that T2D started on the premise that we wanted easier to digest functions. Things like 0-deg being "up" rather than "right". Positive rotation being clockwise rather than anti-clockwise and angles being in degrees rather than radians.

Unfortunately, by doing this, we've seperated ourselves from the inherited functions from the TGE platform and for that, I apologise.

I have noted your concern and it is valid and I'll see what we can do about it in the future.

- Melv.

#2 Ah... I hadn't realized you'd reversed the rotation! I had suspected a 90 degree rotation, but that explains why the skid function wasn't working right...

I was reasonably sure you chose degrees because non-math types go "huh?" with radians -- but for the love of mike please consider doing normal rotation? Heck, normal starting point would be nice. And for your average side-scrolling 2D game that is what would make sense anyway: 0 degrees is forward, positive is up, negative is down.

edit: reading this now it sounds a little strong to me. I am requesting that you consider the rotation starting point and direction arrangement, but whatever you guys do will work for me. Thanks for taking the time to read my feedback.

#3 Degrees and up been 0 is certainly going to be more obvious to many new users. But, is it going to cause more confusion the moment they use the maths functions and find its expecting radians and that 0 radians is to the right?

edit: Thinking about this a bit more, I guess using degress and up as 0deg is fine, so long as it's made clear in the documentation what coord system layout T2D uses. Maybe a diagram showing the coord system and an explanation of the system the torque inherited functions use would clear things up for anyone starting out.

As long as people know to expect it they can account for the difference and will probably be able to work in degrees most of the time :)

#4 When in doubt, build your standard to the to the library / framework standard.

#5 The only problem with flipping the rotation and rotating 90 degrees is that it makes it harder to think about if you actually know what you're doing.

#6 The main problem is consistency: one set of functions in degrees with reverse rotation and an offset and another in radians. As I said originally, it needs to be one or the other. Otherwise you are asking for obscure problems if you write code of any complexity.

That said, I have no earthly idea why zero degrees would point up or why it would be considered more intuitive. As I already pointed out the normal convention matches the standard 2D scroller perfectly. So why not?

I asked a friend of mine about this. He's not a programmer and his only education post high school is a trade school (mechanic). I'm sure he hasn't a clue about radians, but he expected degrees to go counterclockwise and start from the right.

If you know much math radians make a lot more sense than degrees, but I will probably always think in terms of degrees, 45 degree angles and 30-60-90 triangles. Radians, degrees, pick one. And if Melv and Josh want rotation to be clockwise starting from up, so be it. Its their product and I'm happy to be using it.

edit: dang typo

#7 Just to provide an alternate perspective: Anyone that has any previous experience with navigation of any sort (pilot/aircraft, captain/ships-boats, or even anyone used to using a compass) will point out that 0/360 is north/up, and compass directions go clockwise! A 090 heading is due east, 180 due south, and 270 due west...

#8 That's about what I think. Using the standard polar system is fine. They teach it in school and it's much easier to think in that system having been taught it. If someone with absolutely no knowledge of anything comes along and thinks 0 is up or something because of a clock, then it makes sense, but it's not difficult to understand using the standard.

If it's not too late, my vote is to use standard polar system with 0 at the right and counter clockwise rotations.

#9 @Stephen, yeah, but I think the vast majority of programmers and non-programmers aren't shipmates or pilots. :)

#10 I prefer 0 at the right, but it reall doesn't matter that much.

#11 @Seth: I bet not a few of them have used a compass before however, hehe.

#12 I do see both sides of the argument here and no matter which way is chosen, I think the important point raised here (and quite rightly so) is the matter of consistency.

It's a bit of a job changing all the underlying engine references so that would only leave changing all of T2Ds stuff to suit which is a pain because we did so much work trying to make stuff easier to understand to beginners.

It would certainly help if you made a clear distinction between T2D and the underlying platform. All fxObjects work in degrees, 0 = "Up" (North) and positive rotation is clockwise. Anything other uses the older system.

This certainly doesn't invalid the original request though.

- Melv.

#13 Ehm... why not just have 2 sets of functions?

One set would do everything in radians, in order to be friendly with the rest of Torque, and anybody else tinkering with the engine code.

The other set would be wrapper functions that merely convert degrees to radians, and the appropriate 0-orientation, and clockwiseness, which then calls the orignal with the correct parameters.

Put Radian or Degree in the appropriate function prefix/suffix, and you'll have 2 sets, one for beginners, and one for 1337 coders!

#14 @Eugene: There are way too many functions to start overloading everyone of them with a radian/degree variant. That would become unmanagement quite quickly as well.

You can use "mRadToDeg()" or "mDegToRad()" quite easily to convert between the two though.

We're at EA and only in week two so there's plenty of time to address this and other issues. :)

- Melv.

#15 @Melv: I agree completely, consistency is the main issue. I was looking at this more thoroughly and noticed* another variation from the "standard" way of doing things than already mentioned. To summarize:

1. degrees vs radians
2. 0 is up vs right
3. rotation is clockwise vs ccw
4. y is reflected

It seems likely to me that point 4 was chosen to allow the "old school" 2D programmers their conventional 0,0 is upper left, am I right? This then leads to a clockwise rotation (or did the clockwise rotation lead to y being reflected? Does it matter?). So points 3 and 4 go hand in hand. Point 1 is an obvious decision (I'm familiar with radians and why they work out "nicer", but I still think in degrees). Point 2? Well, heck, that's really less of a deal IMO than point 3, so if some people would find that easier then it makes sense as well.

In otherwords, it all fits together and makes logical sense -- to me, anyway. Then comes the caveat, the underlying Torque platform you inherit from is more math oriented and:

1. uses radians
2. 0 is right
3. rotation is ccw
4. y is not reflected

I'm sorry if I didn't make that clear earlier: it was certainly a distinction I understood. So the consistency conflict is between the underlying platform and T2D.

My first suggestion would have been Eugene's, but you've already pointed out why that isn't workable. I think what would work is to provide three helper functions:

1. vectorFromPolar() or whatever you want to call it. As I said, it is trivial and not really necessary, but I think it fits with the existing functions

2. RadToDegT2D()
3. DegToRadT2D() -- goes from the T2D definition of angle degree to the platform definition of angle radian and vice versa.

The purpose of these functions is to account for the four points. This way the user of T2D doesn't even need to really understand what is going on, just that they have to convert from the degrees that T2D uses to the "radian thingy" that the platform uses. And then only if they are wanting to use the platform's trig functions. If someone does understand the distinctions they can still use the helper functions or accommodate the differences on their own. Minimal effort, maximal return.

Well, that's my $0.02 anyway

Tim Doty

*I feel compelled to explain why it took me so long to notice the discrepancies. Basically, I'm doing this in my spare time and I don't have that much of it. Consequently, I've been focused on achieving results rather than analyzing what is going on. I should have noticed something was up when the steering function was reversed, but I simply swapped left and right and drove on. It wasn't until I got to using trig functions that it came into focus.

I don't know if I'm a typical user of T2D or if there even is such a thing, but the fact that I got this far before noticing anything -- and if the foregoing functions had existed in T2D still wouldn't have noticed anything says to me that as long as there is logic and consistency it will "just work" for the majority of users.

edit: forgot a clarifying para
edit2: dang typos

#16 Well I vote for the current system of degrees and 0 being up/north!
I've always used this for simplicity and because of the analogy to compass navigation.

But if many others wanted a different system, couldn't angle inputs be put through a quick function to convert from your chosen angle system into the underlying angle system?