the hertz parameter of the graphics command
Archives Forums/BlitzMax Bug Reports/the hertz parameter of the graphics command
| ||
| I don't know if it is considered a bug but on full screen mode this parameter has no influence about the fps (it is locked to 60). on windword mode it works fine. my os is windows 8.1. I wonder if other users of blitz max has the same problem ? |
| ||
| hertz is just a 'hint' - it used to be more useful back in the CRT days, but these days with LCDs pretty much everything is 60hz. |
| ||
| thank you for replying. it is true that a good game should set it's objects speed logically with code so on faster machines the graphic objects will make more movements steps but every step will be shorter distance on every second while on slower machines the graphic objects will make less movements steps but every step will be longer distance on every second. it is true that on this pro approach the hertz parameter has no important since we design the game for every possible hertz machine and not just for ours machine hertz. still this hertz feature can be useful when it works fine on two cases: 1. testing. after you finish game you want to check it on faster machines and on slower machines to see how it works and this can be achieved with no need to leave your computer by changing the hertz parameter. 2. sometimes on simple games it is better approach to limit the hertz so faster machines will not run the game too fast. |
| ||
| Hertz parameter is the monitor refresh rate. It is nothing to do with code execution speed and is no use whatsoever in either of the situations you're suggesting it's used for. |
| ||
| I thought like you until I ran the 'Refreshrate and Delta Time' example from the 'Beginners guide to BlitzMax' by wave and also made some tests based on this example. sorry but I think you wrong here. it is true that the hertz parameter has the limitation of the native monitor refresh rate from above and it is true that the native monitor refresh rate is usually 60 on lcd and laptops screens but it is not true that the hertz parameter is the monitor refresh rate. the hertz parameter when it works (for me it works only on windowed mode) sets the amount of steps the computer run every second on graphics mode or at simplify words it is the execution speed at graphics mode. it is true that this parameter is only a hint because if yours hardware is too week it may run on lower fps on average (the fps is not always constant from many reasons) but from above perspective this parameter when it works limit the maximum fps so a more powerful machine wont be able to run the game at fps that is higher then the parameter even it has the ability to do so. |
| ||
| the hertz parameter when it works (for me it works only on windowed mode) sets the amount of steps the computer run every second on graphics mode or at simplify words it is the execution speed at graphics mode. Gfk is right: in full screen, it sets the monitor refresh rate, which is what that flag is supposed to do. In windowed mode the overall screen refreshrate is controlled by the windows desktop and not your application, which is why it behaves differently there. |
| ||
| sorry but I think you wrong here. maybe if you play a little with the 'Refreshrate and Delta Time' example from the 'Beginners guide to BlitzMax' by wave as I did you understand what I am talking about. this example demonstrates very well how to save the logical speed of a game when the hertz(fps) is change because we change it manually through the graphics command hertz parameter or because the machine running the game is weaker then the developer machine and therefore perform on lower hertz(fps) but the reason is not really important here. the only problem I faced with this example is that on my computer the actual fps displayed on screen is not moving from 60fps even if I change the hertz parameter. the issue is solved when I move to windowed state. |
| ||
| Think yossi refers to this: mod/brl.mod/graphics/graphics.bmx Rem bbdoc: Flip current graphics object about: #Flip swap the front and back buffers of the current graphics objects. 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, unless the graphics object was created with a refresh rate of 0 in which case flip occurs immediately. 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. End Rem Function Graphics:TGraphics( width,height,depth=0,hertz=60,flags=0 ) ... See that it just depends on how you create your "local g:TGraphics". I also remember to have seen this getting used in a sample somewhere (different TGraphics-Creation). And I also interpret this similar to yossi. flip -1 -> could be vsynced - or synced to a manual given refreshrate - which would limit the framerate too with the benefit of using less ressources. bye Ron |
| ||
| thank you Ron but it is not what I meant. anyway I find a solution: before the game start i calculate the actual fps of the computer that run the game (i count the steps on graphics mode in one second). if the actual fps is bigger then the normal (60) i use delay to slow the game to get normal feeling of 60. if the actual fps is lower then the normal(60) i use a delta time technic to make the graphic objects to move larger distance every step and by that i save on constant game speed (the game will run less smooth and with some leg feeling but still can be playable because the speed of the game is logically preserved). |
| ||
| On my PC when full-screen resolution is set to 1366x768, the refresh is always about 75 fps -- not 60 fps as with all other resolutions. |
| ||
| hello John G when I talk about actual fps I talk about the general capability of a computer (the operational speed on graphic mode) and that is the only parameter I check to decide if I should delay the game or advance the moving distance of the objects on each step. for that specific purpose I don't really care about the resolution. on a case like you when the actual fps is 75 I will create delay on code since I develop on 60 and for me it is the base mode (I want to prevent a situation when my game is running too fast on your computer). it is important to preserve the same speed of the game on all computers that might run the game. |
| ||
| I've never gotten all these fps constraints/options figured out. If the hardware vertical sync is 75 and you delay to 60, won't the screen jitter? Thanks. |
| ||
| no jitter. on 60 you get a speed of 1/60 steps per second. on 75 you get a speed of 1/75 steps per second. so we get delay(1/60-1/75) after every step. this is the performance distance for one step between 75 and 60. if you put this delay after flip you get on 75 the same performance as 60. |
| ||
| I made a mistake on previous post. the speed is on terms of time per step and not steps per second and by time I mean milliseconds so it should be delay(1/60*1000-1/75*1000). |
   |