ic0de

The problem here is that in order to make the movable objects show up properly I need to invert the x and z axis.

If you need to invert 2 axes, it means you're performing a 180 degree rotation (around Y in this case), and not a coordinate system change. That might be accounting for the confusion possibly?

You bring up a good point I'll look through my mounds of code. Might this also explain the y axis inversion?

Have you tried using the parallel pattern library? 

 

http://msdn.microsoft.com/en-us/library/dd492418.aspx

 

Cheers!

I don't really think it's a problem with the library i'm using but rather my implementation.

If you verify and find out that you are correct and that rendering must be on the same thread as input, you are basically screwed as far as getting smooth and reliable input until you drop SDL.
Dropping SDL would be my main recommendation, but you may be able to work around it with SetWindowsHook() or SetWindowsHookEx() and bypass the SDL method of handling recognized keyboard and mouse input (while letting it handle unrecognized keyboard input so it can continue to do its thing with maximizing/resizing windows, closing the game on Alf-F4, etc.)

Normally that's what I would do but dropping SDL would be catastrophic to the portability of my code. Right now my game is a unified codebase that compiles directly under a variety of operating systems (so far only tried it with Windows and Linux). For now I think I'll finish implementing this using SDL's event driven framework as opposed to reading from the keyboard buffer, this should be fine for now so that I can finish implementing the interface and work on other stuff until either I come up with a more novel solution or the SDL api changes.

Oh and I'm rendering with OpenGL if anyone was wondering and I'm using the 2.0 version of SDL.

Read this if you haven't already.

Time-stamping is necessary for robust input handling and synchronization with the game simulation.
See this reply.

So I read both links and I was just wondering if someone could help clarify a few things.

1. The first approach runs in a single thread which interrupted when a key is pressed or is another thread is started?

2. The second approach runs in two threads the second of which gathers input. This seems to favor a polling approach as opposed to a callback. right?

3. The two approaches accomplish essentially the same thing but the second one just uses multithreading

4. I use SDL for input handling and it seems to have limitations that prevent the use of both systems. Firstly it has no callbacks to my knowledge. Secondly as far as I know input can only be gathered in the main thread which as also where rendering must take place. Does anyone know any workarounds for this? or has this changed in a recent release?

Is your loop progressing at a known pace or just as fast as possible?

If it is progressing as fast as possible, I highly recommend setting a minimum time before the next loop through is done. 16ms is a good time since this means 60fps, which is the refresh rate of almost all monitors.

Good idea but it would seem to defeat the purpose of timestamping my inputs in that case.