• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.


  • Content count

  • Joined

  • Last visited

Community Reputation

145 Neutral

About martinis_shaken

  • Rank
  1. OpenGL

      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

    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  https://github.com/martinisshaken/Sample-SDL2-OpenGL-Program   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

        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

      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

    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

      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

      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

    Another update:   I have compiled and executed http://lazyfoo.net/tutorials/OpenGL/06_loading_a_texture/index.php   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. https://github.com/blinry/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 https://github.com/martinisshaken/Sample-SDL2-OpenGL-Program 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

        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

      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

      Yes, the stuttering persists even if I don't measure it or output it. 
  12. OpenGL

      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

      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)); } https://github.com/martinisshaken/Sample-SDL2-OpenGL-Program 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

    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

    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.   https://github.com/martinisshaken/Sample-SDL2-OpenGL-Program   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):