A final word about frame and refresh rates:
A final word about frame and refresh rates:
A final word about frame and refresh rates:
A final word about frame and refresh rates:
A final word about frame and refresh rates:
A final word about frame and refresh rates: A final word about frame and refresh rates: A final word about frame and refresh rates: A final word about frame and refresh rates: A final word about frame and refresh rates: A final word about frame and refresh rates: A final word about frame and refresh rates: A final word about frame and refresh rates:
A final word about frame and refresh rates: A final word about frame and refresh rates:
A final word about frame and refresh rates:
Go Back  Xtreme Visual Basic Talk > > > > A final word about frame and refresh rates:


Reply
 
Thread Tools Display Modes
  #1  
Old 02-12-2010, 06:13 PM
jill_kitten's Avatar
jill_kitten jill_kitten is offline
Regular
 
Join Date: Apr 2006
Location: USA, WA
Posts: 77
Post A final word about frame and refresh rates:


A final word about frame and refresh rates:

I have seen a recurring theme in questions about DirectX frame rates [fps = Frames Per Second]...

People trying to "free" themselves from the monitor refresh rate or trying to achieve higher frame rates beyond their monitor refresh rates.

It is understandable for those that do not understand the behind the scenes hidden processes in DirectX and hardware drivers to not realize it, so please do not take this personally, but do let me note that this is an absurd idea as the only usefulness of it might be to determine more exactly how much time the rest of your code is eating up, and serves no real purpose in a final application. However, when you think about some basic things outside the realm of DirectX, video hardware, or programming, you can begin to understand.

The human eye/brain can only discern differences when the frame rate gets EXTREMELY low. Please note that a lot of internet players only run at 15fps, most movies are displayed at 22fps to 24fps while newer digitally created ones still at only 32fps, and having a monitor refresh rate of 60Hz (60fps) or higher is much more than enough.

Note that by trying to go outside your monitor refresh rate you incur artifacts like "tearing" or "flicker" (and slower swap chain back buffer copy effects) that can show up on some systems and not on others, while not achieving any useful end. This applies to using swap effects other than SwapDiscard (or SwapCopyVsync for windowed mode when scan lines cannot be read) and/or using an 'Immediate' presentation interval instead of a synchronized one.

If you can get the rest of your program to eat up enough processor time, it might jump down to 30fps (every other frame) or 20fps (every 3rd frame), which are really great frame rates. If even more is eaten up then it can go to 15fps or 12fps and it will still be good. Even more could make it 10fps, 8.6fps, 7.5fps, or less and depending on the type of monitor (like CRT, plasma, LCD, LED) different people will perceive these differently. However, this is NOT a problem of being vsync'd by using SwapDiscard (or SwapCopyVsync for windowed mode), it is a problem with slow code (like unneeded, unnecessarily accessed, or hidden code), and changing to another swap method will only slow things down even more due to frame copy effects and hidden additional swap chain back buffers you didn't create yourself.

The optimum swap effect to use is SwapDiscard as it avoids extra frame copies, hidden swap chain back buffers, and is synchronized with the refresh rate. WARNING: On some video card and monitor combinations a condition can exist where in Windowed mode the scan line cannot be determined and this can cause SwapDiscard to not be synchronized for your applications window. In this case, a setting of SwapCopyVsync can be used to overcome this as it copies the window when it gets the vertical synchronization signal. This condition can be tested for by checking the D3DCAPS8.Caps member for the D3DCAPS_READ_SCANLINE flag:
Code:
CanReadScanLine = CBool(D3DCAPS8.Caps And D3DCAPS_READ_SCANLINE)
If this is False while in WINDOWED mode then you should use SwapCopyVsync. However if you are using full screen mode (as opposed to windowed) then still use SwapDiscard as it will still synchronize because since it covers the entire screen the top line resides at the first scan line and it uses the vertical synchronization signal instead of trying to read the scan line for an application window and it still avoids extra swap chain back buffers and copy operations.

If your excuse is that you are trying to buy your program more time to work before the next frame or that it messes up your physics/AI/etc., then you either have your program physics/AI/etc. based on the frame rate instead of the actual time (and/or frame time) like it should, or you can freely allow it to present frames with the refresh rate and allow your program to make its calculations as it would like to and the frame rate will come as it will while still allowing computation time for when you have to work with more complex environments instead of it being eaten by more complex hidden code because you made it "free" of the refresh rate. If you so desire you could make the presentation interval every other frame or every 3rd frame so the time used in presenting the extra frames can be used for calculations, but I myself never bother adding the extra code needed to handle that.

