4 ms·

This is an issue that I've been interested lately. I've been prototyping a yet-another-gl-context-lib (like sdl,glut), and this is one of the issues that I want

by scoopr 15y ago

This is an issue that I've been interested lately. I've been prototyping a yet-another-gl-context-lib (like sdl,glut), and this is one of the issues that I wanted to focus on. On apple platforms, there is CVDisplayLink (osx) and CADisplayLink (ios), that triggers a notification on the vsync interrupt, which should give rock solid framerate-stability with minimum cpu-usage. I've yet to find similar solutions to other modern platforms, which is a little disappointing. Though there is hope that vsync swapping is implemented little more sanely on other platforms. Also dwm (windows compositing window manager) has some more knobs to tune, don't know if they help. For the input-lag, handling messages in a different thread than rendering should work, but doesn't help with battery-draining. And also the input that comes as messages (keys, mouse) have timestamps on them, not sure if they are granular enough though. So while it might come with lag, at least you should be able to simulate the game state so it makes sense with the inputs you've provided I wonder, do media players on windows work with pure luck or do they attempt some kludges try to keep the framerate stable, without burning the cpu/battery?

blackhole 15y ago
Running an input thread side-by-side only partially solves the problem by simply increasing the chances that a key hit will be detected before the render is completed. Unfortunately, most input detection, by necessity, is done near the start of the render loop. Consequently, the vast majority of the render time will still be spent with most of the inputs locked in, resulting in little to no reduction in input lag. I should also note that windows really, really hates it when you try to do this.
exDM69 15y ago
Please, give a link to your gl context library. I've written one too (http://libwm.googlecode.com http://libwm.googlecode.com - use latest tag, not master branch). OpenGL infrastructure is so damn complicated - internally and externally. It seems to be impossible to write 3d graphics that work well in a modern environment when our API's are designed in the 1990's.
- scoopr 15y ago
  If you remember, we've talked over irc =) I actually at first tried to improve upon libwm, but didn't go too far with it. There were some design points I disagreed with, and you've seemed to stop updating, so I've started prototyping on my own codebase. I wanted some simplicity, and make it easier for various ffi-bridges, so I went with plain c. The code is too raw, so I won't link to it, but I'll definitely make some noise when I think it is at usable state.
  - exDM69 15y ago
    The FFI point was a factor why I have not used/updated libwm recently. libwm is C++ with constructors, destructors and exceptions. The semantics of C++ make it poor for FFI. Some interpreter-based languages can somewhat do it (e.g. python), but on a compiler based language like Haskell it becomes a bit painful. Another factor was that libwm supports a lot of legacy API's, like GLX 1.0. I wanted to support my g/f's crappy intel based macbook because at the time I was sometimes stuck that as my only computer. Anyways, the morale of the story is: don't write system level libraries in C++ unless you want to spend the rest of your life writing C++.

by scoopr 15y ago

blackhole 15y ago

Running an input thread side-by-side only partially solves the problem by simply increasing the chances that a key hit will be detected before the render is completed. Unfortunately, most input detection, by necessity, is done near the start of the render loop. Consequently, the vast majority of the render time will still be spent with most of the inputs locked in, resulting in little to no reduction in input lag. I should also note that windows really, really hates it when you try to do this.

exDM69 15y ago

Please, give a link to your gl context library. I've written one too (http://libwm.googlecode.com http://libwm.googlecode.com - use latest tag, not master branch). OpenGL infrastructure is so damn complicated - internally and externally. It seems to be impossible to write 3d graphics that work well in a modern environment when our API's are designed in the 1990's.

scoopr 15y ago
If you remember, we've talked over irc =) I actually at first tried to improve upon libwm, but didn't go too far with it. There were some design points I disagreed with, and you've seemed to stop updating, so I've started prototyping on my own codebase. I wanted some simplicity, and make it easier for various ffi-bridges, so I went with plain c. The code is too raw, so I won't link to it, but I'll definitely make some noise when I think it is at usable state.
- exDM69 15y ago
  The FFI point was a factor why I have not used/updated libwm recently. libwm is C++ with constructors, destructors and exceptions. The semantics of C++ make it poor for FFI. Some interpreter-based languages can somewhat do it (e.g. python), but on a compiler based language like Haskell it becomes a bit painful. Another factor was that libwm supports a lot of legacy API's, like GLX 1.0. I wanted to support my g/f's crappy intel based macbook because at the time I was sometimes stuck that as my only computer. Anyways, the morale of the story is: don't write system level libraries in C++ unless you want to spend the rest of your life writing C++.