Sorry your browser is not supported!

Hello everyone, this is my first ever board post on TGC forums. Let me give you guys a little of my background before I get into the meat of my problem. First of all, I first started working with DBPro about 8 to 9 years ago. I was a teenager then, and I quickly lost interest after a few months of studying out of the "DarkBasic Pro Game Programming 2nd Ed." book. I had dabbled in it since, and never really got into it again, until about 10 months ago. Since then, I've almost gotten through part 2 in the book, with just the 3D portion in part 3 left to read.

And so that brings me to where I am now. For almost an entire year, I've been working on my game, Marooned. For those of you who know what Terraria and StarBound are, it's pretty much that kind of game; A 2D sort of Minecraft type of game. The character explores a 2D world of blocks, breaking them, placing them, digging tunnels, finding treasure, building structures of out blocks, etc.

The problem I am having is a classic one, something that many of you have seen all over the forums: SYNC RATE IS INCONSISTENT AND UNRELIABLE. Let me elaborate a bit. My game runs in a screen that is a resolution of 640 x 480. It used to be 1280 x 720, but I realized that DBPro was just handling too many sprites concurrently. I tried incorporate an efficient masking system, separating untouched groups of blocks into chunks, mathematically calculating which blocks are in which chunks, playing with the sync rate, and adding a timer feature to the main game loop and setting the sync rate super high (say 200 FPS) in effort to coax at least 60 FPS out of my game.

Here's the thing. I have an Intel Core 2 Quad machine, with 4 GB of RAM. I've noticed that DBPro does not support thread management, i.e. you can't specify which parts of your program you want to split up on different cores of your CPU to make your program more efficient. So it basically pegs one core of my CPU to the floor (supposedly) for as long as my game is running. HOWEVER, if my game is running by itself, it will seem to struggle. I can be running it in 30 FPS, 60 FPS, or even more, and it will somewhat achieve it, although teetering between 29 and 30 fps or 59 and 60 fps. Then when I open another program along side it, sometimes performance improves, sometimes it gets worse. Sometimes I boost the frame rate up to 70 FPS and it stays at 60, and once I get into the 80's then it starts to move up a little bit. But once I hit a sync rate of 90, then BOOM, all of a sudden the game reports it's running at 90 FPS. You see my struggle now hopefully.

As far as efficiency in my game goes, I have it running as efficiently as possible. I've been tinkering with it for months. It draws only the blocks in the world that are currently being displayed on-screen, and nothing else unless the character moves and the screen is shifted. More specifically, I do this by splitting up a 3000 x 3000 px world into a grid of (potentially) 200 x 200 blocks at 15 x 15 px each. These blocks are separated into 64 chunks of 25 x 25 blocks each. Each time through the loop, the game determines which chunks are within the screen boundaries and need to be displayed. Then after the chunks are passed a 1 or 0, the next part of the program checks which blocks need to be drawn within those chunks by checking if they are within screen boundaries. Bear with me guys, this is the very dumbed-down version of it, but this is essentially how the game works.

Now, I have seen people suggesting to install the hitimer() plug-in for a more accurate timer, to use timer-based movement, tinker with v-sync all of that. I've even seen someone separate the game into two parts, the game loop and the display loop, and then running each loop one after the other inside the main loop, only updating the screen via the display loop when it's possible/feasible by the computer (which I have not been able to get working at all).

I am here today to ask if there is a better way. Am I doing this right??? I hit this brick wall about 3 months ago in my game, and have struggled to overcome it since. I've studied this forum religiously for months and still haven't found a reliable/plain-english answer. I KNOW that DBPro can DO what I want it to do! Can't I just somehow tell the CPU to run at max power while my game is running, allowing me to determine what sync rate I want the game to run at and just leave it at that? Whatever sync rate I put the game at, it can achieve it, but with varying results in varying situations. Sometimes it does it with flying Colors! And other times... not so much. Sometimes nothing will be running on my computer at all, and the game will do poorly, and other times it will run great!

My fellow programmers, I am desperate. Like I said, this is my very first post on here, and I am at my wits end with this problem. I am searching for answers and have been unable to find any. If any of you know some magic fix to this problem, I am all ears. Also, the reason this is my first post on here ever is because I don't want to feed the trolls. I've seen a lot of scenarios on other forums where people belittle each other for the sake of flexing their muscles. I have worked professionally in I.T. for 5 years now, and while I may not know as much about programming as the next guy, I am a confident technician and consider myself fairly knowledgable. But this is beyond my grasp. All I'm asking for is help with a problem I don't understand; So please don't yell at me, saying I should know better. Let's all be friends! And thank you for your time spent reading all of this!

So, what exactly is the core of your problem? I understand you're running your game with vsync disabled (i.e. maximum possible refresh rate) and you're using timer() to calculate a delta factor for timer based movement.

Sounds fine to me, where's the issue?

This thread has been a major help for me:
http://forum.thegamecreators.com/?m=forum_view&t=175312&b=1

