Refersh Rate - Is Vertical Sync Independent Of It

zparticle · September 15, 2003, 7:03pm

Is it correct to assume that the vertical sync period (the time it takes the electron beam to get back to the top left corner of the screen from the bottom right corner) is shorter at higher refresh rates?

It seems like this should be a fixed length of time, not affected by refresh rate.

[edit]

Or perhaps since it is a deflection via a magnetic field this timing is simply a monitor induced delay to get the specified refresh rate and therefoe it should “take longer” at lower refresh rates.

princec · September 16, 2003, 1:02am

Who knows? Doesn’t really make any difference if it is, because you’ll be double buffering 8)

Cas

zparticle · September 16, 2003, 12:04pm

Well, in this case is does matter because I’ve been asked to write a chapter for a new Java book that is coming out and I don’t want to be giving people the wrong information.

[edit]

I’m trying to understand if you actually have less time to perform your drawing at higher refresh rates.

Mojomonkey · September 16, 2003, 12:14pm

Here’s something I found regarding the Cathode Ray Tube Controller spec:

Vertical Timing

The Vertical Timing section consists of the Scan Line Counter, Character Row Counter, Registers R4 through
R9, the Vertical Control logic block, and associated Coincidence Circuits.

The Scan Line Counter counts from zero until coincidence with Register R9 synchronously resets the Scan Line
Counter and synchronously increments the Character Row Counter. The Scan Line Counter counts the Scan
Lines composing a character row, and the Character Row Counter counts the character rows comprising a
vertical frame.

The Character Row Counter coincidence with R4 and the residual Scan Line count represented by R5 marks the
end of a vertical frame.

The Character Row Counter coincidence with Register R6 marks the end of the active display portion of the
vertical frame measured in character rows.
The Character Row Counter coincidence with Register R7 marks the beginning of vertical retrace with Vertical
Sync (VS) going active high. VS remains high for a fixed period of 16 scan lines.

Register R8, Interlace Mode Register, effects the Vertical Timing according to its programming. Normal Sync
(Non-Interlace) mode displays the same field each frame. Interlace Sync Mode splits a frame into even and
odd fields. Vertical Sync (VS) active high is delayed one-half scan line at the end of even fields. For Interlace
Sync & Video Mode, in addition to the VS delay on even fields, the Row Address counter sequences on even
fields through 0,2,4,… counter values while on odd fields, through 1,3,5,… counter values.

Seems like your second guess would be right.

princec · September 16, 2003, 12:31pm

zp, if you’re trying to understand that you’re sort of going off at a tangent.

The refresh rate of the monitor determines the exact amount of time you have to draw a frame if you want it drawn without tearing or missing a frame if you are synchronizing to it. At 50Hz, it’s 20ms. At 100Hz it’s 10ms. The speed at which the electron gun zips back to the top left has no effect on the refresh rate and hence no effect on the time you have to complete your drawing. LCD and plasma displays work differently anyway.

If you are not synchronizing to refresh rate it doesn’t matter one bit how fast your drawing is; you’ll get tearing.

If you are doing any kind of graphics animation you must double-buffer your display or you will get rendering in various random stages of production scanning down the screen.

Cas

zparticle · September 16, 2003, 12:43pm

Ah, I see. So I was missunderstanding the situation. So you’re executing your game logic while the frame is being displayed NOT while you are in the vertical retrace period. Is that correct?

If so then you still have some timing issues to cope with because you need to be able to render the new frame inside of the time in takes the monitor to display a single frame. Less time at higher rates.

Duh, sometimes my mind simply doesn’t function. BTW I would really like some feedback on the chapter before I submit it to the publisher. I’m not quite ready to let people look it over yet but if anyone is interested in helping me not spread incorrect information please drop me a note at scott_shaver2000@yahoo.com .

erikd · September 23, 2003, 6:57pm

[quote]So you’re executing your game logic while the frame is being displayed NOT while you are in the vertical retrace period. Is that correct?
[/quote]
When you vsync, the only thing that you’ll do at vertical retrace is flipping your display buffers because that’s the only period the monitor is not drawing to screen so flipping the buffers is ‘invisible’ at that time. The rest of the time is drawing to the back buffer and executing game logic etc.
When you’re not syncing to your monitor, you’ll be flipping buffers when the monitor somewhere in the middle of drawing a frame, which will result in partial screen buffers being rendered. Which is called tearing. Which is why switching on vsync in your display drivers will result in smoother animation, even though the fps of your game might be lower than when you don’t enable vsync.

Hope this helps.

Erik