Again, trying to "free" yourself from the vsync would only make your frame rates be able to go between the already mentioned frame rates, or pointlessly above it, and would only be more accurate in telling more exactly how much time it takes your program to present a frame while incurring slow downs and artifacts that you may or may not see but others certainly will.


Thank you for listening...
-Jill-

P.S. A single copy operation eats time: Width * Height * ColorBitDepth \ 8 = bytes to copy for a frame, and there can be additional copies, or additional swap chain back buffers which multiplies this when using Copy or Flip swap effects.

P.S.S. I would request that this be added to the 'Frequently asked DirectX 7/8 Questions' at
Frequently asked DirectX 7/8 Questions
, so that questions about this subject can be reduced.
__________________
Smeg!
"Oh Listy"..."Rimsy",.. ..."Ahghghaa!"

Linux Mint is way cool! [and super easy to install as a dual boot]

Last edited by jill_kitten; 02-13-2010 at 05:54 AM. Reason: Added P.S. and fixed typo
Reply With Quote
  #2  
Old 08-04-2011, 04:41 PM
DracullSoft DracullSoft is offline
Newcomer
 
Join Date: Mar 2010
Posts: 2
Default

Interesting post.

The main reason for free running framerates is to allow my games to run on all computers and make game logic independent of framerates.
Once that can be done, there are additional benefits. For example if you have a heavy effect like an explotion (e.g blowing up the death star into 1000 pieces) the games frame rate might go down on low end computers (notebooks etc) but the game speed will still run unaffected.
Another example is that I can simulate low end computers by forcing framerate to 20 or 25 fps to test if my game still looks nice or I can do a "Bullet effect" slowing gamespeed down by 10 times but still keep framerates up.

just my 2 cents around free running framerates.
Reply With Quote
  #3  
Old 09-27-2011, 03:30 PM
jill_kitten's Avatar
jill_kitten jill_kitten is offline
Regular
 
Join Date: Apr 2006
Location: USA, WA
Posts: 77
Default

Not to be flippant, but apparently you either didn't read the post or you don't understand it since the second [2nd] biggest point is to not use up all your processor cycles on rendering extra frames and the first [1st] biggest point is to allow your game logic to run INDEPENDENTLY from the rendering system!

You must NEVER base your physics or AI [game logic] on the frame rate of your rendering system! If you implement things in the way you have described then that is EXACTLY what you are doing! You MUST break your game [logic AI, physics, etc.] AWAY from the renderer and its frame rate or your game will be doomed to be a slave to it,.. which is what you want in accordance with your very first sentence, however by doing what you describe your game logic is clearly a slave to the frame rate. Again, you MUST break your renderer from the rest of your game system.

In Vb, one of the simplest ways to achieve this is to simply put your rendering system into an activeX 'exe' [thread pool = 1] allowing it to run independently of the rest of your game and be certain to provide a useful enough interface for it to be used effectively and in an independent way. Then it runs on its own thread eating the fewest number of processor cycles possible allowing the rest of those cycles to be used by the rest of your game. And THAT is how you can make it run on even lower end systems and thus an even a wider range of them!

When you have your renderer in an independent library like this you can even lower the number of frames rendered per second to still be within a pleasant visual acuity [as stated in the original post to take 60 fps and cut it to 30 or 20 fps] while/thus giving the rest of your game code even more processor cycles to play with! Making your renderer independent is KEY to allowing it to run on lower end systems [which I deal with often] and thus the widest range of computers.

Again, simply put: If you have to make it 'free run' to make the rest work, then clearly the rest is a slave to the rendering and thus NOT independent,.. AND you are wasting precious processor cycles on rendering all those multitudes of extra frames instead of giving it to the rest of your game code.

I hope this better clarifies the issue for you.

P.S. Note that using an active X 'exe' is not the 'best' way, but it is the easiest and least complicated way to achieve rendering Independence in Vb.
__________________
Smeg!
"Oh Listy"..."Rimsy",.. ..."Ahghghaa!"

Linux Mint is way cool! [and super easy to install as a dual boot]
Reply With Quote
  #4  
Old 01-17-2015, 01:08 AM
jill_kitten's Avatar
jill_kitten jill_kitten is offline
Regular
 
