Yea, there is and it's a method called "forced timing", introduced to us by Orgull from the old DB forums. It's kinda like setting how many times you want a function to be called in a loop. Anyway, I'll just copy-paste the whole article here.
Quote: "Forced Timing For Better Performance
Orgull
Hey there!
Forgive me if this gets a bit long, but speed optimization seems to be the big issue with DarkBasic, so I feel this is a very important subject. I have examined source code for about two dozen games written in DB and I have NOT ONCE seen anyone use this technique. I'd like to share it with you all. If you know and use this already, I apologize if I come across sounding preachy, I get zealous when a topic matters to me. F.Y.I., I developed this method back in the late 80's, when the vast differences in speed between machines meant that you had to time your code carefully, or else it wouldn't run on every system. The method is called "Forced Timing".
Q) What is forced timing and how do I use it in DarkBasic?
In a sentence, forced timing is a method of calling functions and subroutines from the main loop at a fixed rate. This is done using a simple set of variables. I'll give an example program that calls three subroutines: Userinput, Cameracontrol, and Playercontrol. Immediately before your main program loop begins, include the follwing lines:
basetime = timer()
inputtime = basetime
playertime = basetime
cameratime = basetime
...
Then, immediately following the start of the main loop, add yet another timer line.
MAIN:
do
basetime = timer()
Simple so far? That's part one, the setup. Now part two comes when you call your subroutines. This won't make sense yet, so please bear with me. Here's how you call your subroutines.
if inputtime < basetime then gosub Userinput
if playertime < basetime then gosub Playercontrol
if cameratime < basetime then gosub Cameracontrol
gosub Updatevisuals
sync
loop
The first time through, each of the subroutines will be called since inputtime, playertime, and cameratime are all less than basetime. Notice that basetime updates itself EVERY loop.
This is part two, the timed call. Now the third part happens at the end of each subroutine.
Remembering that the timer increments 1000 times per second, add this line to the end of every timed subroutine, just above the return statement.
...
inputtime = basetime + 40
return
Now, the Userinput subroutine will only be called when basetime catches up with inputtime. Since we've given this routine a time of 40, it will be called at a rate of 25 times per second. (1000/40) Do the same for all the other timed routines. This is the third and final part of "Forced Timing".
Ask yourself, how often to visuals need to be updated. Answer: as often as possible. But, how often do we need to get user input? Not as often. Even in the fastest game, calling userinput 25 times a second instead of during every loop will free up speed for the visuals.(which really is the whole idea here isn't it?) In one program I just wrote, I use the following times
viewcontrol = basetime + 20 (calls 50 times a second)
cameracontrol = basetime + 40 (calls 25 times a second)
playerinput = basetime + 80 (calls 12.5 times a second)
refreshstatusbar = basetime + 250 (calls 4 times a second)
Using this method I regulary get 60-75 fps on my PII-450 even when displaying complex multiple objects. (which is something DB has a terrible time doing quickly)
I hope this method helps. There is more to it, but I don't want to write a book... not today anyway."
Hope that helps
AsriCE Crew,
- Adi
There's only one hope.
