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 / Print command problem

Author
Message
Maxentius
13
Years of Service
User Offline
Joined: 24th Oct 2012
Location:
Posted: 24th Oct 2012 21:57


i created code using the "print" command and input commands to collect the variables...the program then draws to bitmap 1 and then copies the bitmap as a texture to a sphere...upon ending the sphere rotation loop, deleting the sphere and sending the program back to the beginning where it asks again for new variables the program does not show the text created with the print command nor text created with the input command...it will however display what you type when it asks you for variable information..such as print "start of program" input "how many colors? 1-256"...i looked around on the forums and my book on DBPRO but can't find anything
TheComet
18
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 25th Oct 2012 01:13
When you create a sphere, DBP turns the backdrop on. That's your problem. The fix is to add this after you delete your sphere:



Let's discuss screen settings. Here are the commands:



Alright, so what does each command do? Turning sync on will give you control of when to render to the screen. When sync is on, the screen will only be updated when you use the command sync. By default the sync is off, which causes the screen to be refreshed after every single command. This is very rarely needed.



Run that. No text, huh? Try turning the sync off. You will see text again. After that, try turning the sync back on and take the "rem" away from the sync command. Text text will be rendered to the screen.

What does sync rate do? This command defines how fast you can update the screen per second. Here's an example:



Try changing sync rate to 30 and see what happens.

Never go over 60 frames per second unless you know what you're doing. It does not make any sense because the monitor physically can't refresh faster than 60 frames per second. You'd be wasting GPU power.

Alright, so what is the backdrop? The backdrop is pretty much the picture you see on your screen. If we turn the backdrop on, this will cause the backdrop to clear itself before every screen update. The backdrop is off by default, which means that the backdrop isn't cleared before updating, which causes the new data being printed to the screen to accumulate.

Run this to see:



You should only be able to see "awesome". Turn the backdrop off, and you will see everything again. Note that we don't have to call sync because sync is off by default.

Alright! So with that out of the way, you should now understand how to use screen settings.

TheComet

"Why geeks like computers: unzip, strip, touch, finger, grep, mount, fsck, more, yes, fsck, fsck, fsck, umount, sleep." - Unknown
Sergey K
22
Years of Service
User Offline
Joined: 4th Jan 2004
Location:
Posted: 25th Oct 2012 01:13
not sure what you mean, but here is a small sample for you that discribes all what you wrote just now:

Static Text:


this is dynamic text (just type something in order it to work):


Advanced Updater for your games!
Maxentius
13
Years of Service
User Offline
Joined: 24th Oct 2012
Location:
Posted: 25th Oct 2012 01:24
thanks guys the backdrop was the problem! and thanks for the added info too!
Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 25th Oct 2012 02:13
Neat.
Maxentius
13
Years of Service
User Offline
Joined: 24th Oct 2012
Location:
Posted: 25th Oct 2012 05:07
just in case my last reply did not post, thanks for the help!
Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 25th Oct 2012 05:26 Edited at: 25th Oct 2012 06:14
Quote: "What does sync rate do? This command defines how fast you can update the screen per second. Here's an example:"


If you are going to make a frame limiter, then SYNC SLEEP might be a better choice.



Adding a frame limiter will basically convert extra spare frames (anything above the limit) into resting periods where your GPU can cool off. However, most methods including SYNC RATE, SLEEP, WAIT have the CPU still working at 100%. Using the method I just posted, your CPU gets a break and can cool down too.

Heat's an issue, I'd recommend this approach.

MrValentine
AGK Backer
15
Years of Service
User Offline
Joined: 5th Dec 2010
Playing: FFVII
Posted: 25th Oct 2012 09:03
Mage, I just might try that one, and Sergey K, very nice!

Chris Tate
DBPro Master
17
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 25th Oct 2012 13:40
Following on, If you download Matrix1 utilities, the Nice Wait command cuts a larger amount of CPU usage.

Check the process in the performance window to see the difference:



Press spacebar to advance through each test, escape to exit. (Nice Wait uses < 1 CPU resources on my machine; the other tests take up 80)

Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 25th Oct 2012 14:45 Edited at: 26th Oct 2012 14:45
I don't really understand the point of those variations. Why not simply use sync rate 30?

