Interwoven in the environment are occasional networks (big or small) of "bug tunnels", where zerg like creatures live and nest. Going through them can be risky, as visibility is low and you might be rushed at any moment.
In this case, we find a mysterious mechanical door that seems to be looking back at us. Hopefully the player makes a mental note to check back here when he has more abilities.
The atmo is pretty good!
That's what I did a second later. xD I pull the rotation matrix myself and
apply it to the OpenGL stack.
The top answer isn't right in ever detail; (s)he wrote;
"For OpenGL itself,
it's no difference whether it receives radians or degrees -- they are
internally converted to transformation matrices anyway, so there's no
computational gain of using one or the other.". Well, there is a computational
gain, since OpenGL rotation matrix uses sine and cosine and both function
require radians. So a conversion is mandatory, if the given implementation
doesn't use trigonometric tables based on a 1 degree stepping.
Here is how I see it:
Once it comes to using math (trigonometry), degrees aren't easier nor
helpful. But if one just looks at them without doing any math, then they are
easier since for example 45 degrees is a whole number while Pi/4 has a
fractional part. So one would need fractions which are more difficult since
they require the concept of an inverse, i.e. the inverse of 10 is 1/10. So as
a kid you may start learning some (visual) trigonometry by just using the
numbers from 0 to 360. You get told what 0, 45, 90, 180, and 360 mean. And
most people got stuck to it for their whole life. And I think that's where the
problem is. I'm going to believe that this is the reason why some people say
'degrees are easier'. If you haven't learn anything else, for sure, they are!
But it seems 'degrees' may have a slight advantage while being used on
low-end hardware like for example on 4-, 8-, or 16-bit computers. Well, it's
not so much the degree itself, its the whole number associated with a (some)
degree(s), which can be used for indexing into a trigonometric table. For a
full circle we get 360 degrees, so we may store a trig value for each degree.
But we can likewise split the circle into just about 256 parts as it was done
back in the days for efficiency reason, since we have mod ax, 256 == and ax,
0xff, i.e. mod ax, 2^n == and ax, (2n - 1). And that's way fast.
For the graphics engine I wrote for the DCPU-16, I develop another approach,
which still allows me to use radians while still being able to index into a
trigtable using them. How? Well, my engine uses some custom fixed-point
formats. One of them is an 8.8 format, 8 bits for the whole part and 8 bits
for the fractional part. I use this format to represent radians. Hence, my
radians have precision of 8 fractional bit ~= two decimal digits, which is
enough. We have 2*Pi ~= 6,283. Since each whole part (bounded by 6) can
only have 256 different fractional parts using my 8.8 format, I just computed
how many different integers I need to represent the 'whole range' of 2*Pi
represented within an 8.8 fixed-point format. To do this, I just multiplied
2*Pi by 256, hence 2*Pi * 256 ~= 1.608. Then I built a trigtable of 1608
entries, i.e. splitting the circle into 1608 parts given a ~0.22 degree per
step, which is quite good. For, using 360 would give 1 degree per step and
using just 256 entries would give about 1,4 degrees per step. So 1608 entires
are enough for making smooth rotations -- given you have also implemented a
stable matrix rotation routine, which can be done by using a fixed-point
format of 2.14 (on a 16-bit computer), plus, if you have the thrill doing so,
quaternions. I did all that. Anyhow. Now I have all these 1608 values of sines
or cosines. Nice! What's next? Remember that my radians are 8.8 fixed-point
numbers. The maximum number is 0x06.0xff (~= 2*Pi). This number is stored into
a 16-bit integer as 0x06ff. For example, Pi/4 is represented as M_PI_4 :=
0x00c9 = 0.78515625 and Pi is M_PI := 0x0324 = 3,140625. Now the kicker is, I
use these values to index into the trigtable. This way I can still use radians
for all my trigonometric calculations. It essentially helped me in programming
more sophisticated math routines in a more naturally way while making less
errors juggling round with degrees. Another advantage comes from being able
to combine radians with other fixed-point numbers for computing variable
argument to the trig functions. This is essentially cool stuff if you want to
generate some procedurally generated content, like I've done, where you may
modify the phase and frequency of the trig functions by modifying their
argument, f.e. freq*t-phase. This works out pretty well -- if everything is
based on the same format and natural to the problem.
Ok, enough of all the math. I may perhaps write a book about it, about how the
first 3d games like Elite were programmed if anyone is interested. But first
I have to finish a game of mine. Otherwise I won't have any time nor money
writing something like this.
DualShock 3 controller on PC.
I want to use a DS3 on PC for controlling the crafts inputs. Does anyone have
any experience using a DS3 on a PC? Is there a library or something like this
making the DS3 easy to use on a PC?
