[DeveloperX]

This is a good read for detail/optimizing-obsessive programmers like me:

http://www.plunk.org/~grantham/public/divshift.html
_________________
Principal Software Architect
Rambling Indie Games, LLC

See my professional portfolio

[Nodtveidt]

Looks like it was written by someone who doesn't fully understand the differences in compiler options and target architecture.
_________________
If you play a Microsoft CD backwards you can hear demonic voices. The scary part is that if you play it forwards it installs Windows. - wallace

[RedSlash]

The author makes a valid point about arithmetic right shifts vs divide, but I think he misunderstood freetype's 26.6 format and incorrectly concluded that he should divide by 64 to get the integer portion of glyph.advance.

-32 if it were represented as a freetype 26.6 int is -1.5 (11111111111111111111111111 100000), and therefore right shifting by 6 and producing -1 as the integer portion is the correct result whereas dividing by 64 and producing 0 is incorrect. Correct me if I'm wrong.

[Rainer Deyke]

C++ integer division to round toward zero. Right shift rounds toward negative infinity. Both are ""correct", but the latter is generally more useful. (One of the nicest things about Python, IMO, is that it defines integer division to always round toward negative infinity.)

RedSlash: your example is incorrect (or has a typo), but your point stands. The bit pattern (11111111111111111111111111 100000) is actually -0.5 (i.e -1 + 0.5). Right shifting produces -1, while C++ integer division yields 0. However, the -1 is correct because it is more consistent, i.e. it rounds in the same direction as division of a positive number would.

To convert a 26.6 fixed point number to an integer, I would use the formula '(n + 32) >> 6'. This consistently rounds to the nearest integer, for both positive and negative values. The alternative using division, '(n + 32) / 64', would produce incorrect results for negative inputs.

[RedSlash]

Ops, sorry that was a typo. Thanks for pointing that out. I was actually referring to integer truncation as opposed to rounding. i.e. -0.1 would still get truncated to -1 when you right shift by 6.