Join Date: Apr 2006
Location: USA, WA
Posts: 77
Arrow

A point of clarification:

Note that there would be no point in trying to render a frame if it will never be displayed [seen] and when you attempt to render frames faster than the monitor refresh [rendering calls between displayed frames], all it does is dump [waist] the previous frame which as a result was never displayed/seen and thus the time eaten to "render" it was entirely wasted!

That time could have been used for so many other things like physics, AI, etc., but instead all that executed code time was wasted to no avail and now gone forever!

Obviously this would make the system slow down in trying to execute code that served absolutely NO PURPOSE.

I hope that puts a final clarification on the pointlessness of going beyond the monitor refresh rate. Why would you do that?
__________________
Smeg!
"Oh Listy"..."Rimsy",.. ..."Ahghghaa!"

Linux Mint is way cool! [and super easy to install as a dual boot]
Reply With Quote
  #5  
Old 02-05-2015, 06:52 PM
Gruff's Avatar
GruffA final word about frame and refresh rates: Gruff is offline
Bald Mountain Survivor

Retired Moderator
* Expert *
 
Join Date: Aug 2003
Location: Oregon, USA - deceased
Posts: 6,440
Default

It's "[Waste]" not "[Waist]". Just saying.
__________________
Burn the land and boil the sea
You can't take the sky from me


~T
Reply With Quote
  #6  
Old 02-14-2015, 07:24 AM
jill_kitten's Avatar
jill_kitten jill_kitten is offline
Regular
 
Join Date: Apr 2006
Location: USA, WA
Posts: 77
Default Thanks for that, I must have been really tired...

Quote:
Originally Posted by Gruff View Post
It's "[Waste]" not "[Waist]". Just saying.
Thank you for that,.. That is quite odd for me, was I asleep when I wrote that? I seemed to get it right in the other places,... Oh well, thanks anyway for bringing that to my attention.
__________________
Smeg!
"Oh Listy"..."Rimsy",.. ..."Ahghghaa!"

Linux Mint is way cool! [and super easy to install as a dual boot]
Reply With Quote
  #7  
Old 02-14-2015, 07:29 AM
jill_kitten's Avatar
jill_kitten jill_kitten is offline
Regular
 
Join Date: Apr 2006
Location: USA, WA
Posts: 77
Arrow A point of clarification...

A point of clarification:

Note that there would be no point in trying to render a frame if it will never be displayed [seen] and when you attempt to render frames faster than the monitor refresh [rendering calls between displayed frames], all it does is dump [waste] the previous frame which as a result was never displayed/seen and thus the time eaten to "render" it was entirely wasted!

That time could have been used for so many other things like physics, AI, etc., but instead all that executed code time was wasted to no avail and now gone forever!

Obviously this would make the system slow down in trying to execute code that served absolutely NO PURPOSE.

I hope that puts a final clarification on the pointlessness of going beyond the monitor refresh rate. Why would you do that?
__________________
Smeg!
"Oh Listy"..."Rimsy",.. ..."Ahghghaa!"

Linux Mint is way cool! [and super easy to install as a dual boot]
Reply With Quote
Reply

Tags
directx, fps, frame rate, monitor, refresh


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Forum Jump

Advertisement:





Free Publications
The ASP.NET 2.0 Anthology
101 Essential Tips, Tricks & Hacks - Free 156 Page Preview. Learn the most practical features and best approaches for ASP.NET.
subscribe
Programmers Heaven C# School Book -Free 338 Page eBook
The Programmers Heaven C# School book covers the .NET framework and the C# language.
subscribe
Build Your Own ASP.NET 3.5 Web Site Using C# & VB, 3rd Edition - Free 219 Page Preview!
This comprehensive step-by-step guide will help get your database-driven ASP.NET web site up and running in no time..
subscribe
A final word about frame and refresh rates:
A final word about frame and refresh rates:
A final word about frame and refresh rates: A final word about frame and refresh rates:
A final word about frame and refresh rates:
A final word about frame and refresh rates:
A final word about frame and refresh rates: A final word about frame and refresh rates: A final word about frame and refresh rates: A final word about frame and refresh rates: A final word about frame and refresh rates: A final word about frame and refresh rates: A final word about frame and refresh rates:
A final word about frame and refresh rates:
A final word about frame and refresh rates:
 
A final word about frame and refresh rates:
A final word about frame and refresh rates:
 
-->