Recent content by Wraith

Now there's a very interesting thing about X52 drivers. You have a lot of extra buttons that are unavailable under "normal" operation: Clutch button, tiny button near mouse stick, throttle wheel press, throttle wheel up and wheel (those are also reported as buttons too!), and even the three...

Yeah, seems I misunderstood you, sorry. But, if you hack around the orbiter.exe a bit and get the device pointer... Hmmm...

Surely D3D7 isn't that bad. There was hardware support for multiple lights since I don't know, Voodoo3? RivaTNT? Rage128? There is D3DDEVICEDESC7::dwMaxActiveLights field where the device reports its max. number of simultaneous lights. And AFAIR those cards reported eight or something.

Yep. Yes, but that won't be reflecting the joystick position, any more because, well, the stick itself is fixed. That's the whole point. The cyclic stick position in a real helicopter is a tremendous cue to the pilot about the swashplate deflections.

Yes, sorry, I mixed collective with cyclic. But no, it's different. In real helicopters, there's a limited degree of deflection for the cyclic stick. The stick controls a very sophisticated piece of machinery called 'swashplate', that in turn deflects main rotor blades. The blade deflection is...

Because helo controls are very different. In flight, trimming must be constantly re-adjusted by the pilot for a given horizontal speed and cyclic setting. Helo-style trimming is just a button that removes the force load from the collective stick, resetting its zero position to the current one...

One more drawback for the X65F - won't do for helicopters.

Ok, I'll break the precious silence then :). Three days to the Moon is pretty good for NASA, but is hardly suitable for a computer game. 'Realism vs. gameplay' here is a crucial question. How much are you willing to sacrifice in order to make it playable? As an example, here are a couple of...

Well, that's the whole point! What MS claims is the functions are "secure" because they made an effort to make them fool-proof. Let's take memcpy_s() as example. Basically, good old memcpy() is perfectly secure: it does what it's told to do: it copies the amount of bytes specified and no more...

Quite the contrary: it's just option 2 is preferred in 99.99% of all the cases. There really can be no 'golden middle' for security vs performance. A software with a subtle bug that allows remote code execution is just as bad as software that has 100 obvious bugs. The functions in question...

If you read the second article, that will give you an example. The main source of all the problems, of course, is in the essence of C: there are no strings in C. But that actually doesn't matter. You can split all situations into two simple categories: 1. You care about performance. 2. You...

Well, that's the problem. First of all, the so-called 'safe' functions are even worse, than 'unsafe'. That's because despite what Microsoft call them, they are not safe. They add no security, but instead give a false sense of security. Second, now that we have moved away from seventies, there...

Actually, the functions aren't deprecated. Feel free to use them as you had learned. Good news: the world didn't turn upside down, as you may have thought. There's been an outcry after VC2005 was out and that crap started to pour on the heads of unsuspecting coders. It's perfectly legal in C...

So in other words, at orbital speeds in the upper atmosphere the hypersonic airflow is strong enough to heat the vessel, but is still weak to produce enough lifting force, is that correct? What about deorbiting a newspaper at a shallow angle? (Remember that?) Will it just burn then?