Units of Measure

I've been working through some auto-moving sprite functionality, and have wandered a bit further down that road than I originally expected to at this point ... so now I need to back up a bit to get back on the main route of progress.  Here is my list of current things to do:

  • Finish fleshing-out my auto-move sprite class (going to set it up to work like a cross between a simple-but-somewhat-intelligent game object and a particle)
  • Crop things down into a "base" sprite class ... and change the auto-move sprite to inherit from the base
  • Build the primative (circle, rectangle, triangle, line) sprites from the base sprite
  • Finish the initial camera functionality (sprite-following, defined bounds, and defined viewports -- leading to multiple cameras in a GameSpace and "split screens" ... btw: thanks once again to the XNA Machine Blog who is taking a slightly different approach to similar terrain -- and that's helping me see things in new ways as well)

Once I get that far, I should be ready to compile a quick demo on how the camera and sprite basics work.

But I wanted to be sure to touch upon a couple units-of-measure that I will be using throughout the library ... and since I don't have something productive to show from my code at this point, I figured now might be as good a point as any. ;-)

Angles In Degrees -- I prefer my angles to be measured in degrees.  Something about my old-fashioned American math training just won't let go of me ... so, I like my circles to start at 0 degrees at top, increase in a clockwise fashion -- 90 degrees is to the right, 180 degrees is down -- until you end up at the top again at 360 degrees.  So, if you see a property or function that is returning an angle (names like "Heading", "Facing", "Aiming", "GetAngle", etc.), it will be in degrees.  However, for properties, I will likely have an equivalently named property with a "_InRadians" suffix (such as "Heading_InRadians") to give something to work with if someone wants to use Windows functions that prefer radians.  The "QuickTrig" helper functions in Nimble2D operate in degrees -- so, making use of those is very easy with this degrees-friendly approach.

Time in Seconds -- I've found it traditional for game programmers to deal with time in milliseconds, for a number of different reasons.  However, I've found over time that I always need to convert those into true seconds to do things related to time-based programming (X = X + VX * (DeltaMS / 1000), etc.).  So, with this library, I've decided to always deal in actual seconds ... usually of type Double.

Space Measurements in "GameSpace Pixels" -- Position and spacial measurements will essentially still be in pixels, with the normal caviats thrown in when dealing with current 3D programming: It's a pixel if everything is at a 1.0 scale.  And everything will be relative to each other within the GameSpace ... so, basically, the camera's position will determine what will be showing up on screen.  Having a position of (800, -16372) may be in the middle of the screen, if the camera is moved into the right place ... and something at (805, -16372) will be 5 pixels to the right of the first object, assuming a scale of 1.0.  When I combine these two things, I like to think of these units as "GameSpace Pixels", as it reminds me of the relativity between all things within the GameSpace.

Rates are "per Second" -- Any rate-style measurement -- "Linear Speed", "Acceleration", "Rotational Speed", "Alpha Fade Rate", etc. -- will be in a "per second" format.  Linear Speed, for example, is in "GameSpace Pixels per Second" ... Acceleration is "GameSpace Pixels per Second per Second" ... Rotational Speed is "Degrees per Second" ... Alpha Fade Rate is in "Values per Second" (where a "value" is each integer in the 0-to-255 range).

"ColorOnly" versus "Color" -- There are times when I like to separate the Alpha channel out by itself from the rest of what would normally be an ARGB-style System.Drawing.Color.  Also, there are cases (such as background color) where the Alpha channel just doesn't matter.  As an example of the former, sprites will have a "SpriteAlpha" property that can hold a value of 0 (completely transparent) to 255 (completely opaque) and a separate "SpriteColorOnly" that, while still being of type System.Drawing.Color, will only make use of the Red, Green, and Blue channels to color-shade the sprite.  If something contains just the word "Color" (and not the "Only"), then all 4 channels will be used for whatever purpose that property or function is up to.

Those are the main ones that I've run into so far ... I'm sure there will be more, so I reserve the right to re-visit this topic (and maybe even change what's been stated here). ;-)

-Matt

Published Friday, February 22, 2008 9:21 PM by MattWorden
Filed under: , ,

Comments

# re: Units of Measure

Nice to see this is still progressing, I hope this really turns out in a successful library.

I'd like to point out some notes about your units of measure here;

- Angles are usually in radians for a reason: the whole goniometry mathematics are based on radians. Are you willing to convert between radius and degrees all the time?

- About the color values, why do you use 0 - 255? If you want to modulate one color with another, it is much easier when you use percentages (0 - 1). Sure a + b = c using both units. But when you do a * b with a 0..255 unit, you are likely get a value out of range which is not even the value you are looking for, you would have to do (int)((float)a * ((float)b / 255.0f)) and casting and dividing is not really what you want to do. With percentage units you do get the right value.

- A seperare propery with "Only" prefix that ignores the alpha component in the color? Why? If your users want 100% alpha they should just set the alpha component to 100%.

Sunday, February 24, 2008 3:44 PM by codeimp

# re: Units of Measure

Good comments/questions, Pascal ... hope I do some justice in answering.  I'll just take then them order.

First, the look-up-table-based trig library functions that I've alluded to are degrees-based ... mainly because I didn't want to do conversions back and forth.  I have provided the trig functions that seem to matter for 2D games (sin, cos, GetAngle, GetComponents, etc.).  The only reason I would provide an alternative "InRadians" would be for someone who wishes to use the original Math. namespace trig functions for some reason.  Personally, I don't expect to use them ... just stick in degrees.

Second, I'm not sure what you mean on the color values.  I have seen them represented in the 0-to-1.0 format and understand how they work.  But when sticking to 0 to 255, and using the Color.ToARGB function ... things seem best in that range.  Also, I've never done multiplication of color values.  So, if you can give an example of when/where this might be used for a 2D library, then I might see the need to implement it differently.

Lastly, I personally like to work with alpha separately from the color values -- especially for sprites.  I seem to mess around with the alpha value a *lot* more than with the color values.  Usually, the color is just left at "White" while alpha is faded-in, faded-out, etc.  Even in the case where I am using color-shading, I still do alpha separately.  So, to be able to better handle it separately conceptually, I've split it out property-wise as well ... so I can just set MySprite.SpriteAlpha = 128, instead of having to build a full color each time I adjust the alpha.

Tuesday, February 26, 2008 10:36 PM by MattWorden

# integer triangle

Pingback from  integer triangle

Friday, May 16, 2008 5:13 AM by integer triangle

# c convert to radians

Pingback from  c convert to radians

Tuesday, June 24, 2008 6:13 PM by c convert to radians