The sync rate is basically just a crude means to making the program wait on each call to sync. I believe it is doing a busy wait so it should be about as accurate as possible (and definately more accurate than you will ever NEED for a game). The displayed FPS may waver between 59 and 60 simply because it is truncated and may sometimes be timed as 59.99998 and sometimes 60.00004 (as an example). This doesn't mean it is actually differing by a full frame from second to second.

Secondly, you should just opt to make your game completely timer-based instead; this makes it so that it will perform at the same rate regardless of the current refresh rate. Since the refresh rate can indeed vary depending on various circumstances (another program starting out, some scheduled service kicking in and so forth) this will reduce any apparent lagging when such happens (unless it slows your program down greatly but that us quite unlikely).
In this case you simply set the sync rate to 0, meaning to not have the DBPro engine enforce any waiting but rather rendering as fast as possible. You will see the frame rate may jump around quite a bit, but with a timer-based game this is of no effect. It may cause visible screen tearing however, which happens when your monitor refreshes in the middle of drawing, which is where V-sync comes into the picture.

Bottom line, don't pay too much attention to FPS values sampled at any particular time but rather see to it that your program will run smoothly

Not sure I\'ve understood The target/current FPS method..
But I aggree to say this aspect of programming can be tricky. I struggled Myself with this in the past
(My program had different behavior on different PCs..)

So your thread title say it all: Don\'t rely on Sync Rate !!!
The help files state the forced sync rate is only approxmative..
The only Rate we need is Sync Rate 0, That will runs the main loop at max speed..
Except if v-sync is enabled, in this case the loop will run at monitor refresh rate: That is the best mode that gives smooth animation and prevent screen tearing! The difference:
If v-sync in on and the loop is executing Sync command. The program will be halted until The vertical sync (VBL), and then perform rendering.
If v-sync in off and the loop is executing Sync command. The program will check if the vertical sync is reached.if yes
the rendering is performed, if no the programm continue with out rendering but this \"frame\" is still taken in account for the current FPS statistic.
Keep in mind that the high FPS values superior than monitor refresh rate are here to measure the performance,
not to increase animation smoothing. This can helps the player to adjust the graphic quality of a game...
(Running a \"Pac-Man\" game at 5 Ghz without syncing will produce nothing else additionnal than waste of power).

So what to do to do the things right??
It depend of complexity of the animation
In the simplest cases, a simple TBM is enough. the subject have been discussed often so you surely have read it..
The one I have discussed:
http://forum.thegamecreators.com/?m=forum_view&t=210153&b=6
This is suitable if acceleration is not taken into account. i.e if updating the character is done only with
method like Pos = Pos+Speed*DeltaTime..

But this will fail if speed if varying.. In this case a fixed Deltatime and Loop decoupling is better.


Hope that helps!

I've been using db pro only for a few months now but ive noticed that every time the sync command is used or commands associated with sync everything go's wrong, you can even get anything on the screen, I don't use sync at all for anything just the graphics card as is with this code. I honestly don't think that the sync command is relevant.


PERFORM CHECKLIST FOR GRAPHICS CARDS
DisplayCount = CHECKLIST QUANTITY()
GrafixCardName$ = CHECKLIST STRING$(DisplayCount)
SET GRAPHICS CARD GrafixCardName$
EMPTY CHECKLIST

I still use this code in all my projects, including acceleration of all sorts, and I think it works pretty well. For movements, you'd just take the game.timeFactor value (or game.timedif, but it's an integer and hence has to be cast to float in each calculation, making it a little slower than using the factor instead), for accelerations e.g. a for loop running from 1 to game.fullUpdates, accelerating a value by a constant amount each time.


Regarding OPs problem, I have to agree with TheComet. I don't quite see the problem. The FPS rate does indeed change relatively arbitrarily sometimes, but usually the differences are small enough to prevent the player from noticing it - unless the game just isn't optimized enough and falls beyond the given FPS rate, which of course is a matter of optimization (and lack of timerbased movement), so not really a problem of the language or anything but just quite natural.
So the question that arrises.. do you actually notice a difference due to FPS drops in your game, or is it just the number in the corner of the screen that's irritating you due to not being perfectly constant? If the latter, just ignore it - if not, timerbased movement might be the way to go.

I've been using DBPro for years, and I run all my DBPro games in fullscreen mode (simply because I want them to be fullscreen). Whenever I create a new project, the very first thing I do is copy in the following code:



However, when I created that template code I didn't understand what VSync did. It kept the FPS at a smooth 60fps, but I didn't realise that it also has issues (if you're a gamer you'll understand). So, what I now do is turn VSync off (line 5, set the 1 on the end to 0) and make the game time-based, so everything moves at the same rate regardless of framerate. This is generally a far better method and not at all difficult to do.

EDIT: As Sph!nx said, this thread is an exceptionally valuable resource.

Noted. Some useful suggestions there that I haven't tried yet.

The one thing I don't want to do in an application is use sync rate 0 on its own - it just turns my laptop into an expensive fan heater.

This should solve that (while also limiting your frame rate to ~1000 FPS):

Hopefully.

Hmm, interesting solution. You'd only want to enable the sleep delay when the framerate goes above a high number or you'd be artificially making the game run slower than necessary.

