scgames

It's probably the forward vector you want to negate, rather than the target point.

If you're using a 'look at' function that takes a position and a target point, you should be able to compute the adjusted target point as follows (pseudocode):

vector3 forward = target - position;
vector3 adjusted_target = position - forward;

   - Ogre: a full fledged game engine.

Ogre is a rendering engine only, not a game engine (AFAIK, at least). It can certainly be combined with other libraries though (e.g Bullet for physics, etc.) in order to create a framework for a game.

Based on what you've said though, it sounds like an integrated engine such as Unity or Shiva might be more appropriate for what you want to do. (You might have to pick up a new language, depending, but if you're comfortable with C++ that shouldn't be an obstacle.)

The main difference between SLERP and NLERP is that the latter doesn't interpolate with constant angular velocity (assuming the interpolation parameter changes at a constant rate, the speed of the rotation will increase and then decrease over the course of the interpolation). In many cases this effect is not noticeable though. Furthermore, NLERP has the advantage of being less expensive than SLERP.

Regarding the artifacts you're seeing, try checking the dot product and performing the negation (if necessary) as the first step in the function, rather than towards the end. (As is, you're computing some of the initial values using the 'uncorrected' input quaternions, which I imagine could cause some problems.)

Since q and -q represent the same orientation, a typical implementation of quaternion SLERP will first check the dot product of the input quaternions and negate one of them if the dot product is negative (this ensures that the interpolation takes place over the shortest arc).

Although I can't say for sure that that's what's causing the problems you're seeing, it seems likely that it is, so that's probably the first thing I'd try.

Would Ogre meet your needs?

Also, consider dropping the 'c' prefix for your class names (it doesn't really add any useful information, and just clutters the code, IMO).

I understand why you cannot use memory dynamically allocated commands in the C program i.e.(new and malloc) because they are not as efficient as creating your very own.

Certainly you can use malloc (in C and C++) and new (in C++) in your programs. In fact, that's probably exactly what you'll want to do unless you have a specific need for a custom solution. (Even then, you might look into existing solutions, such as boost::pool if you're using C++,  rather than implementing something from scratch.)

[Edit: Fixed error in post.]

I'm guessing it's a theoretical question.  The practical reason is if you needed to inline functions in older (e.g. C89 and K&R C) code.

Only the OP can tell us for sure, but I get the impression the question is practical in nature. For one thing, the thread title is 'C++ Macro Problem', which suggests the question is specifically in reference to C++ rather than C.

I could be wrong though (maybe the OP will clarify).

Unity:
Can be run on both Windows and Macintosh, and the end-result games  can be played on either platform (unsure about Linux/Ubuntu/etc.)

Unity does not currently support Linux.

Haven't yet found if they charge you anything.

You should be able to find most if not all of the answers you're looking for here, here, and here.

Any reason you're not just using a function?

You're right about that. Yet, ironically, doing it the right way brings worst results! Now the image never faces the direction it's going! What's going on? O_o

Do you still have any of the 'corrective' code in place? That is, are you modifying the angle returned by atan2() in any way?

Also, although this is probably too obvious, are you missing any degrees<->radians conversions anywhere?

float radians =  atan2(x_vel, y_vel);

Assuming you're using standard conventions (which it sounds like you are), the above should probably be:

float radians =  atan2(y_vel, x_vel);

you might be best using  directx D3DXVECTOR2  for this ,  cause  all the operators are overloaded, makeing maths  so mauch easyer

What if the OP isn't using DirectX/Direct3D, or is targeting platforms that don't support it?

(I didn't see anything in the OP's posts specifying what APIs are being used or what platforms are being targeted.)

Is there a way to delete a topic? I can't find it otherwise I would.

No need to delete - the question and the link you provided may prove useful to someone in the future :)

That should probably be a switch statement or a series of if-else's rather than a series of 'if' statements (since '_wparam' can only have one value).

Also, if you're going to use leading underscores for symbols, be sure you're familiar with what the standard has to say about them.

As for your problem, it seems unlikely to me that Windows would not correctly report multiple key releases in a single polling cycle. As such, I'm guessing the problem is due to a logic error in your code somewhere (although I can't say that for sure).

In any case, the first thing I'd probably do is add some breakpoints or debug output to determine which blocks of code are actually being executed.