3
\$\begingroup\$

In my Asteroids game the user can scroll through space. When scrolling, the ship is drawn in the centre of the window. I use interpolation. I scroll the window uing glOrtho, centering it around the centre of the ship. On my first machine (7 years old, Windows XP, NVIDIA), I am doing 50 updates and 76 frames per second. This is smooth. My other machine an old compaq laptop (Pentium III) with Linux and Radeon OpenGL driver delivers 50 updates and 30 frames per second. The ship regularly seems to "shudder" back and forth when at maximum thrust. When you position the mouse cursor beside the ship it is obvious that its relative position in the window changes. Also, the stars seem blurred into short "lines".

Playing the game in non-scrolling mode, the ship moves within the window, glOrtho is therefore not called repeatedly and there is no problem.

I suspect a bug in my positioning of the ship and the window but I have dumped out these values and they seem to only go forward, not forward-back-forward. The driver does support double buffering. I guess if it is my bug I need to slow the frame-rate down to debug properly. My question: is this an obvious driver bug or is the slower machine uncovering a bug in my stuff and if so, some debugging tips would be appreciated. I am drawing in world co-ordinates and letting OpenGL do the scaling and translation so if I had a quick way of verifying what pixel co-ordinates OpenGL produces for the ship centre, that would help clarify this.

\$\endgroup\$

3 Answers 3

Reset to default
5
\$\begingroup\$

I had this problem too in my game which just uses SDL. For me, the issue was the camera was updated before the player's new position was updated. Since, his movement is time-based(not constant) sometimes he 'jumps' ahead and appears to stutter. So I just had to change the order of updating.

  • update Active Player
  • update camera position
  • update everything else (but do not re-update active player)

For me, everything is drawn off-setted based on camera's position, but the camera is based on the active player's position. It was a simple fix, but it took me a long time to find since I was blaming time-based movement. Anyways hope this helps.

Edit: I'd like to clarify that this only happens when the camera is tracking the player. Also, A fixed timestamp should fix this problem since there is no time difference between when the camera is drawn and when the player is drawn, but the player should still be updated first, otherwise the player will look like it is always one from ahead of the camera(if that makes sense).

\$\endgroup\$
1
  • \$\begingroup\$ Thank you so much!!! I struggled with this same problem on a university project I had 2 semesters ago and which I now intended to develop a little further. I just can't for the love of god understand how the update order could affect the rendering though... I use the same timestamp for all sub-update methods (player, camera, map, etc...) and I draw objects at absolute coordinates on the world and set the camera to look to at the position of the car. Setting it to look at the current frame position or last frame position should have no impact on the fluidity of the game. But apparently it does \$\endgroup\$
    – AlexJF
    Commented Jun 28, 2012 at 23:40
1
\$\begingroup\$

"I have dumped out these values and they seem to only go forward"

I think you should dump ship's screen coordinates not logical "in game" ones.. If I understand correctly, ship's screen coords should stay the same, am I right?

\$\endgroup\$
2
  • \$\begingroup\$ You are ruight and yes that would be ideal. I don't know how to get the ships screen coords. Everything is expressed in world coordinates. I'm looking for a way to query the resultant transformed co-ordinates. Know how? \$\endgroup\$
    – Ciaran
    Commented Mar 8, 2012 at 13:53
  • \$\begingroup\$ If you use orthogonal projection (glOrtho) as 2D projection, then I think that at the end to display something on the screen, it has to have screen coords, so if your ship has x coordinates like for example 5000 units, then you probably use glTranslate to move world space to screen space. You have few possible solutions here: just for debugging, do the same translation manually by getting translation matrix from opengl to check ship's position values in screen space, or rewrite your engine to do this translation by itself and then pass proper screen coords to opengl. \$\endgroup\$
    – Kamil
    Commented Mar 9, 2012 at 11:00
0
\$\begingroup\$

It appears that calling glOrtho for panning is not recommended. Not sure why. Based on some advice from stack overflow, I have fixed this problem by instead maintaining the ship at origin 0,0 all the time and translating everything else in the world by the ships real displacement from the origin. The window set up by glOrtho remains constant, changing only if there is a zoom.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .