Jump to content
  • Advertisement
Sign in to follow this  
SpriteChild

Refresh rate issue or eye limitation?

This topic is 3340 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi guys, I'm a bit confused on what I'm running into. I've been playing around creating an oscilliscope for music, and although it seems to be working, the line changes so quickly that instead of seeing 1 line, I'm typically seeing 2 or 3. I'm using a windowed view with D3DPRESENT_INTERVAL_DEFAULT, and when tracking the framerate, its going around 60 FPS. I've tried restricting the framerate down to 30 through sleep calls, but this only makes the situation slightly better, and it doesn't seem like something I should be doing anyway (don't games strive to hit 60 FPS?). When I pause the rendering, only one line is visible, so I'm fairly positive this is just my eyes thinking these "ghost" lines are still there, but has anyone had a similar problem and been able to do anything about it? Or is it just something we deal with? Thanks!

Share this post


Link to post
Share on other sites
Advertisement
If you're looking to simulate an oscilloscope, then forget about what games "strive" for. An oscilloscope is intended to display information useful to the user and should adjust its refresh rate to that end.

If the refresh rate is too high, as you've discovered, you'll just see a jumble of information which may or may not be useful to the eye.

A more useful approach may be to have an adjustable trigger rate (how often the display gets erased) as well as an adjustable display width (how many seconds or milliseconds of data appears horizontally). This allows the user, for example, to trigger at 1/3 of the frequency of interest but adjust the width to show 3 cycles at that frequency.

In general, the display would persist (not be erased) for the trigger interval, even if, at low frequencies, you see the data being drawn across the screen. That's how oscilloscopes work.

And don't confuse trigger rate with your screen refresh rate. You can still draw the display as often as you like, but: draw the same info, adding only new data points since the last draw. And don't erase the background except between triggers as that will cause flicker.

Share this post


Link to post
Share on other sites
One thing you can do is make sure the start of the display is triggered when the value goes from negative to positive. Probably implemented as an option as it drops some data.

With that enabled if the input is some kind of reasonably sensible waveform (e.g. a sine wave or music) then you'll get a much more stable output.

Share this post


Link to post
Share on other sites
Thanks for the responses guys.

I guess I should have probably specified that I had no real idea what an oscilloscope was, beyond something that looked like a cool means of visualization on Winamp, which was basically the implementation I was striving for -- displays fast enough so its constantly changing, but it isn't so fast that it makes you think you're seeing multiple lines. To that end, I implemented Buckeye's suggestion, and by manually incrementing the trigger rate, I can get the display to something I'm comfortable with.

Because my ultimate goal for this thing is to use it as a debugging aid for beat-detection, it probably helps to understand oscilloscopes at a deeper level; from what I can gather from the responses, it's nothing more than the entire waveform of the music, pushed along as the song moves along. And, given that I'm only sampling a small history of the music at any one point (I'm only getting the last 64 samples), it makes sense that the display is all over the place.

Anyhow, I guess I don't really get Adam's or undead's suggestions.

Adam, when you say negative to positive, do you mean basically monitor a specific sample of the current wave, and then only trigger everytime that sample reverses sign? It sounds like this might just be a useful heuristic to getting a smoother display rather than something with a deeper purpose?

undead: what do you mean by interpolation? I thought my problem was data updating too quickly...if I drop data and then replace those frames with in-between ones that make more sense (even if they aren't the real wave), won't I just get the same effect, albeit the lines will be closer together?

Thanks again for everyone's help.

Share this post


Link to post
Share on other sites
Quote:
Original post by SpriteChild
undead: what do you mean by interpolation? I thought my problem was data updating too quickly...if I drop data and then replace those frames with in-between ones that make more sense (even if they aren't the real wave), won't I just get the same effect, albeit the lines will be closer together?

In thory an oscilloscope is nothing but something displaying a function onscreen. I assume you have N horizontal pixels, updated at a rate of X hz.

Let's consider a single pixel. This pixel changes his Y value "randomly" 60 times every second. Interpolation helps because the transition between one coordinate and another will be smoother. If you update your function at 15hz, it's going to be much more smooth, since raw data could be.. uhm.. very raw!

The advantage is you don't need to drop frames. I mean... you decide which is the target value of that pixel for the next interpolation, so if you find meaningful data, you could save it and pass it to the next time you submit new target values. If you have a peak between the data you don't visualize, you can save it and submit it later. All you need to do is to divide the raw data reading part from the interpolation one, then send photographs of the target function every X frames. :)

I'm playing with something like that (not an oscilloscope, a set of objects updated very often), I'll see if I can post a video of that later, and interpolation is a pleasure to see, compared to raw data.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!