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.

Newcomers DBPro Corner / Can someone take a look at this snippet and tell me if I'm understanding SYNC.

Author
Message
NeilF
18
Years of Service
User Offline
Joined: 2nd Aug 2006
Location:
Posted: 19th Aug 2006 10:46
Link


This silly bit of code does the follow:-
UP CURSER - Doesn't do a sync.
DOWN CURSER - Introduces another extra sync.

Some questions...

1) If you click UP CURSER even briefly the rotating goes mad. Is this because basically SYNC does a pause to the next time a frame should be produced? Without this pause the rotation goes super quick so when it is SYNC'd next the cube has rotated basically into a random position?

2) This seems to be backed up by the fact that if you press the DOWN CURSOR, because how there are twice as many SYNCs for each step of the rotation, the rotation halves in speed.

3) What the hell is clearing the screen? You'll see the dots I'm plotting on the left part of the screen disappear each loop. What is actually doing/controlling that?

4) Why is my FPS always 10% higher than my specified figure? If I specify 30, I get 33fps. If I specify 50, I get 55fps.


Thanks alot!
Back to top
Profile PM
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 19th Aug 2006 13:07
Link
As a general rule, you should SYNC every loop. Some cycles, there may be nothing to do, but that doesn't matter. Your program will be much easier to follow as it grows if you know there is a SYNC every loop. Having 2 SYNCs is possible, but under normal circumstances "odd".

2D operations to the screen, such as DOT, BOX, and TEXT are cleared every SYNC.

SCREEN FPS() is an approximation of the SYNC RATE. SYNC RATE is also a tool for throttling the rate, but isn't necessarily 100% accurate. If you want deadly accurate timing, you need to code a timing routine of your own, and set the SYNC RATE to 0.



Back to top
Profile PM Email
NeilF
18
Years of Service
User Offline
Joined: 2nd Aug 2006
Location:
Posted: 19th Aug 2006 20:35
Link
1) So is my assumption that SYNC is just doing a pause till the next frame is correct?

2) What is clearing the screen? For example I can take out every sync related command in my code (snippet) so it runs at 500+ FPS but still something is clearing the screen. It's something magical to do with the "make object"! The software then decides to start clearing the screen for me?

What if I want to control the refresh/display of the screen? What if I want to render some graphics and only when I've finished then present them to the monitor - so as to prevent flickering?

When I used to program in machine code you'd basically render a new screen and then when it's complete tell the graphics card it was OK to move from the old image to the new one. (Therefore getting no flickering)
Back to top
Profile PM
Daemon
18
Years of Service
User Offline
Joined: 16th Dec 2005
Location: Everywhere
Posted: 19th Aug 2006 20:51
Link
The sync command causes no pausing. It is exactly what you describe at the end of your post, it tells the computer to update the screen. You would put a sync once in a loop like BatVink said to update the screen once each time through the loop instead of it updating after each command.

Yes, when you make an object (or sprite) the computer begins clearing the screen for you. This is because making an object (or sprite) turns the backdrop on. If you don't want this to happen put "backdrop off" at the very beginning of your code.

Back to top
Profile PM Website
NeilF
18
Years of Service
User Offline
Joined: 2nd Aug 2006
Location:
Posted: 19th Aug 2006 21:52
Link
Quote: "The sync command causes no pausing."


That makes no sense though! If I take away the SYNC related coding my cube spins at a rediculous rate - Each loop rotating it by a value of 1.

Infact I can prove you're wrong.



This shows the time the SYNC statment takes. My example is running at one frame second, to the sync statement pauses for nearly a second. Change the sync rate to 2 (frames a second), and you'll then see the SYNC statement pauses for nearly half a second.

So my assumption is right surely?!

I find I have to know what things are doing in reality before I can use them...
Back to top
Profile PM
Daemon
18
Years of Service
User Offline
Joined: 16th Dec 2005
Location: Everywhere
Posted: 19th Aug 2006 22:05 Edited at: 19th Aug 2006 22:07
Link
Sync rate does restrict the frame rate, sorry I misunderstood what you were saying.

What I was talking about was the difference between this (using sync):



and this (without sync):



The difference would be more evident if more was happening in the loop, but basically the first one is updating the screen once in the loop and the second is updating it once after each command. Sync rate 0 means that it won't restrict the frame rate.

Back to top
Profile PM Website
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 20th Aug 2006 00:10 Edited at: 20th Aug 2006 00:13
Link
This may help...

You are using a double buffer system. You draw to the backbuffer, and when you have finished drawing, you SYNC. This puts the backbuffer to the screen buffer, which is what your user sees. This prevents the user seeing half a rendered screen, they only see the complete article.

The backbuffer always starts blank. So even if you have dots on the screen, you don't have dots on the backbuffer. After "drawing all of your 2D stuff, DirectX overlays the 3D objects - models, sprites, shaders and so forth. So the 3D stuff is always present because DirectX is applying every time. In contrast, it's up to you to keep redrawing the 2D stuff over and over again.

Going back to ypur previous thread about starfields, this is why using a particle system, using 3D textured plains or sprites, is so much easier from a programmers perspective.

There are advanced methods to do what you are trying to do, saving the screen to a memblock (chunk of memory). However, for a first (or 2nd, 3rd or 4th!) project, it can cloud the simplicity of what DarkBASIC can do without getting complex.

SYNC can effectively pause the program. If your program/system is running at 300 FPS, and you SYNC at 30 FPS, it will spend 90% of the time doing nothing. However, if your system runs at 15 FPS, there will be no delay and your code will run as fast as it possibly can. It will not run at 30 FPS though, this is simply the fastest rate you have specified for your application.



Back to top
Profile PM Email
NeilF
18
Years of Service
User Offline
Joined: 2nd Aug 2006
Location:
Posted: 20th Aug 2006 00:15
Link
Now that explains it!

The double buffering is basically being automated for you
Back to top
Profile PM
Back to top

Login to post a reply

Server time is: 2024-09-25 07:29:06
Your offset time is: 2024-09-25 07:29:06