Messages

1

Graphics / Re: Framerate inconsistency

« on: October 04, 2016, 02:19:45 am »

To give you a little more detail, I work in cognitive neuroscience with a technique called frequency tagging. We oscillate the luminance of our stimuli at specific frequencies which induces a brain response to those stimuli at the same frequency. Any variability in timing adds noise the flicker frequency, which in turn adds even more noise to the neural response.

I could use a fixed time step to update the luminance at longer intervals, but ultimately the results will be better with a more clearly defined sinusoidal signal. I use a 144Hz monitor, so ideally I would alter the luminance of a stimulus the full 144 times within a second, with the same magnitude of change at each step.

I’ve been using V-sync without setframeratelimit(), so I’m on top of that at least.

My current workaround is to update the luminance according to the elapsed duration since the last iteration of the gameloop. This means that the change in luminance can be variable, but the flicker should at least approximate a sinusoid at the correct frequency. In order for this workaround to work, I would need the clocks to be accurate at least to the millisecond level. Do you know what sort of precision I could expect on a windows 7 system?

It’s been suggested to me that for really precise timing I should be using linux or even MS-DOS (:/). Any thoughts about whether the change might be worth it?

2

Graphics / Framerate inconsistency

« on: September 30, 2016, 03:59:21 am »

I'm using SFML to develop a program for an experiment, which requires extremely precise timing.

I usually write these experimental programs using a graphics toolbox in Matlab. Using this graphics toolbox, the program loops once for every monitor refresh. For example, on a 60Hz monitor, each loop runs for precisely 16.7ms.
Unfortunately, when using SFML, the timing between iterations of the game loop is much more variable; some iterations can take as long as 40ms - even I'm not presenting anything but a blank screen. In this situation, the game loop tends to compensate in that the next iteration is considerably faster. However, in my case, this is more of a hindrance than a help, because the iteration runs through before the next monitor refresh, which essentially means that whatever I was going to display during that frame is missed completely.

I've used "window.setVerticalSyncEnabled(true)" in order to synch the game loop to the monitor refresh rate. I've also found that using fullscreen mode helps a little. Yet the problem persists despite these measures.

Is there anything else I can do to reduce variability in the duration of my gameloop iterations?
One suggestion I've seen is to split updating and drawing into separate threads, would this result in a more consistent framerate?

Someone has also suggested to me that the inconsistency is actually in the clock, rather than the fliptime - the idea being that the timing is being inconsistently reported. I was planning to use the clock to correct for missed frames by basing the display on the elapsed time between flips rather than the number of frames, but this won't work if the reported clocktime is inaccurate...Does anyone know how accurate the clock timing is?

Thanks for the help!