I modified your demo a bit to get smooth syncing. I also added an extra option to use sync rate and adjusted the starting code so it resets properly:



I get about 3500 fps with 50% CPU usage for the start setting and about 30 fps with about 2% CPU usage for each of the other options.

Edit For some bizarre reason my original snippet didn't include the sync rate 30 command. Reinstated now.
Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 26th Oct 2012 03:13 Edited at: 26th Oct 2012 04:05
Quote: "I don't really understand the point of those variations. Why not simply use sync rate 30? "
Quote: "Following on, If you download Matrix1 utilities, the Nice Wait command cuts a larger amount of CPU usage.

Check the process in the performance window to see the difference:"


I don't see any real difference to using the plugin command Nice Wait vs. the new built-in command Sync Sleep. Well Ok one limiter was at 25fps vs. 32fps using the same values. So there might be a wait time accuracy thing there. But both commands suspend the CPU and GPU workload.

The whole point is if the game is drawing frames faster than needed you can use the free time to wait and let the hardware cool off. This flies in the face of frame rate decoupling which uses this extra time to do additional background processing. Shader heavy games get heat problems. Battery powered devices last longer with less workload. This CPU friendly frame limiter is the better approach for video games.

In either command examples I found the CPU sat at 0% the entire time. With Sync Rate 30 the CPU was maxed out the entire time. With Sync Rate 30 you get the effect of a frame limiter but the CPU doesn't get a break.

Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 26th Oct 2012 14:53 Edited at: 26th Oct 2012 15:10
Quote: "With Sync Rate 30 the CPU was maxed out the entire time. With Sync Rate 30 you get the effect of a frame limiter but the CPU doesn't get a break."


I hope you used the corrected version of my snippet - see edit.

Anyway, with the sync rate 30 command actually included here's what I get:



The final option looks simplest to me.

This obviously depends on the system set up in some way. For example, the laptop switches between two different GFX card systems in some non-obvious way (Nvidia Optimus system).

I'll check my corrected snippet on my other machine and edit this post with the results.

Edit Added results for desktop and tidied up the results layout. Same story - sync rate 30 is simplest and seems to achieve same results.
Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 27th Oct 2012 00:34 Edited at: 27th Oct 2012 01:45
Quote: "The final option looks simplest to me.

This obviously depends on the system set up in some way. For example, the laptop switches between two different GFX card systems in some non-obvious way (Nvidia Optimus system).

I'll check my corrected snippet on my other machine and edit this post with the results.

Edit Added results for desktop and tidied up the results layout. Same story - sync rate 30 is simplest and seems to achieve same results. "


With respect, I disagree.
You are almost correct!

This is called Demo Glamor. Where the results look great in a demo and don't work when applied elsewhere.

I'll tell you why. Sync Rate doesn't reduce the CPU workload as you observed. It will keep the CPU at 100% Unless -- You call Sync Sleep 1 after the Sync On command. Then without warning Sync Rate becomes CPU friendly.

In fact the effect seems to only work with Sync Sleep 1 and no other values. This smells like a bug. It's as far as I can tell, undocumented behavior that could very well change without warning. I fear that even the use of other unrelated commands could cause this behavior to suddenly change. There's no degree of reliability here.

Want Proof? Make the Sync Rate test, the first test in the demo. Suddenly its using 100% CPU.

Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 27th Oct 2012 01:23 Edited at: 27th Oct 2012 01:49
But wait there's more!

Nice Wait also seems to use more CPU when Sync Sleep is never called once. It seems that Sleep Sync is affecting both other methods.

Removing the Sync Sleep method from the code made Nice Wait method increase from 0% to 24% CPU usage and Sync Rate method increase from 0% to 100%. Update: Not happening on every computer I tested.

When these methods are properly isolated Sync Sleep is the only one showing 0% CPU usage. Now I want the best method possible, so someone, anyone, put me in my place, prove I'm wrong here.


