...
... Now, the viewport is 1280x720. Potentially the means I'll be dealing with enemy or obstacle locations in the million pixel range in the X coordinate. That just doesn't seem like the way it's commonly done to me. Or is it? I don't know. ...
You may perhaps be interested in an object's local-, global-, and viewport
coordinates and how to transform them into each other.
... I think the whole "floating point numbers aren't reliable" thing is the reason Unity has the Mathf.Approximate(float, float) method. Different processors are likely to handle floating point math differently, ...
"Are likely". True. But not if they follow a given standard, i.e. the IEEE 754
for floating-point computation. In this case they all behave the same,
otherwise it's a bug.
There are vendor specific feature that extends the standard, like Intel with
its 80bit extended double precision format. On a modern Pentium all floating-
point computations are converted to 80bit internally, which sound good, but
isn't if one doesn't pay attention. Why? Well, upon loading a 64bit float into
the FPU it gets extended to 80bits as stated earlier. If you now do some
computation on the extended 80bit float and later store the result back to
memory, while being converted back to a 64bit float again, you will get a
different result with respect to the plain native 64bit version.
However, that's not such a big issue for gaming. But there are two at least;
(a) "the whole 'floating point numbers aren't reliable' thing" stems from
truncating the standard to increase performance. If that's the case, you,
being the developer, have to take care of this to know all its limitations,
if you want to program a reliable game on the given hardware. For example,
even the Cell's SPEs do not support full IEEE 754 single-precision floating-
point numbers, which isn't necessary for gaming nevertheless. But you better
know about it.
(b) The other issue with floating-point numbers usually stems from performing
computations on too different scales, i.e. using bad coordinate systems. One
of the coolest things about floating-point computation is that the computer,
i.e. the FPU, adjust the radix point by itself, i.e. it rescales the
coordinate systems such that both numbers are aligned in scale/dimension/
magnitude. If the numbers are too far apart, one may lose significant figures
(precision) during computation leading to unstable results. However, the
floating radix has lead people to assume that one can throw numbers together
at will. And this, despite the spooky features some systems have, is by far
the biggest issue. You really have to take care of the range of your numbers
and the range of the numbers they get, for example, multiplied with. That's
why we are programmers to begin with. To take care about all these things. No
tool whatsoever can save one from such consideration, since every finite
number system resampling an infinite one poses such limits.
I need to implement text rendering for menu and HUD. Are bitmap fonts the way to do it? (C++, DirectX9)
Like razu said. And btw don't bloat your game with superficial libraries just
to render a font. I have written a little code fragment for you to render
bitmapped characters and strings (
no error checking done, mind you!)
Code:
// blit a character to the screen
void blitChar(int x, int y, char c)
{
char map[] = "abcdefghijklmnopqrstuvwxyz0123456789";
int len = strlen(map);
int i = 0;
// find index of character c in map[]
while(i < len)
{
if(map[i] == c)
break;
i++;
}
// blit bitmapped character to the screen
bltBM(x, y, // screen position
bm, // bitmap with characters, aligned with map[]
i*char_width, // char position in bitmap
char_width,
char_height,
video_buffer);
}
// blit string to the screen
void bltStr(int x, int y, char *str)
{
for(int i = 0; i < strlen(str); i++)
bltChar(x + i*char_width, y, str[i]);
}
blitChar() uses an elegant character map, which saves us from holding a whole
ASCII character bitmap (which would be faster, since no additional translation
is needed). You can extend the character map with other symbols etc. Just draw
some more characters in the bitmap and extend the character map within the
code. Obviously, you need to replace the bltBM() function. Easy! The bltStr()
is pretty standard for rendering a string, but very slow in general. Ratering
bitmapped strings in scanline order, assuming a linear framebuffer, is much
faster. But you may perhaps never touch that ground while programming on a PC.
