Main > Main Forum

Vertical Refresh Rate: set by game software or monitor hardware?

<< < (3/5) > >>

MonMotha:
Gah, I had a nice, long reply to this typed out, but smurfing SMF ate it when I accidentally hit the back button.

Essentially what you need to know is this: your impressions of LCD monitors being "purely fixed frame rate" are largely wrong.  Just like "fixed rate" CRTs, LCDs will accept a certain range of input refresh rates and WILL ACTUALLY REFRESH THE DISPLAY AT THAT RATE.  The exact range depends on the design of the monitor and are usually further limited by the panel and its accompanying driving electronics.  Common ranges are 47-63, 57-75, and 47-75Hz, but others of course exist.  What your monitor will do when presented with something outside this range depends on what the designer told it to do: some will attempt to convert while others will give an "out of range" error.  Since all LCD monitors have scalers, anyway (since they ARE fixed pixel resolution devices), it's usually not terribly hard to include frame rate conversion, but it simplifies the scaler chain substantially to avoid it.

Of course, there may exist some brain-dead monitor designs out there that attempt to convert all inputs to the monitor's idea of its "frame rate".  I don't know WHY you'd do it that way, but it's of course possible.  I've never seen one.  If you have one, I'd suggest defenestrating it.


As to proper PC programming practice, I think you misunderstood me.  I did not mean that one should simply render frames as whatever rate and "do nothing" (which results in tearing) to display them.  One needs to be aware that there WILL be a discrepancy between what framerate one asks for and what one actually gets (it will probably be fairly small, <1Hz, but it will be there).  If one is rendering stuff on the fly, it's not hard to make sure that a single frame is always ready when the user's hardware needs a new one.  Waiting for vsync or using triple buffering will do just that and avoid tearing artifacts.

Indeed, this is probably one of the earlier lessons in a computer graphics curriculum.

What I meant was that using the actual refresh rate (whatever it may be) as an indicator of elapsed "wall time" (based on your requested framerate) is a BAD idea on a PC.  Suppose you have a pre-rendered animation of a clock that is rendered at 60FPS.  If you just blindly assume that you should have a 1:1 mapping between source frames and output frames, your animation will eventually show the wrong time.  You somehow need to handle the small difference between your "perfect 60FPS" notion in the input material (which is fine, since you have to pick SOMETHING for pre-rendered material) and the actual output frame rate.  Usually, duplicating/dropping frames is fine.  It avoids messy interpolation and doesn't have any tearing issues.

Note that it's common practice to use the vsync rate on consoles and arcade game hardware as an indication of wall time.  It can simplify program design to do so, and consoles and arcade game boards can be carefully controlled and characterized to guarantee a certain output framerate.  The vast differences in PC hardware and driver configurations make this relatively impossible in a PC environment unless you have full end-to-end control over the hardware and software.


If MAME is requesting "244x288" from GDI or DirectX, then that's almost surely a "visible" or "active" pixel count.  You can measure this in hardware, too.  Measure the number of hsync pulses between vsync active edges (you have to use a single edge and not the pulse since there are a few lines during vsync, fortunately most counters support this).

torino:

--- Quote from: MonMotha on March 28, 2011, 08:06:30 am ---Gah, I had a nice, long reply to this typed out, but smurfing SMF ate it when I accidentally hit the back button.

Essentially what you need to know is this: your impressions of LCD monitors being "purely fixed frame rate" are largely wrong.  Just like "fixed rate" CRTs, LCDs will accept a certain range of input refresh rates and WILL ACTUALLY REFRESH THE DISPLAY AT THAT RATE.  The exact range depends on the design of the monitor and are usually further limited by the panel and its accompanying driving electronics.  Common ranges are 47-63, 57-75, and 47-75Hz, but others of course exist.  What your monitor will do when presented with something outside this range depends on what the designer told it to do: some will attempt to convert while others will give an "out of range" error.  Since all LCD monitors have scalers, anyway (since they ARE fixed pixel resolution devices), it's usually not terribly hard to include frame rate conversion, but it simplifies the scaler chain substantially to avoid it.

