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 / 1st Sync is dissed

Author
Message
heartbone
23
Years of Service
User Offline
Joined: 9th Nov 2002
Location:
Posted: 17th Jul 2003 09:38 Edited at: 17th Jul 2003 09:40
Link
The first Sync command executed in a DarkBASIC Professional program does not work.

Test it for yourself. Run the code below as it is, then uncomment the second line and run again. Or comment out the first uncommented Sync for a different test.

Even with this bug, DBP is much, much better than DarkBASIC v1.13 sync functionality. There the Sync command is useless, since the Sync On command is dysfunctional. You can not prevent Sync from being called. Run this same program in DBC to prove it.



The more you see, the more you know.
The more you know, the more you see.
Back to top
Profile PM Website
Shadow Robert
23
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 17th Jul 2003 09:52
Link
not a bug... dbp uses the sync in DirectX 8.1+ fashion, dbv1 uses Dx7.0+

totally different render & syncronisation setups - its doing what it should

Back to top
Profile PM Email Website
heartbone
23
Years of Service
User Offline
Joined: 9th Nov 2002
Location:
Posted: 17th Jul 2003 10:01
Link
Raven:
not a bug... dbp uses the sync in DirectX 8.1+ fashion, dbv1 uses Dx7.0+
totally different render & syncronisation setups - its doing what it should

Raven I know a bug when I see one.
Dude, you must be confused. I am programming in DarkBASIC, not DirectX.

Taken from the DarkBASIC Professional Reference Manual

SYNC
This command is used to improve the performance of demanding programs that require a consistent frame rate. This is especially true of games. By default, sync is set to off which allows the system to automatically handle screen refreshing. When SYNC ON is used, your program is responsible for handling screen refreshing. You can refresh the screen using the SYNC command. When you want the system to automatically handle screen refreshing again, you can use the SYNC OFF command. By placing the SYNC command at the end of your main program loop, all drawing DarkBASIC Professional - The Ultimate 3D Games Creator and refresh tasks can occur in a single call. This dramatically increases the speed and smoothness of graphical operations, allowing your programs to run at their best.

SYNTAX
Sync

The more you see, the more you know.
The more you know, the more you see.
Back to top
Profile PM Website
indi
23
Years of Service
User Offline
Joined: 26th Aug 2002
Location: Earth, Brisbane, Australia
Posted: 17th Jul 2003 10:52
Link
the sync seems to work ok here once the sync rate is established.

this bit of code shows that the current timer is slightly out each loop and that the fps setting that sync is set to is set to 110%
60 = 66.

the flickering of the timer would change due to background cpu instructions fluctuating correct?

is there were a an accurate timer is required.?
What tests did you try with the fast sync command as well?
If i synced this at say 90 would that change the timer result?



http://www.lunarpixel.com
http://www.lunarpixel.com/dt/
Back to top
Profile PM Email
Ratty Rat
23
Years of Service
User Offline
Joined: 24th Sep 2002
Location:
Posted: 17th Jul 2003 12:02
Link
Heartbone - I tried your bit of code and that is an interesting effect.

Ravens assertion that Direct-X is to blame may well be correct.

At some point when you use the sync command DB/DBPro will call the Direct-X 7/8 core commands to update the display based on new data that DB has set up. Direct-X may have an overloaded buffer of commands or may be trying to establish a sync rate (or something, I`m hardly an expert on Direct-X), particularly if it just started up, in which case it may simply buffer the commands DB sends it and thus they get updated on a later sync.

It is also quite likely that text commands like 'Print' by-pass the direct-x core and write directly to the screen buffer, hence the Text shows up before the sprites.

Simple solution is to ensure your programs call sync a couple of times before getting to the main loop (it`ll only waste a few microseconds after all).

Indi - sorry I can`t work out what your bit of codes trying to do.

"Don`t try to engage my enthusiasm, I don`t have one"
Back to top
Profile PM
Richard Davey
Retired Moderator
24
Years of Service
User Offline
Joined: 30th Apr 2002
Location: On the Jupiter Probe
Posted: 17th Jul 2003 16:02
Link
heartbone - this is not a bug. It's behaving just the way it should and we've discussed this topic many times both here on Apollo and on the old DB forums before that.

Although you can use the sync command to control when DB/P should sync - you cannot ever stop your video card from forcing a sync. If you fill up the available video memory the card will simply flush out the results (ala SYNC) to the screen and you cannot stop this in either DB or DBP.

It's simple to test - write a loop that plots random dots on the screen and leave it running. Depending on the amount of video memory your hard has depends on how long it will take before it automatically syncs, but it will ALWAYS happen eventually.

The reason your first (commented out) sync command doesn't appear to do anything is because it's got nothing to do at that point in the program. There literally is nothing to sync. So that's what you get regardless of commenting it or not.

SYNC ON works with in DB and DBP, but you can code situations where you forget to sync which makes it appear broken. It's not, you're just filling up your video mem carelessly.

Cheers,

Rich

"Gentlemen, we are about to short-circuit the Universe!"
New DBS Web Sites Coming Soon - All Change
Back to top
Profile PM Email Website
Ratty Rat
23
Years of Service
User Offline
Joined: 24th Sep 2002
Location:
Posted: 17th Jul 2003 16:39
Link
Rich - to jump to heartbones defense - did you actually run the code with and without that first sync? Because without it the first thing you see is the message 'program running'. without it you see the coloured boxes first then the message IE without that first sync before any graphic operations the first set of graphics never appear, despite there being a sync directly after they are drawn.

As you say the presence or not of the first sync should make no difference, BUT IT CLEARLY DOES!

Not that I`m fussed, as I say its easy to get round.

