How to find the hertz rate?
BlitzMax Forums/BlitzMax Programming/How to find the hertz rate?
| ||
| I don't quite understand the whole Hertz business when setting up graphics displays/windows or flipping the display at the right time. 1. Apparently if you don't specify a hertz rate and you set the color depth to 0, when calling Graphics(), you get a 60Hz default refresh rate. This isn't necessarily the hertz rate of the display. Presumably, though, this is quite a popular hertz rate so it might be synchronized to the display quite often. This seems to apply to windowed mode and fullscreen mode. But doesn't this mean that Graphics() really doesn't know what the display's hertz rate is? If I open a 75Hz fullscreen display, by passing 0 as the hertz rate, will it actually be 75Hz refresh or 60? 2. I can see how this `unknowingness` of the hertz rate can be avoided in full-screen displays, by selecting an actual `known` mode from the list of modes you get back from GetGraphicsMode() or GraphicsModes(). If the data includes the actual hertz rate of the display, you can then know how often to ideally flip the display. However, on some systems the Hertz rate in the mode info is passed back as 0, maybe particularly applicable to LCD screens. With hertz of 0, the mode opens correctly at whatever hertz rate it is, but you don't know what that hertz rate is. Is the only option to then guess a 60Hz software rate, or how can we find the actual rate of the display (requires waiting for the VBlank reliably) ?? 3. If I want to use GLGraphics() or CreateGraphics() for full-screen modes, I have to know the hertz rate I want to give the object before I open the display. Presumably that has to be the rate found in the list of graphics modes otherwise the display will not open (or 0 is default). So then the graphics object might be 0 or a hertz rate, if you're lucky, but it's 0 you're out of luck. It also appears that Flip 1 or Flip -1 do not wait before flipping, at all, unless the display was created with Graphics(). All flips act like Flip 0. To update at a given rate I have to use CreateTimer() at a given hertz rate. What hertz rate? 4. What we basically need, I think, are two things. Open the display, whatever method, then a) A way of reliably waiting for the vertical blank on all systems (OpenGL only please), and then b) do a timed test to see how long it takes to do x number of flips from which we could find something `near to` the hertz rate of the actual display, which we could round up or down to the nearest 5 Hz perhaps since the timer is inaccurate. OR ... if BRL could provide the ACTUAL hertz rate of the display even when it's listed as 0, that would work too. Summary: Full-screen modes, find the actual mode and open it. If you know the hertz, use that, if not, use 60. Windowed mode, try and match the desktop mode to one from the list if possible and get the hertz from it to use, or if 0 then just go with 60Hz? Do we have no choice but to use 60Hz when we don't know the hertz rate? Any ideas/comments/suggestions appreciated. |
| ||
| Oh man, your just kidding at me, aren't you ? That's exactly the point I've decided to code that module for... I can't understand why you don't use it instead of asking one resolution-question after another... :D I've added the Linux part yesterday and will upload it tomorrow if you are interested in this. |
| ||
| AngelDaniel: In DirectX, all flips act like Flip 0 in Windowed mode too. That's why there is vertical tearing in windowed mode. This happens when using Graphics(). That's why I tweaked the BRL modules to make Flip -1 and 1 do a VSync. |
| ||
| d:bug Actually I tried to go back and find the module you posted but I couldn't find it. I'll be happy test out the one supporting all three platforms. Thanks. |
| ||
| ok, I will upload it tomorrow. Click here until I've done this. :D This is the old version without the Linux-Part... |
| ||
| Cool thanks. |
| ||
| Hey d:bug ... I tried your module on my Mac here, it works fine :-) Thanks for the effort you've put into it. It'll be interesting to see it supporting Linux as well. I did recently buy MaxGUI which has GadgetWidth(Desktop()) and GadgetHeight(Desktop()) that returns the desktop dimensions, so I'll probably use those, but I am finding that I will still need to use your module to find out for sure what the bit depth of the desktop is, and the hertz rate. So that's all cool. I really think MaxGUI should have the desktop depth and actual hertz rate as well as the dimensions. Maybe they can put that info into some kind of `extra` field of the gadget. Who knows. I am finding that, and something to bare in mind, is that some computers return 0 as the hertz rate. Your modules also return zero on those computers for the hertz rate. I think what we're facing here is that maybe the o/s itself doesn't even know what the hertz rate of the display is and just refers to it as 0, maybe using its own timing system for updating stuff. Although it's hard to think the o/s wouldn't know the display's refresh rates. Fact is though that trying to find it out with your module or any other method seems to return 0 on those systems and there doesn't seem to be any way to truly find out what the rate is. I think what it'll come down to is using your module to find out the hertz and bit depth, if the hertz is 0 then we'll basically have to guess at a decent hertz rate, like how BlitzMax defaults to 60. That's probably all we can hope for. It's a pity that not all hardware behaves the same. If we were dealing with one graphics card and one main computer card like the ole Amiga it would be much simpler :-D |
| ||
| Glad to see that you have found your freedom... ;) Yesterday i've uploaded the new version, but the board was down. You can find the new, optimized version with Linux support here. I've only testet it on my computers and they all returned an accurate refresh rate of 60Hz. No wonder, since LCD screens can't get faster. I've also talked to hamZta and it seemed to work on his Mac too. |
| ||
| Ok cool. Then it's down to whether the o/s gets given the rates properly or whether the driver just returns 0 on some systems. Will have to make do in that case, but try to avoid that case as much as possible. Cool about the linix support. Has anyone tested the linux version? Thanks again. You should post your module in the module tweaks forum? |
| ||
| Hey d:bug ... in this new version, you've referred to GetBPP for the macos code, in two places within desktopext.bmx, but in the macscreen.c you refer to it as GetBits. I changed the two instances in the bmx file to GetBits and rebuilt the module, now it works fine. Before it was saying unable to link because GetBPP wasn't found. |
| ||
| Yeah, i've tested the Linux-support by my own. Had to install Ubuntu and BMax to do that. That was the main reason that it took so long since skidracer told me about the GetGraphicsMode trick. I'm not shure about the module tweaks forum. Isn't that a place to post 'tweaked' BRL modules? I've thought about the refresh rate 0 problem. Did you checked grapiccard drivers on this machines. Some cards provide an application based frame rate. I remember i had to uncheck it for B3D to get an accurate speed without vsync. Before I've done this my apps allways runned at 60 FPS, Flip(0) or not! Waarg... It's hard for me to explain something in english! :( cheers |
| ||
| You're english sounds fine, I didn't realize it's not your native tongue till looking at your website ;-) Incidentally, DesktopDepth() returns 8 for a 256-color screen, which is cool. Can you confirm that it returns 8 on Linux and Windows, if you have a 256-desktop mode? Cool thing also is it returns 16 for a 16-bit display, even though OpenGL says the mode is really 5:5:5 not 5:6:5. :-) |
| ||
| I've didn't test 8bit graphics mode so far, but I will do it this evening. Will tell you the result tomorrow. I don't think that this is any problem, if all other resolutions are confirmed. :D |
| ||
| Ok. I'll test it on my other mac also as it has a different display arrangement. |
| ||
| Tried to test ist but failed. My Notebook doesn't provide 8bit... Could somebody please test this for me ? |
| ||
| You're english sounds fine, Oh the irony. :o>Anyway, does anyone have a BINARY I can test? |
| ||
| Hey, thats hurting me ;) O.K.here is the link again. cheers |
| ||
| lol. Just download the module and install it, build modules, exit the IDE and then make a program, like: Import dbug.desktopext Print DesktopWidth() Print DesktopHeight() Print DesktopBits() Print DesktopDepth() I tested on my other computer, an ibook .. it reports 8-bit for the 256-color desktop. It was interesting to realize that the o/s is reporting that the desktop on my ibook is 32-bit while on my ibook OpenGL says there is no alpha buffer and it's 24-bit. This means that on some systems you automatically get given an alpha, on others you don't. So you should ask for exactly what you want, and be careful of getting extra. |
| ||
erm, the function DesktopBits() doesn't exist anymore :DImport dbug.desktopext Print DesktopWidth() 'Get the width of the current desktop Print DesktopHeight() 'Get the height of the current desktop Print DesktopDepth() 'Get the depth of the current desktop (...not DesktopBits() ;)) Print DesktopHertz() 'Get frame rate of the current desktop thats the right syntax |
| ||
| Oh ok. |
| ||
| I've placed the folder dbug.mod in the pub.mod folder, rebuilt all modules, then restarted the IDE. I get the error: "Compile Error. Can't find interface for module 'dbug.desktopext'". Could someone be so kind to point out my mistake? :) Thanks! |
| ||
| Dont put it in the pub folder? In my setup I created a DBug folder in the mod folder, which contains the desktopext.bmx etc files. |
   |