Can some explain the "hz" parameter?
BlitzMax Forums/BlitzMax Beginners Area/Can some explain the "hz" parameter?
| ||
| I'm kind of lost on the hz parameter in the graphics command. I thought if it was 0 it would default to whatever the card is set at, but I "think" BMax is forcing it into 60hz mode if = 0. Can someone explain in detail what this parameter does? Thanks! |
| ||
I used to know the answer...I think it may be different in Windowed mode from full-screen too. OK I think the Hz param is used by Bmax to do the timing if you use Flip-1. Remember Flip 0 = no vysnc, and Flip 1 = vysnc and Flip-1 = use the Hz param. Flip - 1 can be used for a basic game timing but I never personally liked it. Mark or Skidracer once explained it to me. Yeah here's the docs:If sync is 0, then the flip occurs as soon as possible. If sync is 1, then the flip occurs on the next vertical blank. If sync is -1 and the current graphics object was created with the Graphics command, then flips will occur at the graphics object's refresh rate regardless of whether or not the graphics hardware supports such a refresh rate. If sync is -1 and the current graphics object was NOT created with the Graphics command, then the flip will occur on the next vertical blank. So Flip -1 will flip with Vsync off as your Hz param. If Hz param is 0, not sure what it does then... A while ago I hassled BRL to get Vysnc in Windowed mode when using Flip 1 and there was some info then about Flip -1 too, you might be able to find it via a search. |
| ||
| uh weird wide post... |
| ||
| Thanks GA! The flip command I "think" I have a grasp for, and your excellent info helps clear that up, thank you very much. ;) But...in the graphics() command there is a parameter for "hz" which according to the docs: "The hertz parameter selects a refresh rate, which refers to the number of times the screen refreshes per second. The refresh rates available depend on the graphics modes available, which differ from graphics card to graphics card. Note that creating graphics with an unsupported refresh rate will not fail - instead, a default refresh rate will be used." I always just pass it a "0" because I thought this would cause the hardware to use a default value, but I think this is causing Blitzmax to try to default to 60hz. I'm hoping there is a way that doesn't mess with the user's refresh rate. I've read where alot of users don't like games to mess with their refresh rate. |
| ||
| Actually I think you are right. 0 defaults to 60Hz. But NOT the display, just a Blitz timer as I explained badly. |
| ||
| If you leave it blank (null raher than 0) then *I think* it takes the current display rate. How this matches with the flip command... no idea. There just seems to be too many permutations of Graphics hz, flip and modes |
| ||
| I think the best way to test it is to compare results with MilliSecs() against some kind of counter before each flip and go with different hz values in fullscreen and window mode. I also wonder how the hz might be affected when 1 loop before the command flip will take longer than 1sec / frequency... Just wanna know if we can rely on something to be sure a game will run at the same speed on different computers now and in the future. |
| ||
| The internal Flip timer is *always* set to the value of Hz, with a Null (or negative) value defaulting to 60Hz. Under DX, the refresh rate will be set to the value of Hz if available at that particular resolution otherwise dropping to the default refresh rate (as set by the drivers) and it'll fall back to 60Hz* if that fails. AFAIR, GL will just drop straight to 60Hz* if the refresh rate at a particular resolution is unavailable. *When I say 60Hz, I assume that BMax (or rather the API) uses the lowest available refresh rate. More here... http://blitzbasic.com/Community/posts.php?topic=57862 |
| ||
| Thanks Yan, that post is very usefull to me... I was always a bit worried when 60Hz would dissapear in hardware what would happen to older games. I think Flip -1 is the safest option for me to use if a reliable speed is most important. |
| ||
I've been searching through the source code and I can't find anything to verify what I hope it's doing. In the DX8 docs, the parameter is handled as follows:
CONST_D3DPRESENT_RATE_FLAGS
Defines the maximal rate at which frames can be presented to the output.
Enum CONST_D3DPRESENT_RATE_FLAGS
D3DPRESENT_RATE_DEFAULT = 0
D3DPRESENT_RATE_UNLIMITED = 2147483647 (&H7FFFFFFF)
End Enum
D3DPRESENT_RATE_UNLIMITED
The presentation rate runs as quickly as the hardware can deliver frames.
D3DPRESENT_RATE_DEFAULT
Microsoft® Direct3D® will choose the presentation rate, or adopt the current rate if windowed.
So D3DPRESENT_RATE_DEFAULT which equals 0, would cause the hardware to handle the refresh rate. Ofcourse this is for DX8 but I'm hoping it's handled the same in DX7. So I hope passing a value of 0 will cause the Blitzmax code to pass a 0 to the d3d driver which in turn should cause a default value processed. Perhaps it's time for an offical answer on this. ;) |
| ||
| Graphics 640,480,0 - Will open in windowed mode on the desktop. - The hardware hz rate will be the same as the hz rate of the desktop display, depending on what resolution/hz rate you've chosen for it in the operating system. - Flip 1 will sync to the hardware vertical blank refresh, so if your desktop resolution is refreshing at 72Hz then Flip 1 will sync to 72Hz and be matched to the vertical blank to avoid tearing. - Flip -1 or just Flip without a parameter will use a default software timer set to 60Hz which will only flip the backbuffer 60 times per second even if your desktop display is refreshing at 72, which can and does lead to tearing because it's not synchronized with the vertical blank. - Also you'll get the same bit-depth as the desktop so if your desktop is 16-bit your display is going to be 16-bit. However, having said that, and depending entirely on the driver/implementation of your graphics api (opengl or directx) you may very well be working with 32-bit textures and a 32-bit backbuffer even if when it is *flipped* (gets copied from the backbuffer to the screen) it may convert the data from 32-bit to 16-bit on the fly, or even dither it. However if you asked for 16-bit you may force it to be a 16-bit format internally. I noticed significant differences in the speed of Flip depending on whether I tried to force 16-bit or to allow it to convert 32-bit to 16-bit. I don't remember whether specifying a bit-depth of 0 gives you windowed mode or whether it's specifying a hz of 0. I'm inclined to think it's the bit depth. So if you specify 640,480,0,85 and you use Flip -1 you'll get an 85hz software timer attempting to run on whatever hz rate your desktop is. But if you specify 640,480,0,85 and you use Flip 1 you'll get vertical blank sync which will run at the desktop's hz rate. Graphics 640,480,32[,hz] or Graphics 640,480 by itself: - will open in full screen mode and if you specify a hz rate it will *attempt* to open a resolution with that specific *harware* hz rate. ie the display hardware actually refreshes the monitor/screen at that rate if your hardware supports that mode. - If your hardare e.g has a 1024x768 32-bit mode running at 75hz, you can say Graphics 1024,768,32,75 and it will try to open that mode. If successful, and you use Flip 1, it will sync to the vblank and run at 75hz. If it is not successful and lets say it openes at 60hz instead (but same res and bit depth), then flip 1 will sync at 60hz while flip -1 will try to run a software timer at 75hz, which will likely tear the update. - Again, flip 1 syncs to the hardware's vertical blank rate and the timing of the beginning of the refresh, so that when the backbuffer is copied to the display (front buffer) for viewing, the copy process is ahead of the video beam, so that you don't see a portion of the previous frame and next frame with a tear between them. - Flip -1 syncs to a software rate which will depend on whether you specified a hz rate. If you didn't specify one it will use a default rate which is 60hz. So there's really two hz rates to deal with. There's the hz of the actual display hardware - how many times the picture on the screen is pulled from memory and displayed as light on the screen surface. You only have so many hz rates to choose from as defined by your graphics card. The hardware will refresh the display at this hz rate *regardless* of whether you try to flip your screen at the same rate or not. The other hz rate depends on your use of Flip. Flip 1 makes your screen flips match the same rate as the hardware refresh and tries to synchronize it with the vertical blank to avoid tearing. Flip -1 uses a software timer which may or may not match the hardware refresh (and can produce tearing). As a rule I personally use Flip 1 all the time, unless I specifically want to control the flip-rate, in which case I write my own timing code and still use Flip 1 when it's time to flip the frame, to make sure it does not tear. Using Flip -1 produces tearing because it doesn't wait for the vertical blank. |
| ||
| Recap on the "hz" parameter. I never want to try to force a refresh rate on an end user's system. I want my game to adapt to their settings. "The smoothest method is to use a hertz value of -1 (>>>should be default refresh at that screen res<<<) and use a fixed logic loop, as you've been doing, with flip 1." To have the device use the GPU's default refresh rate, should I pass a value of "null", "0" or "-1". |
| ||
| In windowed mode Hertz is only used for the timing of Flip -1, it's not used with Flip 1 or 0 because obviously the desktop Hz is being used. Do you forsee any problems with running at 60Hz in full-screen mode (the default?) Everything supports that. You can obtain the Hz rate of the desktop if you want to use that in full-screen mode (assuming you are using the same resolution I guess that's sensible). My framework has code to get the Desktop Hz in Windows, but not OSX. |
| ||
| When I coded in DX8 everything I researched told me it was a big "no no" to mess with an end user's refresh rate setting and the best thing to do was let the DX8 interface take care of it by passing a value of "0" when you created the device. I did some peeking around at the DX7Max2D source and it appears the hz passed to the graphics command is not being trapped to make sure it's a valid value. The docs state any unsupported value will be converted to a default value. I'm assuming the docs mean the GPU will set the refresh rate to a default value in the event the passed hz is not supported by the hardware. So this means passing -1 will cause the GPU to set a default refresh rate. I've tested this and it appears to be accurate. "Do you forsee any problems with running at 60Hz in full-screen mode (the default?) Everything supports that." hmmm....Yah...you're probably right, and perhaps I should just set it at 60 and forget it. But it goes against everything I learned. :) lol.. |
| ||
| There's two parts to the system, there's the setting up of the display, and then there's the managing of screen flips. The two systems are separate. `Graphics` handles the setting up of the display, and `Flip` handles the double buffering. First of all, let's get the parameters straight. The parameters of the Graphics command are: Graphics Width,Height,Depth,Hertz The third parameter is NOT the hertz rate, it's the number of bits of color depth per pixel. `Graphics 640,480` opens a window on the desktop using the desktop's color depth and records the hertz rate as being the same as whatever the hz rate of the desktop resolution is. If your desktop is 1024x768 at 85Hz then it will record 85 as the hz rate. `Graphics 640,480,0 does exactly the same thing. The 0 just means `use whatever the desktop is using`, which applies to both the color depth and the hz rate. The way Mark coded the difference between opening fullscreen and opening windowed is that if the color depth is 0 it'll be a window and if the color depth is >0 it'll be fullscreen. If you omit the color depth it'll default to 0 which is windowed. Not entirely intuitive - might've been better to have a GraphicsWindowed and GraphicsFullscreen. In order to define a Hz rate on the desktop you have to include 0 as the color depth so that a window will open, ie Graphics 640,480,0,60 will open a window at 640x480 with whatever color depth the desktop has and then regardless of the desktop hz rate will record 60 as the internal hz rate, a software hz rate later used by Flip -1. Note that there is NO way to alter the desktop's actual hardware hz rate, screen resolution or color depth using the Graphics command. The assumption is that since you're asking for a operating-system-friendly cooperative window, you're just going to accept the depth and hz settings that you inherit from the desktop. Now, before we even look at fullscreen modes, we'll look at the Flip command. Whatever value was stored as being the hz rate of the desktop OR the hz rate that you SAID it was to use (as in Graphics 640,480,0,60), is now accessed by the Flip command. If you say Flip -1, the stored value is used to create a software timer that flips the display at that exact hz rate, regardless of whether it happens to match with the desktop's hardware hz rate. If you specified a Hz rate then the software timer will only flip the backbuffer at that rate, even if it doesn't match the hardware refresh rate of the display. If you didn't specify a Hz rate, or it happens to match the display's hz rate, then flips will be synchronized with the desktop display - BUT only in that they flip the same number of times per second, NOT necessarily synchronized to the vertical blank. Flip 0 ignored the Hz rate altogether and flips immediately. Note that if you try to flip 300 times per second and the hardware is only displaying the desktop at 100Hz refresh, then about every 1/3rd of a refresh cycle a whole new frame will have been drawn to the backbuffer and flipped with the visible buffer, so you'll see portions of 3 frames being displayed - an effect we call tearing. Just because you Flip 0 at 300Hz the display still is only showing at 100Hz. Flip 1 takes the *hardware* refresh rate of the display and not only flips at the exact same rate (cpu/gpu permitting) but also waits for the vertical blank period before each flip so that the copy of data from the backbuffer to the frontbuffer is ahead of the video beam - resulting in the beam never overlapping the draw position, completely eliminating tearing. So even if you said Graphics 640,480,0,60 and your desktop is at 85Hz, if you Flip 1 it will flip at 85Hz. However if you Flip -1 with the same settings you'll get a software flip at 60Hz. For fullscreen, when you ask for a display mode you do it by defining a color depth>0. A hz rate is optional. Graphics 640,480,32 or 640,480,16 creates a fullscreen display at that resolution and depth if available. It sort of depends on what resolutions your hardware has available and what happens when you ask for one that does not exist, as to how the app will react to an unusual request. For example if I ask for a 600x200 display at 12-bit color, my hardware cannot do it. But I do still get a fullscreen display. It'll be at the next higher resolution that can encapsulate that - so a 640x480 screen, but it will be as if I defined a viewport 600x200 ancored in the lower left corner of the screen. As to the 12-bit color, it'll probably be promoted to 16-bit. This might not necessarily work the same on other computers, it might fail if you ask for something unavailable. Once you've opened in fullscreen, if you do not define a Hz rate you'll get one provided by the o/s. Usually it'll be whatever is the lowest hz rate, like 60, or whatever the driver defaults to. Then with Flip -1 it'll use that rate, and Flip 1 will also use that rate albeit vblank sync'd. If you provide a Hz rate, however, it will try to find a resolution that supports it. If my hardware can do a 640x480 display at 120Hz refresh and I somehow know this (ie I get all display modes and search through the list), then if I do Graphics 640,480,32,120 I should get a display which refreshes in hardware at 120Hz. If I then do a Flip -1 it'll be at 120Hz software, while Flip 1 will be at 120Hz v-sync'd. However, if such a rate was not available - say I asked for 640x480 at 500Hz refresh, then either the display won't open or it'll adjust to whatever it can achieve, say 85Hz. If I then I do a Flip -1 it's going to use MY hz rate of 500 and try to match it in software, flipping 500 times per second. If I do Flip 1 however it'll go at the screen's rate of 85. If you are worried about changing the user's screen hz rate, as supposedly it sometimes messes up some applications/graphics on Windows, or they just don't like it (too picky!), then find the hz rate of the desktop and ask for a fullscreen mode with that hz rate. That's about all you can do. It's then up to you whether that rate is too fast for your game engine or whether you Flip -1 or 1. Note that ideally you want to Flip 1 where possible because it is the only way to be totally sure (as you can be) that you won't get any tearing in the display. Flip -1 does not prevent tearing. For some reason a lot of Blitz users keep using Flip -1 thinking it't somehow magical and wonderful but every one of those apps produces tearing on my iMac unless I change it to Flip 1. Yes the -1 gives you control over the flip rate of the game, which acts like a fixed-rate logic system where logic is tied to graphics and runs the same rate on all machines if possible, but it doesn't produce smooth flips. In my opinion you want the smoothest graphics display possible, which means your only option is Flip 1. It will sync to the vertical blank (so long as the hardware supports accurate reporting of the vertical blank which some drivers do not - darn it). This also means that now in order to always Flip 1 you'll have to design your engine so that it can adapt to different Hz rates. One user may only have an 85 or 120hz display whereas others may only have 60 or 72hz. That means your graphics engine is going to have to run at the same rate as the display hz. You can decouple your logic and do like fixed-step with tweening or something. You're not going to get smooth graphics without tearing on all systems just by doing a 60hz Flip -1. And since your flip rate depends on the hardware hz rate, you have to design your animation/physics etc to be constant-rate regardless of the graphics update. It also in a way means that you MUST try to get graphics to update at the hardware hz rate, because if it falls below while you're doing Flip 1 you'll drop down to like 30hz. In a way that almost makes constant-rate graphics a higher priority than high constant-rate logic. You could possibly detect how long it has taken to draw the frame and if it is longer than it should've been based on the hardware hz rate, do a Filp 0, otherwise do a flip 1. Some frames will be without tearing, some with, but then it won't drop down from 60 to 30, more like from 60 to 50. Anyway, I hope that helps. |
| ||
| Very detailed post. Anyway, it's the same as my understanding of it all (and I tested it all when I designed my framework). Once you've opened in fullscreen, if you do not define a Hz rate you'll get one provided by the o/s. The default Hz param is 60, so if you don't supply a Hz param in full-screen mode it will be 60Hz. You need to use -1 as MGE has discovered to use one provided by the OS. |
| ||
| Love all the info. Thanks IH and GA! :) |
| ||
| I think what you meant to say was that you need to use -1 to use the hz rate you requested, regardless of what the display is doing. I guess the o/s really doesn't provide a hz rate unless you use Flip 1 to sync with it, or you open on the desktop without specifying one. But like you said maybe it's Blitz that's defaulting it to 60 and not the o/s. I think the best approach is to basically be in control, to know what screen modes are available and to allow only available modes/refresh rates to be used. And the more you can make your engine flexible to adapt the better. |
| ||
| Function Graphics:TGraphics( width,height,depth=0,hertz=60,flags=0 ) As you can see the default is 60, which is probably the most widely supported. I meant if -1 is passed as the Hz (I wasn't talking about Flip, should have made that clear) as MGE said, it will use whatever the OS/Driver provides as default. Note: Some video card drivers do not return a Hz param so you cannot properly search for a chosen mode with a fixed Hz with GraphicsModeExists(). |
| ||
| Oh, so like Graphics 640,480,32,-1 would let the o/s driver choose a hz rate for the display resolution for you? I didn't know it could do that. Also, yeah, pity that some drivers do not report properly the hz rate or the vertical blank event. What can you do. On my iMac widescreen display where you have stretched versions of 4:3 ratio resolutions, in addition to normal 4:3 ratio resolutions, there is no way to distinguish between then in the list of display modes. It would be nice if BRL added ability to read the hz rate into the list. |
| ||
| Just to be clear, if you pass a hz that is not supported by the os the GPU (not Blitzmax setting it) will use a default value. This value could ofcourse be 0, -1, or 10000. But I use -1 because it's more visually obvious. :) |
| ||
| Just to be clear, if you pass a hz that is not supported by the os The operating system doesn't decide what display frequencies are available. It's reported by the drivers. Which leads me very nicely into something I was wondering. What happens if you specify a display frequency which the drivers tell you is available, but the monitor does not actually support. For instance, my old Nvidia drivers used to report that 72hz and 75hz were available on my old 15" lcd monitor, but in truth, it was only capable of 60hz. Setting the wrong frequency on an LCD doesn't do any harm - although it did irritatingly make the screen go blank - but what would happen if the situation were repeated on a CRT? Surely you could end up causing physical damage to the monitor? |
| ||
| "The operating system doesn't decide what display frequencies are available. It's reported by the drivers." Yes, yes..ofcourse. Sorry. Good question and which is the reason I prefer to let the driver set the hz value for me. Years ago I read stories where this could cause physical harm, but I've yet to read anything that proves it. |
| ||
| I would think you would just see a screen with a mishmash of mis-aligned rows of data flicking all over the place like you get when you try to set a res that isn't available on a given monitor. I did this on an old VT220 terminal recently which was couldn't do a 1024x768 mode, so it just displayed scrambled input. I don't think you can force the monitor hardware to try to do something outside of its design as such, but saying that I do recall even in the Amiga days people warning against trying to make your monitor do things it wasn't designed for. Speaking of monitors, though, has anyone with a flatscreen LCD display noticed that it takes several frames for an old frame of graphics to `fade` from the screen, ie some of the color value or brightness is retained in the pixels and so when you have normally smooth moving objects like at 60hz, you get this blurred streaking motion-blur type of effect rather than a really crisp graphic? I find it somewhat annoying. |
| ||
| Yeah I've never seen proof of a CRT blowing up with the wrong HZ. IH: I still have a CRT as I prefer it for action games as I don't like the TFT blur (or interpolation if running the game at a res which is not the standard res of the TFT) |
| ||
| "Speaking of monitors, though, has anyone with a flatscreen LCD display noticed that it takes several frames for an old frame of graphics to `fade` from the screen, ie some of the color value or brightness is retained in the pixels and so when you have normally smooth moving objects like at 60hz, you get this blurred streaking motion-blur type of effect rather than a really crisp graphic? I find it somewhat annoying." Yep. Actually it's kind of cool when you have a ton of space sprites with flames, etc, flying around giving you that extra motion blur. But otherwise, yah..it sucks. |
| ||
| I'm a purist which is which I've clung to my CRT for so many years. But I may convert soon (but perhaps keep the CRT for testing). |
| ||
| ImaginaryHuman: That has a lot to do with the monitor's video response rate. The faster the response time, the less you notice that blurring. It is recommended for game systems to be no more than 8 ms. Mine is at 5ms and I do not notice any blurring. On the other hand, my parent's monitor is something like 20ms and it blurs horribly. |
| ||
| I'm a purist which is which I've clung to my CRT for so many years. But I may convert soon (but perhaps keep the CRT for testing). A halfway decent LCD still beats the snot out of a good CRT -- there is absolutely no way I'll ever switch back to CRT's if I have half a choice. (Just need to make sure that the colors are adjusted properly -- the factory default settings on many LCD's stink. But even at 120Hz refresh rate my CRTs used to give me eyestrain, the LCD's don't do that.) |
| ||
| A halfway decent LCD still beats the snot out of a good CRT In what way? CRT has better contrast ratio, no interpolation when using different resolutions, no blurring on moving graphics. Sounds like you only prefer TFT due to no flicker which can be avoided on CRT with high refresh rates. Oh and of course they take up less space. |
| ||
| I have a 22" CRT as my main monitor that I bought off eBay for £10. CRTs are far better for photo work. And they're a damn sight easier to calibrate. |
   |