Sorry your browser is not supported!

When i load a gun model it works but i moves FREAKISHLY SLOW! I have FPSC too and models run fine on that. BUt it moves so slow. Can i fix this thx in advance!

at the top of the code:


at the end of the do-loop:

Actually thats made me curious about the sync rate. I thought once you type Sync on at the start, then DB only updates the screen once it reads a sync, which as you say, tends to be at the bottom of a loop. So what does typing in sync rate 30 do. My thought was that if you specify the sync rate, then a sync is not required as DB will automatically "sync" one time in 30 (or whatever frequency 30 refers too). Can any confirm if my thinking is correct or (most likely) faulty.

Thanks,

@fpsfreak

What is slow? The whole program, or the model's animation (if there is any)

@Hangar18

The computer runs through the code and does any processing it has to, math, strings, memory, whatever... It also handles all the video stuff in between processing or vice versa. Generally, it will try and redraw the screen as often as it can. This may not be at good times for your program, because the resources are going to be allocated based on interrupts (loosly, the timing order that things happen like checking the serial port, or drawing a raster beam). This is where the sync command comes in handy. This gives you a certain amount of control as to how often you want the screen redrawn. When you set the sync rate, you are limiting the refresh to that specific cycle (as long as it's within the fastest possible refresh there can be based on your hardware and the program) and forcing the computer to halt the other interrupts until the refresh is done. This allows you to keep your screen redraws happening at a constant rate. If you set the sync rate to 0, there will be varying FPS on different machines. But if you set it to 40, and the processors aren't too too different then the game should run at the same speed on the other machines(40 fps in this case).

SYNC RATE isn't a maximizer, per say, it is a limiter to set an orderly control as to how often everything is redrawn. This helps to ensure that a game written on one machine will perform the same on another, and it gives you control over the speed in general.

When you place the SYNC command in the loop, your goal is to limit the refresh of the screen until everything before the SYNC command happens. If you had set the rate to 30, it may keep the refresh at 30 fps, but if you did intense math calculations or huge loops before it ever reached the SYNC, you may see a drop in FPS because the processing took so much time before it got to the video refresh. Now the opposite could be true as well. It may take no time at all to do the processing before the SYNC command but since you set it at a limit of 30, it will wait long enough so that the screen refreshes at 30 fps. If you never enter the SYNC command and have used SYNC ON, then the video will not refresh - DBC is waiting for you to indicate when to redraw with SYNC (and it will try to keep the FPS based on the SYNC RATE).

Back in the old days, one would interrupt the raster scan and squeeze in a pointer to code in the time between the redraws of the individual lines on the screen. This code would run and then disable the interupt when it was finished to redraw the next line. This allowed for the illusion of multitasking and a host of other cool effects that today are looked at as standard.

@Latch,

Ah ok, I think I get what your saying. The trouble for me is I use quite a bit of text on screen at the one time and so using sync on with sync commands at the end of a loop has tended to give the best results.

I know that I should defined/create my own texts as DBC is slow with using its own, but I am lazy and its working ok with this method. I will try experimenting with sync rates and see how this affects performance.

Thanks for taking the time to explain the effects of sync rate.

@Hangar and FPSFreak
Following on from Latch:
You must have played games where it asks you to set the Hz (usually 40Hz or 60Hz) before starting the game, it's my understanding that this is the same as SYNC RATE. It will set how many times the screen is refreshed every second (not loop), the SYNC command is simply showing where in the loop you want to perform the synchronisation.
Here's an example:

This code uses two SYNC commands, this effectively cuts the program's speed in half (15Hz) and is bad practice. If your program needs more than one SYNC... re-write it

Try experimenting with the placement of the SYNC command, it can produce entirely different results.

SYNC RATE 0 : sets the computer to sync as fast as it can!
The default sync rate is 30, this is usually fine for simple programs so you don't always have to specify a rate

Latch

I remember the old days of trying to squeeze a small routine into the interrupt or changing the configuration of the video lines on the screen. I did that on some 8-bit machines. That's funny that you remember those days too. Sheesh, I feel old all of the sudden.

LB