I guess that's the point of it.

I meant you'd be making it run slower than 60 FPS if it already only just reached 60.

True.

I vaguely recall seeing a DBPro oddity where you get the gain from sleep even when you only use the relevant command once. Forgotten the details though. Might be something to do with sync sleep.

That's true, but not by much. Also if it is running at that speed you probably don't want to sleep it but rather just let your game / whatever hog the processor to get as much out of it as possible. The suggestion was in response to the complaints about letting a program run as fast as it can "turns my laptop into an expensive fan heater".

The DBPro built-in sleep function is not CPU-friendly but rather aims to provide perfect timing; it basically does a busy wait until the set amount of time has passed. As such using it will not reduce your program's CPU usage.

Maybe, but there was a discussion a while back where one of the commands involving the word sleep had the effect of reducing the CPU load even when it wasn't being used (or something like that). Unfortunately I can't recall the topic - or precisely what was done. If I find it I'll post back.

I've had a good look around and can't find my earlier test or the relevant thread - and haven't been able to reproduce what I was talking about so perhaps I imagined it. Or perhaps I did something wrong before.

May have been sync sleep as you pointed out above; I looked it up and it apparently basically does the same thing as what I posted above automatically within each subsequent sync call.

Yes, it seems to and only needs to be called once (unlike its use in the DBPro Help file sample code).

I can't reproduce the issue I thought I'd noticed though - which is probably just as well.

I KNOW. That's what I was saying. You sleep for a short time each frame as long as the framerate is above a certain level (say, 65-70) to limit how much time is spent processing unnecessary numbers of frames. If your game is running <60fps, however, sleeping each frame will reduce the FPS even further and make the game less playable.

I did say that, didn't I?

One of the first mistakes is to assume that sync rate 0 will solve the problem. It doesn't , instead, it causes the screen to refresh as fast as possible which actually concentrates resources to the screen instead of processing hence slowing down the app for lack of processing in areas where you need it most.

Therefore, I suggest that to achieve the smoothest possible fps that you lock the frame rate to 50. This gives plenty of room for everything to work nicely.

I see that you did, most sneaky indeed


What...?
You might want to rephrase that, as I read it you're basically saying that you won't give the logic of your program time to process properly by using too high a frame rate? This is most definately not true, the logic will always be processed in full for each frame, the only thing locking a frame rate accomplishes is some superficial waiting when issuing the sync function if your actual frame rate could go beyond that which you lock it to. (Of course you could split your application logic among several frames but that would be up to you too handle by implementing a state machine or similar in your per-frame logic).
Locking the frame rate serves as a (rather crude) means to ensure it won't jump around too much during the course of your program's execution, which can cause lagging / stuttering visuals and updates unless you use a timer based updating system, if that's what you meant however?

Hehe



Exactly what I was thinking. If you limit framerate, the game will sit there for a portion of time between frames doing NOTHING. It doesn't calculate game logic during this time, so you don't lose any time at all for calculating logic if you use sync rate 0. Here, look - the picture below should illustrate my point:





Why 50? No monitor refreshes at 50Hz and 60fps is the norm.

I wouldn't personally do that, because if you use the built-in frame rate locking you'll be using 100% CPU which is a waste of power. Instead consider using v-sync if the computer can handle it, or implement your own frame rate limiter that doesn't use busy waiting.

Did a moderator just delete my post? I can't see it.

ah well it goes like this. Let us suppose you have an area where your fps drops below 60 yet in other parts is over 200. Now if you set a sync rate of 0 then you will have over 140 fps jump. If you set to 60 , then as soon as it gets to that area it will not be quite so noticeable but still there.
If however you set it a little lower then things will appear to run smoothly (assuming of course that you actually drop below 60).

Now as we all know the average refresh rate of most monitors is 60, and in some cases is 75, however the goal here is to provide the appearance of a smooth frame rate with the smallest amount of deviation possible so that things appear to never glitch, jump or any of that. Now if you have an area where the fps drops below the 60 default then this might be useful.

Other things to possibly consider is how dbp reports its fps especially when using vsync. Here are a few things to remember about using vsync via the set display mode command:

When using vsync the refresh rate is capped to the monitor's refresh rate (usually 60fps).
if the rendering area is stretched (usually via window desktop and window fullscreen modes), then it will not be a true framerate returned by "screen fps()"
8 bit screen resolutions are not supported
and lastly this little piece in the documentation of the set display mode command which has a big warning in it:





Have a look at the sync sleep and nice sleep commands. It may prove useful for some of you. (note that the nice sleep requires the Matrix1 Utility Plug-in)

Which one can't you see?



That's silly. It might run perfectly on one user's hardware but not on another's, so limiting it to 50fps just because that provides the smoothest gameplay on your PC isn't going to work on someone else's. The ideal solution is to let the end-user choose what framerate, if any, they want it limited to, and whether or not they want vsync.

no matter which way you go there will be inconsistencies so I suppose it comes down to what you as the developer are comfortable with as each method has its pros and cons.