"Don`t try to engage my enthusiasm, I don`t have one"
Back to top
Profile PM
Ratty Rat
23
Years of Service
User Offline
Joined: 24th Sep 2002
Location:
Posted: 17th Jul 2003 16:40
Link
OOPS! obviously that should read '...Because without it the first thing you see is the message 'program running'. with it you see the coloured boxes first then the message ...'

"Don`t try to engage my enthusiasm, I don`t have one"
Back to top
Profile PM
Shadow Robert
23
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 17th Jul 2003 18:12
Link
no but Heartbone is blaming the sync for the problem... when it isn't the sync's fault - it is a bug in the other commands.

i've also experienced thier is sprites and text... infact the text commands appear to be extremely buggy - something that i hope DBS are paying some close attention to.

Back to top
Profile PM Email Website
heartbone
23
Years of Service
User Offline
Joined: 9th Nov 2002
Location:
Posted: 17th Jul 2003 21:42 Edited at: 17th Jul 2003 21:43
Link
Hey I'm just reading what the commands are supposed to do straight from the reference manual. rich if you are correct, then the DarkBASIC manual has to be wrong. Who to believe you or the manual... about something so fundamental?

This was just a report. Ratty Rat is correct, there's a simple fix for the programmer. Just make sure that you call sync once before you need it, the purpose of that first sync command is undocumented, but it is needed.

The more you see, the more you know.
The more you know, the more you see.
Back to top
Profile PM Website
heartbone
23
Years of Service
User Offline
Joined: 9th Nov 2002
Location:
Posted: 17th Jul 2003 21:58 Edited at: 17th Jul 2003 21:58
Link
rich you should run the programs and observe the effect for yourself. If you do that and are convinced that it is not a bug then DarkBASIC should change the documentation. After running it unmodified and seeing the behaviour, then uncommenting out the first sync and rerunning it you should understand. If still not convinced, comment out the first two syncs and rerun it. That should do it.

rich :Although you can use the sync command to control when DB/P should sync - you cannot ever stop your video card from forcing a sync. If you fill up the available video memory the card will simply flush out the results (ala SYNC) to the screen and you cannot stop this in either DB or DBP.
.........
SYNC ON works with in DB and DBP, but you can code situations where you forget to sync which makes it appear broken. It's not, you're just filling up your video mem carelessly.

In Dark Basic V1.13 the buffer must be a single pixel.

DBCv1.13 actually appears to auto Sync based on time, not the quantity of data. Run the sample program in Dark Basic and compare it to DBP. Surely a single small sprite or single print is not causing these syncs. Many discussions or not, Sync on does not work in DBV113 executables on my systems.

The more you see, the more you know.
The more you know, the more you see.
Back to top
Profile PM Website
heartbone
23
Years of Service
User Offline
Joined: 9th Nov 2002
Location:
Posted: 18th Jul 2003 22:05
Link
Raven: "no but Heartbone is blaming the sync for the problem... when it isn't the sync's fault - it is a bug in the other commands."

Since I don't know if the problem is in Sync or elsewhere, I didn't specify where the problem is. Your statement in reference to me is incorrect. Is English your native language?

I do find it somewhat odd that you answered a question from Ratty Rat personally directed to Rich.

The more you see, the more you know.
The more you know, the more you see.
Back to top
Profile PM Website
HZence
23
Years of Service
User Offline
Joined: 9th Mar 2003
Location:
Posted: 18th Jul 2003 23:13
Link
HeartBone: "I am programming in DarkBASIC, not DirectX."

DirectX isn't a programming language, lol.

SW Games - www.freewebs.com/swgames

Yeah, I know, I only have one game. Yeah, I know it sucks. But I made it! Me!
Back to top
Profile PM
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 19th Jul 2003 01:41
Link
One display surface, one backbuffer that you've finished drawing to (after a sync) that is waiting to display, and one that you can draw to immediately.

You basically have a choice of whether you want slow but more video memory, or fast and less. DBPro selected the fast way. No bug here, just the way it is
Back to top
Profile PM Email Website
Back to top

Login to post a reply

Server time is: 2026-07-21 12:50:29
Your offset time is: 2026-07-21 12:50:29