Edit:
Quote: "This obviously depends on the system set up in some way. For example, the laptop switches between two different GFX card systems in some non-obvious way (Nvidia Optimus system)."

I have a Dell Laptop with this nVidia system that I just tested. Nice Wait is at 0% instead of 24%, Sync Rate is still at 100%, and Sync Sleep is still at 0%.

Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 27th Oct 2012 02:28 Edited at: 27th Oct 2012 02:31
That's weird. I'll see what I get tomorrow and report back.

Edit Just a quick question for now. If, as you say, the CPU is indeed at 100% when you set sync rate 30, what do you think it is doing exactly?
Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 27th Oct 2012 03:48 Edited at: 27th Oct 2012 03:54
It's probably just looping until a timer is reached, burning CPU cycles. However since Sync Sleep called even once can affect it, it can't literally be that. There must be either an alternate handling it switches to, or a really crappy CPU Friendly sleep in said loop that only works on very specific conditions, possibly on account of a bug.

I have never heard of Sync Rate being CPU/Windows friendly. I have only ever heard talk of separate wait/sleep plugins being needed. Sync Sleep is a relatively new command.

Also: If you have a Multi-Core CPU, DBP will only use 1 core. So maxing 1 core will be roughly 25% CPU usage on a 4 Core CPU and 17% on a 6 Core CPU. Windows will round these numbers to whole numbers. Windows task manager will in these cases not report numbers that are direct percentages of CPU usage for the purposes of this discussion.

Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 27th Oct 2012 12:05
Just done a quick test and I've confirmed your results. As you say, a single sync sleep 1 command makes the reported CPU usage drop when you use sync rate 30. That side effect seems like a useful feature to me - but as you suggest it could be a bug with unpredictable consequences.

I now agree with your other comments too. Thanks for persisting with this.

Quote: "Also: If you have a Multi-Core CPU, DBP will only use 1 core. So maxing 1 core will be roughly 25% CPU usage on a 4 Core CPU and 17% on a 6 Core CPU. Windows will round these numbers to whole numbers. Windows task manager will in these cases not report numbers that are direct percentages of CPU usage for the purposes of this discussion."


Good point - my 50% figure was on a dual core core PC.

It still seems to me the case that sync rate 30 is the simpler option as it doesn't seem to require any code in the main loop - but it only has that effect if you add at least one sync sleep command before the loop (with a positive argument - a zero value seems to switch off the effect you've discovered). I'd be reluctant though to rely on an undocumented feature/bug. What do you think?
Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 27th Oct 2012 15:05
Quote: "I now agree with your other comments too. Thanks for persisting with this."


Hey, it's what I do.
http://www.gateworld.net/gallery/albums/sg1_season5/512-WormholeXTreme/screencaps/normal_sg1_512_688.jpg

Quote: "It still seems to me the case that sync rate 30 is the simpler option as it doesn't seem to require any code in the main loop - but it only has that effect if you add at least one sync sleep command before the loop (with a positive argument - a zero value seems to switch off the effect you've discovered). I'd be reluctant though to rely on an undocumented feature/bug. What do you think?"


I certainly see why. If it's stable then it has an advantage of being simpler to use. However the effect could very well disappear as quickly as it came. Too many memblocks, the wrong shader, second camera added, who knows. It could even be stable and in the next update be completely gone.

I'm already wrapping Sync inside it's own function because of other effects and things. So in my case adding a global variable to track sync timing and the several lines of code for the limiter isn't that big a deal.

If Lee came out and said Hey this is working exactly as intended, then that's a different matter entirely.

Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 27th Oct 2012 17:33
Quote: "If Lee came out and said Hey this is working exactly as intended, then that's a different matter entirely."


Very true - but it's hard to see what purpose the default behaviour serves. Why not make the behaviour with sync sleep 1 the default? Can you see a down side to this? How are background tasks such as AV scanning affected for example?
Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 27th Oct 2012 19:05
I cannot offer anything beyond speculation. It's possible there are unforeseen consequences on the system or hardware level in certain situations. It is also possible this is old obsolete code.

Login to post a reply

Server time is: 2026-07-07 11:46:47
Your offset time is: 2026-07-07 11:46:47