Willem, am forwarding this to Audyssey as I'm betting you wanted both Thomas
and I to see this?
-And here is my response;
First off, you're absolutely right that degrees can be used to be more
human-readable; this and the fact that all standard functions use radians is
exactly my point.
I need to create methods that take degrees and return degrees but do the actual
work in radians. I think this is the point that I'm not being clear enough on.
this isn't just a matter of doing a bunch of calculations and then making a
print-out at the end for someone to look at. This is very different from that.
the end user will pretty much never see any of these calculations except in a
super limited context. However, as a developer, when working with a game engine
as we're talking about here, there do need to be some conveniences that need to
be created so one can work comfortably in creating and working with the engine.
I.E. In order for me to write code which works with the behaviors of an object
in space during the game or GPS app, or whatever, I need to see an angle
measured in degrees because I personally feel more comfortable and prefer
working in that mode. Since the computer is more comfortable working in radians
to do the calculations I need it to, to calculate a vector on the object, I
then need to convert back and forth in two of my functions. Just as a note, my
functions are not the same as thomas is using; I contributed to his but our
paradigms are a bit different.
Anyway, all of this code is internal to the game but since I really need to see
degrees, I then need to convert. I need to call conversions all the time, back
and forth, because game objects need to update their headings and movements
etc. (which they show to me, the developer, in degrees so I can more easily
work with / understand how they're behaving) So since this needs to be done
many times a second, this isn't just a case of staying in radians and making
one conversion at the end.
Anyway, I hope this makes sense… and thanks for your note. Perhaps someone else
can explain this a bit better if necessary. :)
Smiles,
Cara :)
Begin forwarded message:
From: Willem Venter <dwill...@gmail.com>
Date: December 13, 2010 6:17:12 AM PST
To: Cara Quinn <caraqu...@draconisentertainment.com>
Subject: Re: [Audyssey] game objects in memory
Hi Cara.
The only time you need to use degrees are to interpret the angle when
debugging or if you are checking something in the game. All the
standard libraries use radians. I adapted Thomas and your code to show
how I'd use only radians and also wrote an easy to call function that
prints degrees.
//name: r2d
//only for checking if everything works as it should. This prints the
degree equivalent of a radian angle
//all the standard functions need radians, so this is the only place
where degrees are needed
void::r2d(double angle)
{
printf(angle *pi/180, "%f");
}
//updated to use only radians
// Name: GetDirection (double, double, double, double).
// Description: Calculates the angle between
// two game objects.
// CQ
// will switch your z to y so i can think straight :)
float Calculate::GetDirection (double x1, double y1, double x2, double y2)
{
// CQ
// changing this so both subtractions are in the same order
// as this changes the result
// Subtract x1 from x2
double x = x2 - x1;
// Subtract y1 from y2
double y = y2 - y1;
// CQ
// this should be y over x
// Calculate theta by the arc tangent
// of -y/x
double theta = std::atan2 (y,x);
// Return the direction in radians
return (float)theta;
}
// Name: GetX(double, double, double).
// Description: Calculates the next possible x component.
float Calculate::GetX (double direction, double x, double velocity)
{
//note direction is in radians
// Calculate the next x component by
// multiplying velocity by the cosine of
// direction
// CQ
// switched this to cos and changed calculation slightly
x = velocity * std::cos (direction );
// Return the new x component
return (float)x;
}
On 12/13/10, Cara Quinn <caraqu...@draconisentertainment.com> wrote:
> Hi Willem;
>
> I guess I'm confused as to what you're saying here, so perhaps you can
> elaborate?…
>
> I need to work between the two modes constantly. In order to convert an
> angular measurement in degrees into a unit vector, and vice versa, I sure do
> need to use radians. If you know of another way to do this, then can you
> share?…
>
> And, as I said, in order to stay sane while working with the code for
> vectors associated with objects and their rotation in an engine, I
> definitely need to use angular measurements in degrees.
>
> So what am I missing here?
>
> Yes, there's a lot of converting going on, but without using radians, I know
> of no other way to move between an angle in degrees and it's associated unit
> vector.
>
> Thanks so much and do have a lovely day!…
>
> Smiles,
>
> CQ :)
> On Dec 13, 2010, at 12:28 AM, dwill...@gmail.com wrote:
>
> I think there is too much converting back and forth. When debugging you can
> convert the angle before displaying, but besides that there is no need to
> have angles in degrees. The developer never really has to work with the
> radians.
>
> -original message-
> Subject: Re: [Audyssey] game objects in memory
> From: Cara Quinn <caraqu...@draconisentertainment.com>
> Date: 13/12/2010 10:10 am
>
> Willem;
>
> Not quite true, unless I'm not understanding you properly…
>
> We're not actually talking about any angles being displayed to the user here
> but working with angles in the engine itself, and interpreting those angles
> either explicitly or relatively to show / affect the placement / orientation
> of game objects as well as some behind-the-scenes uses in game play for the
> user. I.e. aiming and such.
>
> So the user will most likely only ever be aware of the actual angle an
> entity is facing in context of a compass heading.
>
> This is purely for the comfort of the developer so we can more easily work
> with game code and not lose our bloody minds doing so!… lol! -Know what I
> mean?…
>
> It's a whole lot easier working with 30 degrees rather than 0.5235987756
> radians, yes? lol!
>
> Have a totally awesome night and hope the holidays are treating you and
> yours wonderfully! -Thanks for the great notes keeping this way cool topic
> happening!…
>
> Smiles,
>
> Cara :)
> On Dec 12, 2010, at 8:24 PM, dwill...@gmail.com wrote:
>
> Yes, but the actual value doesn't matter as long as you stick to using one
> or the other method. Under normal surcomstances it wont be shown anyway and
> only the angles that are displayed need to be converted.
>
> -original message-
> Subject: Re: [Audyssey] game objects in memory
> From: Cara Quinn <caraqu...@draconisentertainment.com>
> Date: 13/12/2010 1:53 am
>
> Hi Willem, right you are! -For me though, holy crap! I wouldn't feel at all
> comfortable dealing in radians all the time. lol!
>
> I prefer to work in degrees and just convert back and forth on the fly.
>
> I basically have two methods I send pointers to; one to get an angle which
> returns in degrees, and the other to set an angle which takes degrees.
>
> I personally just don't naturally think in radians, but there ya go.
>
> Have a terrific day!…
>
> Smiles,
>
> Cara :)
> On Dec 12, 2010, at 9:28 AM, Willem Venter wrote:
>
> Hi Cara and all.
> Thanks for the discussion. Reading all this was very informative and
> helpfull. An observation I might make is that if you work only in
> radians, multiplying
> and dividing with the constant (pi/180) becomes redundent. This will
> save some small calculation and simplify the code. If you really want
> to see the normal
> degree form of the angle you could just use standard functions to
> convert it back for displaying.
>
>
> On 12/12/10, Thomas Ward <thomasward1...@gmail.com> wrote:
>> Hi Cara,
>>
>> Got it. I apologize if I was a bit short with you a bit earlier. It is
>> just the fact I've written and rewritten this engine code so many
>> times I'm ready to scream. One of those cases wereI feel like I can't
>> do anything write, and the worst part of it is I'm both college
>> educated and have a programming degree. I shouldn't have this much
>> grief over something like this. Although, to be fair to myself some of
>> it wasn't my personal fault.
>>
>> For example, when I was looking at going cross-platform Travis highly
>> recommended SFML for Linux, Mac, and Windows. So I checked out the
>> API. On the surface it seamed exactly like what I needed, and
>> abandoned my plans to use SDL 1.2.13 and went with SFML 1.6 instead.
>> Next thing I know the game is causing massive crashes all over the
>> place, and many users reported the almighty blue screen of death.
>> Initially I thought it was something I did, my own mistakes, etc and
>> so ran it through the Visual Studio debuggers. Much to my surprise
>> after I did a step by step debug it comes up with an error found in
>> sfml-window.dll. So I go and report it to the developer of the project
>> ask him if they know about this bug and what could be done to resolve
>> it etc. Basically, the guy knew about it, and doesn't kno how to fix
>> the bug at this time. His recommendation, "upgrade your Windows vidio
>> drivers." This immediately became a tech support nightmare, and the
>> reason I'm pulling SFML 1.6 completely out of beta 17 and going with
>> my original plan of using SDL 1.2.13. At least it is stable and has no
>> vidio driver problems I'm aware of.
>>
>> So at this point I've got the cross-platform engine ripped apart and
>> I'm now in the process of redesigning all the low level subsystems
>> like the window manager, input, audio, networking support, etc. What a
>> bite in the butt!
>>
>> On the bright side I have rewritten the window subsystem and have
>> basic keyboard support back in place with SDL and so far so good. I'm
>> probably going to work on joystick and mouse support tomorrow and the
>> window and input subsystems will be ready to go.
>>
>>
>> As for audio I'm still not sure where to go with that. I'd like to use
>> OpenAL, but I feel as though I'll have to rite some bit of middleware
>> like a library that wraps OpenAL and can load ogg, mp3, wma files, etc
>> which will be a very time consuming project. In the mean time FMOD
>> would give me that and more which would at least get the engine up and
>> running again for beta 17.
>>
>> So the basic point of what I was saying here is I've already got a
>> long development cycle ahead with low level stuff. If there was a need
>> to change more things to do proper collision detection now would be
>> the time to do it, but I don't want to add more time to the
>> development cycle than absolutely necessary.
>>
>> Smile.
>>
>> On 12/12/10, Cara Quinn <caraqu...@draconisentertainment.com> wrote:
>>> Hi thomas;
>>>
>>> Just one last note for the evening.
>>>
>>> when I switched your z to y, it was for clarity's sake for the email. I'd
>>> assumed you would adapt the new code with your current orientation as I'd
>>> made other changes as you'd asked. The formulae are right but I was using
>>> x
>>> and y to show what I was doing in a standard way. -Only for clarity in my
>>> note. :)
>>>
>>> So sorry I obviously didn't make that clear enough.
>>>
>>> There's no reason, even in a worst case scenario that you should ever
>>> need
>>> to rewrite that much code for changes like these. I'll need to check back
>>> in
>>> with DX, but last I checked, you could essentially flip your world around
>>> any way you wanted it simply by changing two coordinates. -And, as I'd
>>> just
>>> mentioned, even if you change back y to z as I thought you would, the
>>> other
>>> changes I made will give you proper calculations. -but at the end of the
>>> day, if your engine is already essentially doing what you need then why
>>> change it at all? -this was, afterall, just a lil' experiment, yes? -I'm
>>> sure not asking you to change your style. :) I'm just personally working
>>> in
>>> one of the paradigms we were chatting about and having success with it.
>>> -But
>>> this is your baby after all. -If I can make suggestions that help, then
>>> great! If not, then don't use them. Yes? :)
>>>
>>> Anyway, Talk witcha on the 'morrow and have a terrific night!…
>>>
>>> Smiles,
>>>
>>> Cara :)
>>>
>>
>> ---
>> Gamers mailing list __ Gamers@audyssey.org
>> If you want to leave the list, send E-mail to
>> gamers-unsubscr...@audyssey.org.
>> You can make changes or update your subscription via the web, at
>> http://audyssey.org/mailman/listinfo/gamers_audyssey.org.
>> All messages are archived and can be searched and read at
>> http://www.mail-archive.com/gamers@audyssey.org.
>> If you have any questions or concerns regarding the management of the
>> list,
>> please send E-mail to gamers-ow...@audyssey.org.
>>
>
> ---
> Gamers mailing list __ Gamers@audyssey.org
> If you want to leave the list, send E-mail to
> gamers-unsubscr...@audyssey.org.
> You can make changes or update your subscription via the web, at
> http://audyssey.org/mailman/listinfo/gamers_audyssey.org.
> All messages are archived and can be searched and read at
> http://www.mail-archive.com/gamers@audyssey.org.
> If you have any questions or concerns regarding the management of the list,
> please send E-mail to gamers-ow...@audyssey.org.
>
>
> ---
> Gamers mailing list __ Gamers@audyssey.org
> If you want to leave the list, send E-mail to
> gamers-unsubscr...@audyssey.org.
> You can make changes or update your subscription via the web, at
> http://audyssey.org/mailman/listinfo/gamers_audyssey.org.
> All messages are archived and can be searched and read at
> http://www.mail-archive.com/gamers@audyssey.org.
> If you have any questions or concerns regarding the management of the list,
> please send E-mail to gamers-ow...@audyssey.org.
>
>
> ---
> Gamers mailing list __ Gamers@audyssey.org
> If you want to leave the list, send E-mail to
> gamers-unsubscr...@audyssey.org.
> You can make changes or update your subscription via the web, at
> http://audyssey.org/mailman/listinfo/gamers_audyssey.org.
> All messages are archived and can be searched and read at
> http://www.mail-archive.com/gamers@audyssey.org.
> If you have any questions or concerns regarding the management of the list,
> please send E-mail to gamers-ow...@audyssey.org.
>
>
> ---
> Gamers mailing list __ Gamers@audyssey.org
> If you want to leave the list, send E-mail to
> gamers-unsubscr...@audyssey.org.
> You can make changes or update your subscription via the web, at
> http://audyssey.org/mailman/listinfo/gamers_audyssey.org.
> All messages are archived and can be searched and read at
> http://www.mail-archive.com/gamers@audyssey.org.
> If you have any questions or concerns regarding the management of the list,
> please send E-mail to gamers-ow...@audyssey.org.
>
>
> ---
> Gamers mailing list __ Gamers@audyssey.org
> If you want to leave the list, send E-mail to
> gamers-unsubscr...@audyssey.org.
> You can make changes or update your subscription via the web, at
> http://audyssey.org/mailman/listinfo/gamers_audyssey.org.
> All messages are archived and can be searched and read at
> http://www.mail-archive.com/gamers@audyssey.org.
> If you have any questions or concerns regarding the management of the list,
> please send E-mail to gamers-ow...@audyssey.org.
>
>
---
Gamers mailing list __ Gamers@audyssey.org
If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org.
You can make changes or update your subscription via the web, at
http://audyssey.org/mailman/listinfo/gamers_audyssey.org.
All messages are archived and can be searched and read at
http://www.mail-archive.com/gamers@audyssey.org.
If you have any questions or concerns regarding the management of the list,
please send E-mail to gamers-ow...@audyssey.org.