Of course, there may exist some brain-dead monitor designs out there that attempt to convert all inputs to the monitor's idea of its "frame rate".  I don't know WHY you'd do it that way, but it's of course possible.  I've never seen one.  If you have one, I'd suggest defenestrating it.

--- End quote ---

I see, and I'm surprised to hear that. Ok, so we agree there is a big difference between "converting" and "adjusting" the frame rate, but still you say most LCDs can vary their vertical refresh rate around 60Hz like CRTs can? I'm convinced they can't and are either totally fixed at 60Hz or have PAL/NTSC converter built-in, which doesn't work with small differences like +0.60601Hz as that choppiness is too sparse for converter to smooth out without introducing considerable lag, all of which does work great with movies, but is not really too desirable in interactive application like games.

In any case, none of my laptops can properly sync to any of MAME games that are not EXACTLY 60Hz, and you say your LCD can? Can you please then make a photo of MAME running Galaga and LCD OSD screen showing 60.606061Hz, or something like that?



--- Quote ---As to proper PC programming practice, I think you misunderstood me.  I did not mean that one should simply render frames as whatever rate and "do nothing" (which results in tearing) to display them.  One needs to be aware that there WILL be a discrepancy between what framerate one asks for and what one actually gets (it will probably be fairly small, <1Hz, but it will be there).  If one is rendering stuff on the fly, it's not hard to make sure that a single frame is always ready when the user's hardware needs a new one.  Waiting for vsync or using triple buffering will do just that and avoid tearing artifacts.

Indeed, this is probably one of the earlier lessons in a computer graphics curriculum.

What I meant was that using the actual refresh rate (whatever it may be) as an indicator of elapsed "wall time" (based on your requested framerate) is a BAD idea on a PC.  Suppose you have a pre-rendered animation of a clock that is rendered at 60FPS.  If you just blindly assume that you should have a 1:1 mapping between source frames and output frames, your animation will eventually show the wrong time.  You somehow need to handle the small difference between your "perfect 60FPS" notion in the input material (which is fine, since you have to pick SOMETHING for pre-rendered material) and the actual output frame rate.  Usually, duplicating/dropping frames is fine.  It avoids messy interpolation and doesn't have any tearing issues.

Note that it's common practice to use the vsync rate on consoles and arcade game hardware as an indication of wall time.  It can simplify program design to do so, and consoles and arcade game boards can be carefully controlled and characterized to guarantee a certain output framerate.  The vast differences in PC hardware and driver configurations make this relatively impossible in a PC environment unless you have full end-to-end control over the hardware and software.

--- End quote ---

What you are talking about I call "temporal resolution", or precision of motion processing, which may be important in physical simulation, but still needs to sync its graphical output with monitor if fluid animation of its visual representation is desired.


.   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .  

...... ......................... ...................... .....


You are talking about density and quantity, but I'm talking about timing and regularity. Consider that even 25Hz of steady and uniform distributed frames in time will give you better and smoother animation than uneven 100Hz. Only doubles work "correctly", only scaling 30Hz to 60Hz (doubling) or say 50Hz to 25Hz (downscaling) is still somewhat authentic, or to say is "least noticeable" difference.



--- Quote ---If MAME is requesting "244x288" from GDI or DirectX, then that's almost surely a "visible" or "active" pixel count.  You can measure this in hardware, too.  Measure the number of hsync pulses between vsync active edges (you have to use a single edge and not the pulse since there are a few lines during vsync, fortunately most counters support this).

--- End quote ---

EDITED.. ok, yes that sounds great, only I can't get any reading with my multi-meter, but if you are correct about most LCDs being able to vary their refresh rate around 60Hz and sync correctly with MAME's Galaga 60.606061Hz, then I just need to find a proper monitor and problem solved, thank you very much... unless you are wrong. :-)

torino:

