Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / Screen resolution/refresh rate problem for my game,...help??

Author
Message
The Slayer
Forum Vice President
16
Years of Service
User Offline
Joined: 9th Nov 2009
Playing: (Hide and) Seek and Destroy on my guitar!
Posted: 11th Jul 2010 12:21 Edited at: 11th Jul 2010 12:22
So, I'm eager to get my game BRIXOID ready to post, but I have a problem with the resolution settings and the refresh rate. It seems that there are only three or four resolution settings where the game runs smooth without hickups. They are:



I programmed my game in windowed mode and then maximized the window.

When I try another resolution, the movement of my objects does have some slight hickups. I tried to code with or without TBM, but that didn't solve anything.
After some testing and checking, it appears that my game only runs well when the screen resotution has a refresh rate of 85. Everything below doesn't work (well, it runs but with those hickups).
So, I was wondering, how could I solve this problem? Could the problem be that my monitor or graphics card is playing tricks on me? My monitor is an older model (Compaq V75) and my graphics card is an ATI RADEON HD 3870.
I'm thinking of just putting the resolutions in my game that run well, but a lot of you guyz and girls have higher resolutions than that, right? So, what should I do?
Any advice or help would be appreciated.

Thanx in advance.

Cheers

Slayer rules!!! Yeaaah, man!
Indicium
18
Years of Service
User Offline
Joined: 26th May 2008
Location:
Posted: 11th Jul 2010 13:21
Just a thought, you could check the settings of your graphics card, there might be something in there set to 85hz, or you could try updating your drivers?

Also, why don't you just use:



Or is there a specific reason why noone ever uses this...

Rawwrr. Sig Fail.
Newcastle is awesome
The Slayer
Forum Vice President
16
Years of Service
User Offline
Joined: 9th Nov 2009
Playing: (Hide and) Seek and Destroy on my guitar!
Posted: 11th Jul 2010 20:32
Thanks for answering, Mad Nightmare.

Well, I just found out why I got those hickups when running some resolutions. In the properties window of my graphics card, I unchecked the option to ONLY show the resolutions that my monitor CAN handle.
So, I only have 4 resolution settings that my monitor supports.
I'm happy that I finally sorted this out, though.

But, now for the bigger problem:

Even though I used TBM, the speed of the game decreases on higher resolution settings. The code I used for the TBM is this (before the SYNC ON command):



and, to move objects, I use:



I also checked which value I get (elapsed#) at the different screen resolutions, and they where:



So, my question is, how comes that the game runs faster at the lowest resolution (1024, 768, 32), while the elapsed# value is less than the higher screen settings?
I mean, is it not the elapsed# value (from the timer() ) that handles the movement speed? I thought that Timer Based Movement is used to keep the framerate even on different refresh rates or screen resolutions?

I also noticed that the elapsed# gets higher depending on the time that has passed. So, how do I keep it the same all the time? Should I put the code BEFORE or AFTER the sync on command?

Can anyone explain or help?

Thanx

Slayer rules!!! Yeaaah, man!
KISTech
18
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 11th Jul 2010 20:52
Correct me if I'm wrong, but..

elapsed#=tim-lasttim/10.0

would divide lasttim by 10, and THEN subtract it from tim.

You want,

elapsed# = (tim - lasttim) / 10.0

That might help with the issue you are having.

The Slayer
Forum Vice President
16
Years of Service
User Offline
Joined: 9th Nov 2009
Playing: (Hide and) Seek and Destroy on my guitar!
Posted: 11th Jul 2010 22:49
Thanx, KISTech for your help. Although I didn't try out your method, I managed to get this framerate problem working with this function. It's a code snippet I found in the code snippets section (I think) just before you answered, and now it runs smooth as silk. I'm so very happy! Yaaaaay!



Cheers

Slayer rules!!! Yeaaah, man!
KISTech
18
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 11th Jul 2010 23:56
LOL.. I was going to suggest something like that, but I didn't want to start another LONG thread about TBM.

Here is a better solution that I've refined since finding the code snippet you show above.



The Diff# and Ideal# variables aren't needed, and dividing by 60 is also unnecessary.

Averaging the last 30 results gives nice silky smooth movement, with little to no jerky movements if your FPS should dip temporarily.

DVader
22
Years of Service
User Offline
Joined: 28th Jan 2004
Location:
Posted: 15th Jul 2010 17:32
Hmm, never had much look with timer based stuff, I always simply use

This sets the frame rate to your monitors sync rate.

http://s6.bitefight.org/c.php?uid=103081
Hawkblood
16
Years of Service
User Offline
Joined: 5th Dec 2009
Location:
Posted: 15th Jul 2010 17:34
Quote: "This sets the frame rate to your monitors sync rate."

Unless your game causes frame rate to drop below.

The fastest code is the code never written.
DVader
22
Years of Service
User Offline
Joined: 28th Jan 2004
Location:
Posted: 19th Jul 2010 17:06
That's what minimum specs are for lol :p

http://s6.bitefight.org/c.php?uid=103081
Randomness 128
19
Years of Service
User Offline
Joined: 13th Feb 2007
Location:
Posted: 20th Jul 2010 20:18
Quote: "This sets the frame rate to your monitors sync rate."

So if someone's monitor has a higher refresh rate, everything in the game will move faster? Doesn't seem like a great solution.

Windows 7 x64, Core i7 860, 8 GB DDR3 1333 RAM, Radeon HD 5850, 1.25 TB HDD capacity
Hawkblood
16
Years of Service
User Offline
Joined: 5th Dec 2009
Location:
Posted: 20th Jul 2010 20:36
Most games should be made with time-based movement.

The fastest code is the code never written.
RedFlames
18
Years of Service
User Offline
Joined: 25th Aug 2007
Location: Germania
Posted: 20th Jul 2010 21:35
Quote: "Here is a better solution that I've refined since finding the code snippet you show above."

That looks like some really useful code you have there, thanks for sharing it

Maybe someone could post some kind of example code for that in the Snippets section, as I think this will be really useful for more than just one or two people (including me)

[Just incase it hasn't already been posted somewhere else, that is]

Login to post a reply

Server time is: 2026-07-25 04:54:52
Your offset time is: 2026-07-25 04:54:52