Refreshrate observation
BlitzMax Forums/BlitzMax Programming/Refreshrate observation
| ||
| (*edit* - in hindsight, this probably should be in the 'bugs' forum... ) I was playing around with the graphics mode refreshrate parameters so a game I'm working on can work at the same speed regardless of the actual refresh rate, and ran into something odd: From what I understand, when you select a 'non-supported' refresh rate, from BlitzMax is supposed to pick a near match and apply some frame limiting to 'fit' your screen updates in there. (OpenGL bglSetSwapInterval, I presume) Overall this seems to work pretty well, but I did notice a very odd one in there: - If I specify 60Hz, my FPS counter returns 60FPS for me, and the GetGraphics command also returns 60. - If I specify 54Hz, both FPS and GetGraphics counter return 54. - If I specify 56Hz, both FPs and GetGraphics counter return 56. - However, the 55Hz mode behaved quite differently from the others: If I first run at 60Hz, stop the program, change the value over to 55Hz, and run again, things go a bit weird: Now things appear to move around faster than they should. FPS counter shows 60 instead of 55, but the GetGraphics command correctly returns '55'. I'm using the refreshrate as returned by GetGraphics to calculate the speed of some objects, so the fact that they move too fast clearly indicates that the frame limiting isn't happening like it should. Now, even weirder: - If I go first to 60Hz (=correct) and then to 55Hz, the 55Hz mode does not do the proper frame limiting. - If I go first to 60Hz (=correct), then to 54Hz (=correct), and then switch to 55Hz, there is no proper frame limiting. - Howver, If I go first to 60Hz (=correct), then to 56Hz (=correct), and then switch to 55Hz, then it is correctly limiting itself to 55FPS. Very weird -- could this be some openGL context variable not getting reset properly or something? While this example above is obviously not something any real program would do, it does show that there may be circumstances under which the frame limiting isn't working as it should... (Aside from this example changing back and forth between various screenmodes/refreshrates by a game, what would happen if you jump straight into 55Hz mode on a computer that defaults to 60Hz on a certain screenmode? Could this issue also appear then? That could potentially be a bit more of a 'real-world' issue I suppose) (I have a feeling that we'll be seeing frame limiting be used to smooth out gameplay to some extend on slower machines, which aren't always able to render OpenGL fast enough to run smooth without the frame limiting. |
| ||
| I would steer clear of changing the users refresh rate, it can be a minefield of problems and just isn't polite to change it IMO. |
| ||
| @Shambler Hey I just learned that lesson the hard way! I sent a test prog to my pal in TX and the damned thing wouldn't run on his crappy old imac....mainly because I forced the refresh rate to somn specific. I took out that part and voila! It worked! |
| ||
| Hey I just learned that lesson the hard way! I sent a test prog to my pal in TX and the damned thing wouldn't run on his crappy old imac....mainly because I forced the refresh rate to somn specific. I took out that part and voila! It worked! Out of curiosity, did you set it to something high, or low? I'm using an LCD monitor myself, which tend to be a lot more forgiving to 'weird' refreshrates than CRT's are. |
| ||
| I guess that as long as one sticks to the refreshrates returned by the GetGraphicsMode command, there -shouldn't- be any issues? Nice to see though -- BlitzMax lists a bunch of screenmodes that weren't detected by the previous versions, like 512x384 (They worked OK, but weren't part of the list before) |
| ||
| Thankyou !.. at last someone else has experienced it - and I'm not imagining it !!!. I've got a 9800 Rad, first time I run my OpenGL proggie I get twice as many FPS then if I run it a second time. (drop of 3000 to 1600) Seems after the first run, it will always default to the 1600 speed. I had a feeling it was something to do with lost syncing somehow. (and this is running on an LCD with a refresh rate of 85mhz) |
| ||
| @Shambler I did set it to 75hz, my friend was trying to run it on his mom's computer...guessing she had an older one, didnt get the specs. :) @PaulJG Glad you're getting to the bottom of it. Heh, I've noticed old boxes with onboard video cant handle anything above 70ish without balking (i.e. not working!!) |
| ||
| I did set it to 75hz, my friend was trying to run it on his mom's computer...guessing she had an older one, didnt get the specs If it's a Mac, there may be another issue: some of the older ones don't support full-screen OpenGL applications at all, and will only run them in windowed mode. Which does bring up the point: We can programmatically obtain the list of supported resolutions and refreshrates -- but is it possible to find out whether or not a computer supports full screen OpenGL or not? |
| ||
| From what I understand, when you select a 'non-supported' refresh rate, from BlitzMax is supposed to pick a near match and apply some frame limiting to 'fit' your screen updates in there. (OpenGL bglSetSwapInterval, I presume) The timing code is set up by Graphics and executed in Flip. bglSetSwapInterval does something different ( http://blitzwiki.org/index.php/BglSetSwapInterval ) Graphics will try and set the screen refresh to the desired rate. It will then perform a timing test to see if the refresh rate is OK. If it fails it just uses the default refresh rate and switches off vsync. In that case Flip will wait the required length of time before calling bglSwapBuffers. It sounds like this is an issue in the timing test in Graphics. |
   |