• Content count

  • Joined

  • Last visited

Community Reputation

145 Neutral

About martinis_shaken

  • Rank
  1. OpenGL Stutter / Micro Stutter Even w/ VSync

      Just tried out LTTng and it dumped 60MB of data (which babeltrace spits out to my stdout) for only 10 second of gameplay. Wow. May install Eclipse to try and interpret the trace data. Tried plugging it all into an IDE when I set it up with visual studio, but trace data there didn't seem to help. The most valuable trace information so far is what I've posted in some other posts where I've screens that show how long each frame takes using c++11 chrono. I can't imagine system calls and other processes really interfering with the code, given that it happens the same way across multiple systems at the same times. I tried recording it to post a video, but it seems my computer can't handle that. Will try fraps or something in Windows and see if I can record with that.
  2. OpenGL Stutter / Micro Stutter Even w/ VSync

    Hello, and thanks for participating!   I would say 2-3 frames, if I had to guess. You should be able to replicate it via the sample program I posted on github   As for system specs, this is the info for my laptop:   /proc/cpuinfo: processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Core(TM) i3-2310M CPU @ 2.10GHz stepping : 7 microcode : 0x1a cpu MHz : 2093.189 cache size : 3072 KB physical id : 0 siblings : 4 core id : 1 cpu cores : 2   /proc/meminfo: MemTotal:        6099052 kB MemFree:         3653744 kB Buffers:          119444 kB Cached:          1361440 kB   NOTE: I run ubuntu 32-bit, even though I've 6gigs of ram, hence the mem free being so low. All I have open when running this is 14 chrome tabs.   lspci: 00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09) 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) 00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04)     Regarding the parked CPU, would this still be an issue if I don't limit frames and just let it run full boar at 700fps? Because the same stuttering issue occurs with or without Vsync enabled.   As for energy settings in Linux I have tried using cpu management tools to set the power to performance or else maxing out the CPU. Same for windows with high performance setting.   I have also tried setting task priority to very high in Linux and real time in Windows to no avail. Exact same stuttering in the exact same way.
  3. OpenGL Stutter / Micro Stutter Even w/ VSync

        Haha, it's okay. I am too, and I'm baffled. If I ever figure it out I'll be sure to post. Thank you very much for the help though everybody!!! :)
  4. OpenGL Stutter / Micro Stutter Even w/ VSync

      Sorry for the very delayed response - been out of the country the past couple weeks. I did try removing all the output statements, piping them to a file, limiting them, etc. and the problem still persists.
  5. OpenGL Stutter / Micro Stutter Even w/ VSync

    I'm not sure I understand this one completely, but the way I interpret it is having the player's movement depend on the delta between frames? If that is so, then it does do that already. Same for the scrolling of the background and everything else. The whole environment runs off a delta (which made me think of taking that out and seeing what happens when it doesn't - which is why I made the sample program I put on Github to take out all the variables I could).       No sir, I do not. In fact I killed all running processes that were not critical in both Windows and Linux - and even reformatted Linux (and also upgraded it to Ubuntu 13.10 and installed only the SDL2 libs), AND reinstalled my video drivers in both Linux and Windows.
  6. OpenGL Stutter / Micro Stutter Even w/ VSync

      Yep, definitely happens if I look away and use peripheral. Didn't know that could happen though, that's cool. I will check now to ensure that the monitor is in fact at 60hz, but if it isn't then VSync should be able to figure that out I would hope. There is something with frames being dropped though, some way some how.   Edit:   god@god-laptop:~$ xrandr Screen 0: minimum 320 x 200, current 1366 x 768, maximum 32767 x 32767 LVDS1 connected primary 1366x768+0+0 (normal left inverted right x axis y axis) 309mm x 174mm    1366x768       60.0*+   40.0      1360x768       59.8     60.0      1024x768       60.0      800x600        60.3     56.2      640x480        59.9   VGA1 disconnected (normal left inverted right x axis y axis) HDMI1 disconnected (normal left inverted right x axis y axis) DP1 disconnected (normal left inverted right x axis y axis) VIRTUAL1 disconnected (normal left inverted right x axis y axis)     Yes it does run at 60fps, and when I try setting it to 40 it all flickers like crazy.
  7. OpenGL Stutter / Micro Stutter Even w/ VSync

      Erik, thank you very much for running it on your system. I really appreciate the help.   I am definitely running in windowed mode, and I noticed when I went to fullscreen in Windows the problem almost completely disappears. In windowed mode though, the stutter can still be seen and this problem does not occur with other games. Your explanation of not being able to have perfect VSync makes sense though, thank you. As for Linux though, it still does not explain why the stutter is so prevalent - and this is with glut or with SDL. It's like it takes the Windows problem and enhances it. And I have the latest drivers on 12.04 and on 13.04, but for 13.10 it is just rolled into the OS. I wonder if this happens on CentOS or another distro....   Still doesn't make sense to me why other games don't have the same problem, such as the Gish game. Same environment, with no apps running, etc.
  8. OpenGL Stutter / Micro Stutter Even w/ VSync

    Another update:   I have compiled and executed   This code essentially loads a '.png' file and displays it on the screen. I modified it to then start scrolling the png from the top left to the bottom right (same as in the sample program on github) and the problem occurs in FreeGlut too........   This is awful. It is the EXACT same problem, so I know it can't be the SDL code. This leaves the OpenGL code or a driver issue from hell.   One thing that makes no sense though, is that I have compiled and run the source code from the game Gish. This runs smoothly on my screen and it uses SDL 1.2 and OpenGL.   And just to re-emphasize, this problem occurs on Windows and Linux on two laptops with different intel drivers and on a desktop with intel cpu and an AMD video card.      Can anybody confirm that the code posted to github also stutters? (if you do install sdl2 from the apt-get , the sdl2_ttf is not there, you can just remove the linking from the sconstruct as it is not used in the example anyway). The below should be all you need to install sudo apt-get install libsdl2-dev sudo apt-get install libsdl2-image-dev If you are unfamiliar with scons, all you need to do is call "scons" in the root of the directory (same spot as the sconstruct), same as you would "make"     If this same code does not stutter on anybody else's machine then I am in awe of this problem.   Thank you very much for everybody's continuing help. If anybody can solve this, it's the gamedev community.
  9. OpenGL Stutter / Micro Stutter Even w/ VSync

        Tonemgub, thanks for the response! I really appreciate everybody helping out.   Firstly, I switched up the timers as you suggested, but saw no big difference. I will keep it in there though as I'm sure it is at least a tiny improvement.   As for the double precision, I don't think I have a single double in the code, just all floats (and as you said probably not an OpenGL problem, but thank you for mentioning it and covering all possible solutions).   Regarding SDL - I took out the SDL_Event polling and the stuttering continued. And as for doing the glClear() after swap_buffers() - I do it because it's the same thing as doing it at the beginning of the loop at that point. If I do it right before swap_buffers it will just erase all the work that "render()" has done and will display a blank screen
  10. OpenGL Stutter / Micro Stutter Even w/ VSync

      This is to be expected (especially if Triple Buffering is enabled, which you could check in your driver settings).     Is it also expected to have the frame sometimes take 5ms and sometimes .3ms?  I am checking now if triple buffering is enabled, but I do know that double is, as that is the SDL_SwapBuffers() command.   Edit: Yes triple buffering is enabled and I tried disabling Intel Speedstep, virtualization, and disabled triple buffering and VSync via ~/.drirc file all to no avail.
  11. OpenGL Stutter / Micro Stutter Even w/ VSync

      Yes, the stuttering persists even if I don't measure it or output it. 
  12. OpenGL Stutter / Micro Stutter Even w/ VSync

      There's the rub though. When I disable all the sleep code, and just have VSync enabled, it caps to 60fps. But it does not run at 16.66666666ms per frame. The image I posted a couple above shows how long each frame takes, and it is erratic. Sometimes the render takes 16ms, sometimes 16.7ms, sometimes 17ms.   When I disable the VSync and let it run at 800fps, the difference between each frame is even more noticeable:         As you can see, sometimes the image takes 5ms to render, sometimes it takes .6ms.    There is NOTHING different that happens from frame to frame, as you can see in the github.
  13. OpenGL Stutter / Micro Stutter Even w/ VSync

      Just edited the above post to show the amount of time the frames are taking, and yes my timer granularity was not sufficient.     Below is the timer code I have added. I also used this_thread::sleep_for(nanoseconds(.....))   to sleep  std::chrono::time_point<std::chrono::system_clock> start, end; start = std::chrono::system_clock::now(); //Do work end = std::chrono::system_clock::now(); std::chrono::duration<double> elapsed_seconds = end-start; float timer = elapsed_seconds.count() * 1000; std::cout<< "Frame Time: " << timer << "ms\n"; The frame-time is going higher than 16.66ms on occasion, and this is with just VSync turned on. When I disable VSync and manually force the time to sleep (using the aforementioned this_thread::sleep_for) for 16ms, 16.66ms, or 16.66666666ms I get the same jitter problem. Below is my sleep code: if(timer < 16.66) { float t = (16.66666666 - timer) * 1000000; cout<<"Sleeping for :"<<16.66 - timer<<" ms"<<endl; this_thread::sleep_for(nanoseconds((long)t)); } Here is the link to the source code - updated to have the frame timers     Again though, whether I have VSync enabled or not, whether it's 800fps or 60fps, and whether I implement timers to try to control the flow or not they ALL have the same stuttering problem.
  14. OpenGL Stutter / Micro Stutter Even w/ VSync

    I have in fact tried the glFinish(), as well as glFlush() and neither has impacted it =/  Aslo, github link to all the code posted above. Thank you!    
  15. OpenGL Stutter / Micro Stutter Even w/ VSync

    Thank you for your post and for the help!   I too thought it might be a timer issue, which is why I ripped all the timers out in my sample program. The sample program simply takes the image and each frame it moves its xPosition and yPosition +1. Since it's capped by VSync at 60fps, it moves 60 pixels per second across the screen. There are no timers that cap the framerate, it relies solely on VSync.    As for the 16-18ms, it usually shows 18ms as the amount of time per frame. I don't understand why though, as the only thing controlling this is VSync (and my monitor is 60hz refresh rate). So 16.6ms would seem right to me, but each frame seems to just take 18ms. And this is with no timers, no frame limiting beyond VSync.   And when I do enable timers to delay, pause, nanosleep, etc. I wind up with the problem being amplified.   Also, the loading of the image occurs only once, I just tried setting the processor affinity to only run on the first core and the problem still persisted, and lastly, I reformatted yesterday with a fresh install of 13.10 and killed all other running processes and it still stutters.   Here is the code I took out that just scrolls the background image across the screen. You may need to tweak the sconstruct's paths for it to build, as I made it for my systems' environments.   Thank you!     Edit: I have run the progam with high precision timers using Chrono from c++0x and I get the following output during jitter times   Frame Time: 16.6016ms Frame Time: 19.5782ms Frame Time: 13.6319ms Frame Time: 16.6807ms Frame Time: 16.5073ms   The above is an extreme example, but there are definitely moments where the framerate goes above 16.66 (see iamge):