Questions about the code (specifically bradians)

Looking through the JBolo source, it appears as though a bradian is a byte radian. (I haven't looked through the C source code much yet.)

This being the case, why are all the bradian angles in Utils floats?

Also, wouldn't it be easier to convert between bradians and radians directly and not go from bradians to degrees to radians and vice-veras?

Another question. Wouldn't it be easier if RADIANS_EAST were 0 instead of 64 since EAST would be 0 radians?

scockroach wrote:

Looking through the JBolo source, it appears as though a bradian is a byte radian. (I haven't looked through the C source code much yet.)

brad's are binary radians, one brad is 1/256 of a circle.

Min

scockroach wrote:

Another question. Wouldn't it be easier if RADIANS_EAST were 0 instead of 64 since EAST would be 0 radians?

doesn't really matter what east is as long as its consistent, why bother changing it? it won't make anything any 'easier' the code is already written to take care of it.

Min

scockroach wrote:

This being the case, why are all the bradian angles in Utils floats?

Questions like this are best answered like this ... "It seemed like a good idea at the time"

Min

Min wrote:

scockroach wrote:

Another question. Wouldn't it be easier if RADIANS_EAST were 0 instead of 64 since EAST would be 0 radians?

doesn't really matter what east is as long as its consistent, why bother changing it? it won't make anything any 'easier' the code is already written to take care of it.

Min

It actually does make it a little easier. All the actual math functions (cos, sin, tan) use radians. So if you wanted to convert between radians and bradians, all you'd have to use is just a simple conversion factor - which you could #define - and that's that.

That being said, I'm sure I put together all necessary functions in mathWinbolo that convert from radian, bradian, degrees to each other.

doesn't really matter what east is as long as its consistent, why bother changing it? it won't make anything any 'easier' the code is already written to take care of it.

So, it might not make anything 'easier' for you but it would make things 'easier' for new comers to the project so that they don't have a wtf moment like I did looking at the code.

It actually does make it a little easier. All the actual math functions (cos, sin, tan) use radians. So if you wanted to convert between radians and bradians, all you'd have to use is just a simple conversion factor - which you could #define - and that's that.

I agree with this. Except, is there any need to convert anything to degrees? Where would that be used?

scockroach wrote:

It actually does make it a little easier. All the actual math functions (cos, sin, tan) use radians. So if you wanted to convert between radians and bradians, all you'd have to use is just a simple conversion factor - which you could #define - and that's that.

I agree with this. Except, is there any need to convert anything to degrees? Where would that be used?

Mainly for readability. Well I eventually want to conduct collisions and such with physic equations. This would allow for simple tweaks via config files to change the way the game behaves. Not many people I talk to can immediately picture the angle that what 0.79 radians makes but when you pass 45 deg in, you can see if that makes sense during debugging.

You're right. That makes sense. For anything human readable it would definitely make sense to use degrees.

Sticks wrote:

It actually does make it a little easier. All the actual math functions (cos, sin, tan) use radians. So if you wanted to convert between radians and bradians, all you'd have to use is just a simple conversion factor - which you could #define - and that's that.

Well, personally, for speed/optimization purposes, I'd suggest converting cos/sin/tan over to brad's instead. In fact, I believe I have a function someplace in my code that I wrote awhile back that does that. Simpler than converting the numbers every time you go to do anything mathwise with them.

brad's are what bolo used, so its simpler to get the physics correct if we keep using them. I'm certainly not concerned about new coder's abilities to understand whats going on. If they have issues understanding it, chances are some of the more complicated code is going to really send them for a loop. And they'll need to ask for help anyways, or they'll search the forum and find this thread and realize 'oh, ok' its not like we're not around to help out.

Min

ps, if you have wtf moments while looking at the code, that usually means that section needs better commenting.

Min

As an aside, scockroach, we have different game types. In a strict or tournament, you usually wait until teams are formed before starting. Apologies if someone was trolling under your nick.