--- Quote from: Calamity on March 28, 2011, 07:47:44 am ---Consider this random game, "motos", that has it's xml data complete, let's calculate it's vfreq:

      <chip type="cpu" tag="maincpu" name="M6809" clock="1536000"/>
      <chip type="cpu" tag="sub" name="M6809" clock="1536000"/>
      <chip type="audio" tag="namco" name="Namco 15XX" clock="24000"/>
      <display type="raster" rotate="90" width="288" height="224" refresh="60.606061" pixclock="6144000" htotal="384" hbend="0" hbstart="288" vtotal="264" vbend="0" vbstart="224" />

So you have a visible resolution of 288 x 244, but the total resolution is what matters:

htotal x vtotal = 384 x 264 = 101376 total pixels per frame

Now we need the dotclock. This one is probably an integer multiple of the cpu master clock, here:

dotclock = 4 x master_clock = 4 x 1536000 = 6144000 Hz (this was just to explain where the pixclock value in xml data comes from)

Now we calculate vfreq:

vfreq = 6144000 / 101376 = 60,60606061 Hz

- htotal and vtotal can be obtained by reverse engineering the pcb hardware.
- master clock frequency too.

That's the theoretical vfreq. Then of course you can plug an oscilloscope to the vsync output and check for the actual value obtained.


--- End quote ---

Thank you, that's brilliant, it really is. I trust your mathematics, however the question remains - where did those numbers come from? We can plug in many different numbers in there and get all kinds of numbers as a result... EDIT: so I need damn oscilloscope, and I was hoping I could take some fancy multimeter from my dad's garage to do this, huh.

Why do you think CPU would work in multiples of refresh rate? Could it be their measurement was influenced by the regularity of video interrupt so it only _appeared to their instruments as if CPU works like that while it actually does not? Would you really be surprised if I tell you my Galaga PCB just so happens to work with my totally fixed 60Hz LCD monitor and OSD says it's being run at exactly 60.00Hz?

Calamity:

--- Quote from: torino on March 28, 2011, 09:52:27 am ---where did those numbers come from?
--- End quote ---

Some may be guessed, some actually measured, I don't know how they're actually doing it, but I trust this information as the best one available, and in fact these values change sometimes as Mame is updated, probably due to more exact measurements being done.


--- Quote from: torino on March 28, 2011, 09:52:27 am ---We can plug in many different numbers in there and get all kinds of numbers as a result...
--- End quote ---

Well not so many indeed, horizontal values are actually 'characters' not pixels, so they are always multiples of 8. Master clock frequency is usually a known value. Total number of lines (vtotal) is actually measurable with an oscilloscope. Vertical refresh too. So you don't have so many possible combinations of htotal, vtotal, dotclock that can produce a measured vfreq.


--- Quote from: torino on March 28, 2011, 09:52:27 am ---Why do you think CPU would work in multiples of refresh rate?
--- End quote ---

No, I didn't say that. Refresh rate here is the final result. It's the dotclock the one that is probably an integer product of the master clock, applying a logic of simplicity, these machines probably had a master oscilator and the rest of frequencies may have been obtained by multiplying or dividing that master frequency by an integer value.


--- Quote from: torino on March 28, 2011, 09:52:27 am ---Could it be their measurement was influenced by the regularity of video interrupt so it only _appeared to their instruments as if CPU works like that while it actually does not? Would you really be surprised if I tell you my Galaga PCB just so happens to work with my totally fixed 60Hz LCD monitor and OSD says it's being run at exactly 60.00Hz?
--- End quote ---

Unfortunately I'm not a native English speaker so can't deal with irony here in the way I'm used to when using my language. Anyway, I have the feeling your style sounds familiar to me.

MonMotha:
If you honestly want this troubleshooted, you will need to define "sync up".  I'm suspecting a simple driver issue which may or may not be easily resolved.

I'd also suggest being less aggressive.  You're coming off as a bit trollish.  In fact, you remind me of a friendly forum troll we know as driver-man.  If that's not who you are, trust me when I say you don't want to be mistaken for this person.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version