Force refresh rate
BlitzPlus Forums/BlitzPlus Programming/Force refresh rate
| ||
| Hello, I remember asking this last year, but there was no solution apart from work-arounds back then so I thought I'd ask again. In 2D, I would like to force a refresh rate of 60Hz for example. I am currently working with all sorts of refreshrates and checking the delta time to calculate a multiplier that I scale everything to run at a similar speed. I would however really like to force a refresh rate instead, maybe using a nifty trick in blitz or possibly using a DLL? Any suggestions? |
| ||
| Yo dude! Heres how I force a refresh rate! ;------------------------------------------------------------- ; program loop starts here! repeat tim = createtimer(60) ; ; dump yer code here ; waittimer(tim) freetimer tim) forever ; end of example code ; ---------------------------------------------------------- This should keep youre game running at a smooth 60fps unless youre code exceeds the amount of processing time available then the FPS value will get lower (slowdown), no dll's are req! Hope this helps you out Mr Brine |
| ||
| This should keep youre game running at a smooth 60fps There's just one thing I would dispute about that and that is the word, "smooth" |
| ||
| Hi Mr Brine, the waittimer works strange with monitors refresh rate higher than 60 Hz. Actually, the only methode to run a game perfectly with the monitor is to set DirectX to 60Hz. |
| ||
| Or set your game timer to run at the current refresh rate. |
| ||
I just go like this:timeseq=1000/60 ; 60 hz repeat time=millisecs() ; code here While (not keydown(1)) and (millisecs()-timer<timeseq) wend forever |
| ||
| I use a multiplier at the moment to compensate for refreshrates, i.e. a multiplier of 0.5 if someone runs the game at 120Hz instead of 60Hz, all calculations of variables will then be multiplied for the compensation. The reason why I prefer not to use waittimer is because I am after 100% smoothness in the 2D game, nothing will do it as good as making sure everything runs at a steady phase in according to the refresh rate. The only solution I am after apart from the one I am currently using is to definitely tell windows / the graphics card and monitor that "RUN AT 60HZ!" =) I don't think Blitz supports this, but there are utilities out there to set refreshrates for DX, so maybe it is possible to integrate it into Blitz with some sort of a DLL or something? Thanks for the replies so far. |
| ||
| If you choose a refresh rate that someones monitor doesn't support, then you could physically damage their monitor. 60 Hz is probably OK, but people set their refresh rates higher for a reason, usually to reduce flicker. If you set it lower, they might not be happy with you. |
| ||
| WolRon, I do agree with you to an extent. I don't like 60hz in windows for example, I always use 100+ if possible. I think in the 2D game 60hz should be fine as the benefit is that the game will be guaranteed to run at that refreshrate on all monitors, and the timing and smoothness will be perfect, especially when playing over the LAN so that people won't benefit or lose out because the game behaves slightly different using different refreshrates. Currently the game runs fine anywhere between 60hz and 120hz, really smooth, and the speed of the cars are nearly identical (too close to measure any difference), but the handling of the skids and stuff may be slightly different. |
| ||
| Thats a HUGE NONO! Never change someones OS refresh rate!!! for the reasons WolRon mentioned plus its really annoying when your monitor goes to crap when you start an application that uses a refresh not supported. And.. in North America 60hz hurts... our power is 60hz and you get flicker... in Europe where the power is 50hz you dont get this problem with 60hz as much... I think most people that know about it and know how to change it run at 75 or 85hz now too. Skully |
| ||
| =)I didn't know the problem was magnified for American users, but I know there is a slight flicker, mainly in windows environments rather than games. The game only runs in 640x480, 800x600, 1024x768 so I should be alright at locking it at 75hz too. It's graphically demanding (and eats quite a bit of video memory due to the size of circuits etc), so I suppose people that can't cope with 75hz won't be able to play the game anyway =) Thanks. |
| ||
| Imphenzia, check to dxdiag.exe on your hard-drive : it runs the DirectX dialog box, and you can set the monitor refresh ONLY for DirectX applications. |
| ||
| This is a pathectic weakness of the Windows system. A lot of drivers have no idea what refresh rate your monitor is capable of. However I doubt you could damage any modern monitor by forcing the refresh rate, though old (pre 95) monitor's are quite dodgy. I'm afraid you'll have to live with one of the alternatives such as delta time or tweening, though they are pretty crap for 2D. Certainly a lot better than waittimer, but never as good at a steady refresh rate. |
| ||
| I'd like to say that there's a large misconception about hz. With consoles and older home computers like the amiga, you won't really get any flicker at 50 or 60, however with pcs you really need to avoid setting the hz like the plague. You can obtain perfectly smooth 2D timing code regardless of hz. Another thing: a lot of new pcs ship with tft flat panel displays (as well as laptops) and forcing 60hz will also have zero effect. Or ruin the entire look. So you really *have no choice* but to use clever timing code. Look in code archives for alternatives. |
| ||
| I agree you have to use timing code, but I don't agree that you can get perfectly smooth 2D using it. You can get reasonably smooth 2D but you will see minor glitches enough to spoil that arcade smoothness. Timing code works perfectly for 3D as everything works with floating points and never really moves a whole number of pixels. 2D does though, so anything moving whole numbers (say the screen scrolling a 2 pixels a frame) will glitch in tweening. Barely noticable, but once you are used to true smoothness you will notice it. This must be because the game logic has to be ready at the exact moment the monitor draws. Normally vwait pauses everything till it's ready so it will always draw at exactly the right moment. In timing code the game logic is seperate from the drawing (though this is good practice, I agree). Chances are the logic fps is not going to divide perfectly into the number of display frames available, and about 1% of your frames will be slightly off. Swedernik's code is about the best I've seen for 2D tweening. The game logic runs at 250fps so it's almost always ready when the frame refresh comes up. If you run it on a 120hz display it's pretty much perfect, but of course this has the drawback of causing the GFX card twice as much work, not much use for a graphics intensive game. I understand there's nothing can be done about it until drivers improve but I was in the mood for a rant. |
| ||
| I move everything relative to elapsed time (game ticks) in my development... This avoids the whole issue of movement irregularities due to monitor refresh. The only down side is that you have to use float values in order to maintain smoothness even though the drawing of the images is done with integers. This makes it slightly slower depending on how much you are doing; however, I usually leave Particle effects out of this restriction unless they can effect actual game objects. Skully |
| ||
| I had a quick gander at my code and realised a missed out a couple of things that might help smooth things out at little, (on my system everything runs a steady fps no matter what the refresh rate 50, 75, 60, My windows refresh rate is 75mhz): ;------------------------------------------------------------- ; program loop starts here! vwait ; before you enter the loop repeat tim = createtimer(60) ; ; dump yer code here ; ; excluding vwait ; flip false waittimer(tim) freetimer tim) forever ; end of example code ; ---------------------------------------------------------- Its also been my experince (which aint a great deal) that putting functions relating to drawing on the backbuffer() at the top of the loop and functions the process the data at the bottom of the loop helps to increase performance a little. But its like say I dont have great deal of experince so I might be talking crap here :-) also note the LACK of vwait, this I would say is important, but see the last line. Hope this helps resolve yer probs Mr Brine |
| ||
| I use floating points for all my location variables too, and with a multiplier calculated based on the refresh rate I would say that it runs smooth enough. You get the occasional glitch, maybe 1% as Simon said, but I can live with it in the type of a game I am making (CTCC). I just don't want someone to be able to patch the game and have control of that multiplier as it would enable cheats in multiplayer mode, but I guess I'll have to spend more time writing cheat-prevention code than locking refresh rates =) My next game will be 3D I think, pixel perfect smooth on such a huge range of PC components is too much hassle =) Mr Brine - I just tried the code above, and it doesn't achieve the smoothness I'm after, but it does however run at a steady phase =) Thanks for discussing this. |
| ||
| Imphenzia, Ive been upstairs playing with refresh rates: I did come up with one more idea, which is changing the the createtimer(60) to createtimer(75), this'll force the update rate to 75fps and gives me really quite smooth animations, but the amount of processing time available in one frame drops, quite a bit, also everything speeds up. I dont if this of help or not. One thing I did notice is that for the first 10-20 seconds it can be a bit jittery, but this seems to smoothen out, with time, also whats a CTCC?? Mr Brine |
| ||
| Thanks for the idea. I haven't tried it yet, but I can check just in case but I fear it still may not produce the same smoothness as sticking to the refreshrate that the monitor is set to. CTCC is a 2D racing game, you can see more info and screenshots etc. here: http://www.imphenzia.com/games/ctcc/ Stefan |
| ||
| Sorry Mr Brine, the code you've made is essentially as effective as waittimer. The likely reason it looks better at 75 is that your monitor displays at 75hz. Oh and apologies, there was a bit of nonsense in my explanation above. The glitch is not due to the game logic being unable to draw at the right time, it's how much an object moves in a refresh frame. Say in a second an object moves 120 pixels. Now at 60 this would move smoothly as it computes as exactly 2 pixels pre refresh (120 pixels/60 frames)=2 pixels a frame. But in 85, this doesn't quite work. (120 pixels/85 frames)=1.4117647058823529411764705882353 And there's not enough precision in a floating point number for that. So it ends up unevenly divided amoungst the frames, in at least one frame, the object will move too far or too little. A dreaded remainder. To be honest most gamers would not care about this, I guess I've been spoiled by too many SNES and Arcade games. |
   |