Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (475)
Games in Android Showcase (106)
games submitted by our members
Games in WIP (530)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Refersh Rate - Is Vertical Sync Independent Of It  (Read 1706 times)
0 Members and 1 Guest are viewing this topic.
Offline zparticle

Senior Member




Thick As A Brick


« Posted 2003-09-15 21:03:59 »

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.

Online princec

JGO Kernel


Medals: 339
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #1 - Posted 2003-09-16 03:02:55 »

Who knows? Doesn't really make any difference if it is, because you'll be double buffering Cool

Cas Smiley

Offline zparticle

Senior Member




Thick As A Brick


« Reply #2 - Posted 2003-09-16 14:04:05 »

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.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Mojomonkey

Senior Member




ooh ooh eee eeee


« Reply #3 - Posted 2003-09-16 14:14:20 »

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

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.

Don't send a man to do a monkey's work.
Online princec

JGO Kernel


Medals: 339
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #4 - Posted 2003-09-16 14:31:13 »

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 Smiley

Offline zparticle

Senior Member




Thick As A Brick


« Reply #5 - Posted 2003-09-16 14:43:23 »

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 .

Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #6 - Posted 2003-09-23 20:57:09 »

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?  

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

Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

ctomni231 (32 views)
2014-07-18 06:55:21

Zero Volt (28 views)
2014-07-17 23:47:54

danieldean (24 views)
2014-07-17 23:41:23

MustardPeter (25 views)
2014-07-16 23:30:00

Cero (40 views)
2014-07-16 00:42:17

Riven (42 views)
2014-07-14 18:02:53

OpenGLShaders (29 views)
2014-07-14 16:23:47

Riven (29 views)
2014-07-14 11:51:35

quew8 (26 views)
2014-07-13 13:57:52

SHC (63 views)
2014-07-12 17:50:04
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!