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 Discussion / Dark Basic 100% CPU Usage

Author
Message
Irojo
15
Years of Service
User Offline
Joined: 21st May 2008
Location: Eating toast.
Posted: 9th Dec 2008 21:36 Edited at: 9th Dec 2008 21:38
Hey guys. I've been running DarkBasic, and I got a depressingly low FPS on my program. So I remed out the for...next loop, and the FPS stayed the same. After alot more reming out the code, I just had it print the FPS rate in a loop. It had not changed, and was at 59.
Sync was on, the screen was being synced, and it was at sync rate 0.

So I went to Windows task manager, and sure enough, my computer was at 100% CPU Usage. I closed every single program besides DarkBASIC, and my computer was still at 100% CPU Usage. So I closed DarkBASIC, and, sure enough, the CPU usage went down to 0.

This has occured before, and my computer is pretty good. (Windows XP) I wasn't sure if it is a memory issue (I don't know where to check my memory ), or not. But anyways, if there is some way to reduce the DarkBASIC CPU Usage without restarting my computer (This happens alot) please let me know.

Thanks a bundle,

-Irojo


I download memory.
zenassem
21
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 9th Dec 2008 22:15
I think both dbc and dbp use 100% of the cpu regardless of what you are running. I know there is a value in the files you can change so that DBP is lighter on the cpu, but I am not sure about dbc. I'll edit the link about DBP to here.

~Zenassem
Irojo
15
Years of Service
User Offline
Joined: 21st May 2008
Location: Eating toast.
Posted: 9th Dec 2008 22:26
Oh. Thanks.

Should the effect the FPS though, or is it an outside computer issue?


I download memory.
zenassem
21
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 9th Dec 2008 22:40
I found DBP has the command 'SYNC SLEEP 1' which eases up cpu usage, but I doubt dbc has it.

I don't know why you are locked at 60 FPS, that doesn't sound right.

~Zenassem
Ashingda 27
16
Years of Service
User Offline
Joined: 15th Feb 2008
Location:
Posted: 9th Dec 2008 22:50
I ran the same test and I'm also locked at 60-63 fps. All it was was a DO-LOOP that prints the fps on the screen.
steve paul thomas
15
Years of Service
User Offline
Joined: 4th Nov 2008
Location: United Kingdom
Posted: 10th Dec 2008 02:20 Edited at: 10th Dec 2008 02:21
Mine's locked to 60fps, even running this basic code:



Setting sync rate to 0 produces the same result.

I don't Adam and believe it!
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 10th Dec 2008 03:16 Edited at: 10th Dec 2008 03:20
Are these dual core processors? Some graphics card drivers with dual core processors can cause this.

Is there a vertical sync lock in the graphics card settings or in the CPU processing somewhere? This cam limit refresh to the montiors refresh.

Enjoy your day.
Irojo
15
Years of Service
User Offline
Joined: 21st May 2008
Location: Eating toast.
Posted: 10th Dec 2008 03:34
Woah woah woah woah.

I have no idea what you are talking about.

Heeehee.

Where do I find if I have a dual core processor?

It rings a bell... I think I might have it.


I download memory.
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 10th Dec 2008 03:49
Check your graphic card settings from the windows control panel under display. There should be a settings option and maybe an advanced button. There should be a series of tabs or buttons depneding on the graphics card. But one of the tabs should read direct x or D3D .

There should be an option for V-Sync or Vertical Sync or something that say wait for vertical sync. If this is checked, fullscreen mode is limited to the refresh rate of the monitor. So if you're running DBC in fullscreen mode, your FPS may be limited. See if unchecking this makes any difference and also try running your DBC apps in windowed mode and see what the refresh is.

The apps also behave differently if they are compiled into an executable in windowed mode or fullscreen mode. Try different things and see if there is any difference.

But the locking at 60 fps suggests that there's a setting somewhere on the computer (most likely the graphics card) that's locking the vertical sync to the monitor's rate.

Enjoy your day.
Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 10th Dec 2008 05:11 Edited at: 10th Dec 2008 05:12
Quote: "So I went to Windows task manager, and sure enough, my computer was at 100% CPU Usage. I closed every single program besides DarkBASIC, and my computer was still at 100% CPU Usage. So I closed DarkBASIC, and, sure enough, the CPU usage went down to 0."

Are you referring to an application built and executed externally or the editor in general? As the latter will use as much CPU as it wants.

If the frame rate seems stuck at 60 then as Latch said, you must have v-sync enabled.

If the application is running at a good speed but you feel it's using up too much CPU, use the system's Sleep() function to relinquish some processing time back to the CPU, like this:



Ashingda 27
16
Years of Service
User Offline
Joined: 15th Feb 2008
Location:
Posted: 10th Dec 2008 06:28
I tried Window mode and Turing off V sync and still get the same results.

Might be what latch said about the cpu.
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 10th Dec 2008 17:00
Also, for 60 fps lock, try looking in the BIOS for a vsync setting.

Enjoy your day.
Robert The Robot
17
Years of Service
User Offline
Joined: 8th Jan 2007
Location: Fireball XL5
Posted: 14th Dec 2008 16:35
This thread has reminded me of something I discovered about DBC a while back. I have the same problem as , with screen fps capping at 60, and the processor maxing out at 100%. However, several months ago I discovered that having Windows Media Player open would increase the frame rate (a purely accidental discovery, I like having music on while I code )

I was testing all this again in the last day or so, and I've found that just having Windows Media Player open will make a 2d application (with only "paste image" commands, "Sync : Cls" etc.) run at about 180-200 fps, while a 3d application (just a 3d cube on screen) will run at around 120fps.

I then tried loading an mp3 directly using DBC's "Load Music" command, and that triggered the same rise in Screen FPS. Why this should be so, I've absolutely no idea - the music doesn't even have to be playing, it just has to be loaded. Midi files have no effect whatsoever.

But perhaps the strangest thing is that the CPU stops maxing out at 100% when an mp3 is loaded - my CPU meter settles down to a slightly more comfortable 70%. The actual value might be a bit lower, I have trouble viewing the meter while a DBC app is running so I have to guess a little.

"I wish I was a spaceman, the fastest guy alive. I'd fly you round the universe, in Fireball XL5..."
Irojo
15
Years of Service
User Offline
Joined: 21st May 2008
Location: Eating toast.
Posted: 14th Dec 2008 17:27
That is the most bizarre thing I've ever heard of.

I'm going to try that!

Thanks.


I download memory.
Libervurto
17
Years of Service
User Offline
Joined: 30th Jun 2006
Location: On Toast
Posted: 14th Dec 2008 18:01
is it just media player or does having anything open raise the fps?

A small program that works is better than a large one that doesn't.

DBC Challenge Rank: Rookie
Robert The Robot
17
Years of Service
User Offline
Joined: 8th Jan 2007
Location: Fireball XL5
Posted: 15th Dec 2008 17:00
Hi guys, I’ve been doing some more tests and I’m afraid I spoke too soon when I commented on these fps rises – they only apply to code run directly from the editor. Standalone EXE files continue to cap at 60fps. I used this code


And from the editor
No program: 63-64 fps.
MS Word 2003: 63-64 fps.
MS Excel 2003: 63-64 fps
DBPro Default IDE: 63-64 fps
Cartography Shop 4: 500-511 fps
FPS Creator Free: Approx 490 fps, although fpsc crashed on program exit.
Windows Media Player 11 (open): 255 fps
Windows Media Player 11 (playing an mp3): 500 fps

But an exe stays fixed at 60fps no matter what is opened. So, I started playing around with VSync, as Latch suggested. With VSync disabled, the code snippet shown above runs in the editor at 500fps and as an exe at 600fps.

Now, it’s probably just me, but I’m very wary of fiddling with things in the control panel – not to mention, it gets tedious for the user if they have to keep changing things from game to game. I’m also concerned by this “tearing” effect that the help pages warned about. I’ve no idea what it is, and I haven’t seen it in the tests I did, but it doesn’t sound good.

So, I started looking at the code Benjamin posted. I modified it a little to run in a “Full-screen Windows mode”, and it comes in at 170fps as an exe or in the editor, with cpu usage down to about 60-70% for a single core. (The set Window on commands don’t make any difference to the code in the editor, but without them the exe caps at 60 again)


So the upshot of it all is that a DBC exe runs with a default of VSync on, a setting which can only be changed by editing the 3d graphics card settings in Control Panel, as Latch said.

The DB Editor behaves much differently though. By default, it works as though VSync is on (again, this may be changed in Control Panel) but as soon as another 3d program starts running, the frame rate picks up to levels I would only expect if VSync had been forced off. FPSC and CShop 4 both trigger this rise, and surprisingly so does Windows Media Player (perhaps the visualisations require VSync off to run properly?)

Perhaps there’s a dll call or a hidden command in DBC itself that will temporarily disable VSync for that exe while it’s running. It has to be possible, because it’s been made an optional parameter in DBPro’;s “Set Display Mode” command (and I’ve already checked, it won’t work in DBC). Failing that, I think the greatest fps rise we’re going to get is from the modified version of Benjamin’s code snippet.

"I wish I was a spaceman, the fastest guy alive. I'd fly you round the universe, in Fireball XL5..."
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 15th Dec 2008 22:52 Edited at: 15th Dec 2008 23:03
This has to be a recent development with new hardware and probably windows software - because SYNC RATE 0 would return the fps DB was running at in the past.

Though it probably won't make any difference, try this program and see what the FPS is. Instead of SYNC, I use the point command. The point command is so slow on it's own because it calls an automatic sync as it's executed. Maybe it makes a difference? I also tried wait 0 instead of sync so see what that does:



Just curious, who's experience this problem and are you using a dual core processor and what version of Windows are you using?

Also in the setup.ini file in the DB.exe directory, there are two settings that may control how directx is redrawing the screen:

blitoverdraw=0
blitflipmode=1

Try changing the values of these between 0 and 1 based on the definitions of the settings:

; blitoverdraw : 0=normal / 1=Draw All 2D twice
; blitflipmode : 0=double videomem flip / 1=blit to video memory

And there has been mention of widows media player affecting things. Could it be that direct show is loaded and activated or perhaps the winmm.dll? How about trying to load and play an avi inside DB and see if that changes the FPS.

Does Cartography use OpenGL or DirectX? Maybe simply starting and closing either of those types of apps from within DB makes a difference (execute file etc)

Enjoy your day.
steve paul thomas
15
Years of Service
User Offline
Joined: 4th Nov 2008
Location: United Kingdom
Posted: 16th Dec 2008 13:51 Edited at: 16th Dec 2008 14:16
@Latch

Quote: "Just curious, who's experience this problem and are you using a dual core processor and what version of Windows are you using?"


My PC is getting on a bit now, but it works OK for what I want to do - so I'm not thinking of upgrading it just yet:

CPU: AMD Sempron 3000+, 1.80 Ghz (Not multiple core)
GFX: NVIDIA GeForce 6600
RAM: 2.00 GB
Windows : Windows Vista Home Premium SP1


I switched Vertical Sync off by using the NVIDIA Control Panel (within Windows Control Panel) and it seems to make no difference to frame rate whether VSync is on or off. It always caps at 60.

Latch's, Benjamin's and Robert The Robot's code all run at 60fps for me.



Quote: "Also in the setup.ini file in the DB.exe directory"


Had a look in the Dark Basic directory, mine is:



...but no sign of any ini file. My version of DB doesn't seem to use one?




Quote: "And there has been mention of widows media player affecting things"


Running Windows Media Player doesn't help mine at all.

Windows Media Player, song playing, visualisation off - max is 60fps.

Windows Media Player, song playing, visualisation on - max is 30-40fps.

It doesn't really bother me though.


@Robert The Robot

500fps?! You must have an insanely powerful graphics card, right?

I don't Adam and believe it!
Robert The Robot
17
Years of Service
User Offline
Joined: 8th Jan 2007
Location: Fireball XL5
Posted: 16th Dec 2008 16:48 Edited at: 16th Dec 2008 16:49
@Steve
Quote: "500fps?! You must have an insanely powerful graphics card, right?"

Don't think so. I'm pretty sure the real problem is that you're missing the ini file. Read on...

@Latch
You’re a genius!

I think I can say the problem’s solved, although I’d like to have it confirmed by someone like Irojo or Ashingda 27. I tried what you suggested about the Setup.ini file but – crucially – I never actually changed it from the default version I got when I installed DBC. The exe behaved as it did back in the editor, with other programs (e.g. Windows media player) causing the same hikes in screen fps as before.

I’ve attached a zip file containing two identical exes in separate folders. Try opening Windows media player, have it play an mp3 file, and then run the exes. I find that when I do this, the exe with the setup file runs at around 500fps, while the other one will cap at 60fps.


So, what’s going on? It’s triggered by two things:
1) The setup.ini file has the line blitflipmode=1. It’s this setting that makes DBC exes allow frame rate hikes when other programs are open. Specifying a value of 0 results in the 60fps lock – I’m assuming that 0 is the default value for all exes if no setup file is located.

2) The winmm dll has to be called. I found that calling “Load Music” and loading an mp3 caused the frame rate hike without the need for any other program to be open. Then, I went back to a code snippet of Latch’s that he wrote when I was struggling with loading midi music in DB1.13. This code snippet loads and plays a midi directly through the winmm dll, rather than with DBC’s own Music commands, and the same frame rate hike is observed.



So, in order to get higher frame rates, all you have to do is include the Setup.ini file in the attached zip and, at the top of your program, load any mp3.

"I wish I was a spaceman, the fastest guy alive. I'd fly you round the universe, in Fireball XL5..."

Attachments

Login to view attachments
steve paul thomas
15
Years of Service
User Offline
Joined: 4th Nov 2008
Location: United Kingdom
Posted: 16th Dec 2008 17:35 Edited at: 16th Dec 2008 18:14
I just dropped that .ini file that you supplied, into my DB directory and ran this code.



Doing that immediately gave me 290 FPS!?! Incredible, I take back my comment of:

Quote: "It doesn't really bother me though."




Nice work Latch and Robert The Robot.


Just a question (probably a silly one):


To take advantage of this superb speed boost for each program that
I make from now on, do I need to distribute the .ini file along with the .exe of my program?

Or does the .ini file only have to be in the DB.exe directory when you "compile" your program?

I don't Adam and believe it!
Robert The Robot
17
Years of Service
User Offline
Joined: 8th Jan 2007
Location: Fireball XL5
Posted: 16th Dec 2008 18:33 Edited at: 16th Dec 2008 18:35
You will need the Setup.ini file with every exe you build. Also, you'll need to either:
1)Have your exe load an mp3.
2)Open something like Windows Media Player when you run the exe.

That's where I went wrong last time, I was getting massive fps rises in the editor, but no improvements with standalone exes.

Just curious, does opening Windows Media player give you an even greater fps rise? I'm getting around 500fps when I have it open and playing an mp3...

"I wish I was a spaceman, the fastest guy alive. I'd fly you round the universe, in Fireball XL5..."
Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 16th Dec 2008 18:36
I'd just like to point out that it's not actually a speed boost, as you won't get any extra processing power (just the frame rate restriction removed).

Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 16th Dec 2008 20:50 Edited at: 16th Dec 2008 21:55
@Robert The Robot
Great detective work! I have a question about the ini file you supplied. I don't see
blitoverdraw=0

And I'm curious about these settings
vbcreate=4
vbusage=3

Shouldn't those be set to zero? I'm wondering if it's forcing the use of system memory over video memory. My ini settings have those set to zero. I've never experienced the frame cap problems (probably because of my older version of directx) and my frame rates on your examples are in the 650 - 670 range with and without external apps running.


Quote: "I'd just like to point out that it's not actually a speed boost, as you won't get any extra processing power (just the frame rate restriction removed)."


Do you mean you won't be squeezing any more juice out of the processor (which is true) or do you mean the program won't run faster or slower?
Maybe I am misunderstanding. I though setting the sync rate in DBC gave a general cap to how fast you wanted events to update. If the frame rate is limited to 60 fps, the program would never run at 200 fps...

Can someone run this test. It runs a 1000 iteration for next loop and times it. For each sync rate the length of time the loop executes increases. The values I get are 5 10 16 and 1000 .



Enjoy your day.
Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 16th Dec 2008 21:53
Quote: "Do you mean you won't be squeezing any more juice out of the processor (which is true) or do you mean the program won't run faster or slower?"

I'm saying that all it affects (I think) is the actual frame rate cap itself.

timmie124
16
Years of Service
User Offline
Joined: 29th Feb 2008
Location: some were in time
Posted: 16th Dec 2008 22:03
if your using AA of any type and any texture filters most games will lock the fps rate at 60 to prevent frame ripping and to keep the graphic card save

Robert The Robot
17
Years of Service
User Offline
Joined: 8th Jan 2007
Location: Fireball XL5
Posted: 17th Dec 2008 16:41 Edited at: 17th Dec 2008 16:42
@Latch
The ini file I had didn’t include a blitoverdraw setting at all, but when I added it there was no difference. vbcreate=4 and vbusage=3 should both be set to zero, you’re right, and it doesn’t seem to affect the frame rate. I’ve attached a corrected ini file – this time, DB will make use of video memory instead of system memory.

I tried running your code in the DB editor – I get 16 15 16 1000. If I open Internet explorer (it’s another program that increases the frame rate) I get 3 10 19 997.

@Benjamin
Quote: "I'd just like to point out that it's not actually a speed boost, as you won't get any extra processing power (just the frame rate restriction removed)."


With what we’ve been doing so far, you’re absolutely right – DBC still maxes out a processor (and at times I’m sure it’s breaking into my second core, as well). However, the code snippet you wrote to call the system Sleep function eases off the processor workload no end. This code:



runs at 170fps on my computer when Internet Explorer’s open, and my cpu averages at about 30-40% (60-80% for a single core). The windows commands I’ve added don’t actually make any difference, they’re just there so I can gain access to the cpu meter that sits on my desktop. Changing the above snippet so that we have “sync rate 60” and “Sleep(15)” gives me a steady 50fps and runs the cpu at 10-12% (about 25% for a single core).

Personally, I think this is the thing to aim for – maintain a refresh rate of 60fps, but the workload on the processor is now so light when it comes to drawing the scene, we have more time to spend on other code. Obviously, the more 3d in the scene the longer it will take to draw so we’ll have to adjust the Sleep time down accordingly, but it all seems to work.

The only thing bothering me at the moment is what timmie124 said about locking the screen fps to 60 to keep the graphics card safe – I’m wondering now if I’ve just shoved all the hard work from the cpu to the gpu!

"I wish I was a spaceman, the fastest guy alive. I'd fly you round the universe, in Fireball XL5..."

Attachments

Login to view attachments
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 17th Dec 2008 21:16
Quote: "The ini file I had didn’t include a blitoverdraw setting at all, but when I added it there was no difference. vbcreate=4 and vbusage=3 should both be set to zero, you’re right, and it doesn’t seem to affect the frame rate. I’ve attached a corrected ini file – this time, DB will make use of video memory instead of system memory"

All of the ini parameters should be included for the sake of whomever wishes to use it or try changing it. Also, be aware that the [STARTUP] section directly affects how a compiled exe behaves. If it's in windowed mode or full-screen mode or the window/display dimensions

Quote: "I tried running your code in the DB editor – I get 16 15 16 1000. If I open Internet explorer (it’s another program that increases the frame rate) I get 3 10 19 997."


Your first set of figures make no sense. Are those with the ini settings and loading the mp3? With these tests the time taken should be ((1/frame rate) * 1000). Your second test is closer what the results should be.

Quote: "Personally, I think this is the thing to aim for – maintain a refresh rate of 60fps"


You have to be careful here because there are different things going on. The sycronization in DBC suggest that porcessing is effected by the FPS. If you run those test again over a period of time and average them, they should come out as 5,10,16, and 1000 because that represents the ms taken for the specific sync rate. The FPS that is reported is more than a representation of video display timing. It is the rate at which things are done per iteration - that is, it's more of a timing benchmark. My monitor's refresh is 119hz which one could say is 119 FPS. The 60hz (FPS) limitation is being forced by Windows and the newer releases of DirectX as a lowest common denominator for monitor refresh.

I think it is very important to be able to run DBC at various frame rates (you could in the past it doesn't make sense that it's gone away!) . You can test what works and waht doesn't work and get a rough idea of what the work load is when you want to distribute your app or game.

Quote: "if your using AA of any type and any texture filters most games will lock the fps rate at 60 to prevent frame ripping and to keep the graphic card save"

Maybe... The graphcics card capabilities are the graphics card's capabilities. If you run within the specs of the card, everything should be fine. If you try to force the card to do something it can't, then your in for trouble. For years, CRT monitors have refresh rates in the 100s - and graphics cards potential have far exceeded that. LCD montiors don't behave the same as CRTs and might be some of the reasoning behind the operating system lock at 60 fps. If you use a refresh rate on the graphics card that is more than your monitor can handle, the monitor may be damaged, but I do not see DBC damaging the video card with any combination of it's command set - including Sync on, Sync Rate, and Sync.

Again, I believe DBC's sync rate is more directly related to the timing that things happen. That's why there is a SYNC RATE 0 which allows as much speed as your system can output for the task. The 60fps limit is a windows (and partnering with the graphics card drivers and directx) imposed limitation that shouldn't be necessary for DBC. DBC's highest sync rate is 1000 which in no way is a monitor refresh timing. If DBC was well programmed, then the maximum display timing is based on the graphics adapter settings. The Sync rate is applying to everything that is going on within the program and the FPS is an indicator of how fast things are happening.

Enjoy your day.
Robert The Robot
17
Years of Service
User Offline
Joined: 8th Jan 2007
Location: Fireball XL5
Posted: 19th Dec 2008 17:48
Hi Latch! Sorry I've been a day or so getting back to you, but it is getting rather close to Christmas

Quote: "16 15 16 1000 - Your first set of figures make no sense."

That would be because I had the screen refresh rate locking at 60fps - sorry! The second set was with the frame rate acceleration.

Quote: "The FPS that is reported is more than a representation of video display timing. It is the rate at which things are done per iteration "

If that's the case, then this is absolutely fanatastic! The frame rate hike means the entire program is running faster but DBC is still only maxing out one processor to do it! (well, it might be breaking into my second core every now and again, but it's hard for me to tell with the cpu meter I've got).

So, we can answer Irojo's original question - it is possible to lighten the workload on the cpu and maintain a high level of performance. Although actually, we are now getting an even higher level of performance than before!

Quote: "If you use a refresh rate on the graphics card that is more than your monitor can handle, the monitor may be damaged, but I do not see DBC damaging the video card with any combination of it's command set - including Sync on, Sync Rate, and Sync."

I'm afraid I'm still a little bothered, although DBpro runs at around 700fps on the same computer so maybe I shouldn't be worried at all.

Maybe I should return to the 60fps cap - after a fashion. Using Sync : Sleep(10), from Bejamin's system sleep function, I'm making the system lie idle for 600ms each second, but I'm still getting 60fps. So instead of taking (1000/60) = 16.67ms to call sync, it's now taking (400/60) = 6.67ms to call Sync.

I do apologise if I've missed the point on this, and it turns out that this kind of thing will send a graphics card into overdrive, but with this method my cpu is only hitting 40% instead of 100% (both values for a single core).

"I wish I was a spaceman, the fastest guy alive. I'd fly you round the universe, in Fireball XL5..."
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 19th Dec 2008 23:23
I think what's happening is the term FPS is being used to identify a lot of different things as a general term to benchmark performance. LCD monitors behave differently so applying a term like FPS is hard to catagorize. Following, however, is how I believe the Sync operations in DBC work:

Back in ancient times there was a beam that scanned across the screen of a monitor, called a raster beam. The raster beam is used to create a display on CRT. Each point that the raster beam hit would be illuminated, the beam turns off, then fires again at the next position. The beam would draw a row across the monitor and then move down to the next row and repeat the process for the whole screen. This would happen so fast that it seemed like there was a single image on the screen. Depending on the refresh rate of the monitor, the entire screen would be redrawn so many times per second. In terms of processing time, this refresh rate leaves a lot of time behind where nothing is happening. This is time the computer can be doing other things. So programmers tried to manage this time using interrupts. In between the beam drawings they could run pieces of code that gave the illusion of the computer performing multiple tasks at once. The computer never really performs faster, it just doesn't waste any time waiting around for the screen to be drawn - the small amount of time between each raster beam scan can be utilized. More programming can be run by a more powerful processor in this small gap of time increasing the output.

Now enter graphics. It's impossible to display more graphics than what can be drawn to the screen within an entire refresh. If you do, you'll get part of the old image combined with whatever new image you're trying to display - thus "tearing" can occur. So, if you're a smart programmer, and I think the makers of DBC are, the actual graphics will only be drawn at the maximum rate that is identified by the graphics adapter. DirectX has a lot of built in mechanisms to help with that. But, you still want maximum output and you don't want to wait around for the screen to be drawn before you draw your next image so you create a second drawing surface called a back buffer where the next image is being drawn while the first image is being displayed. As soon as the first image is done, you swap the back buffer with the front buffer and repeat the process.

I believe in DBC the swapping will only occur at the maximum rate of the monitor refresh - however, the processing that goes on (loops, math, conditionals, etc.) is synced or timed according to the sync rate which ties back to how much power your processor and graphics card can give you for the speed of operations. So your loops, your math, all that stuff runs according to the Sync Rate you supply. When you query DBC for the FPS, it gives you a value that represents the speed that things are happening. The most drawn frames of graphics information will be the maximum refresh rate that the monitor paired with what the graphics adapter is set to, but the processing is carried out as if the rate of display is what is reported by the Screen Fps() command.

Now enter the latest versions of Windows and DirectX. CRT monitors are on the way out if they aren't out for the most part already! The newer technologies don't behave exactly the same way. Integrated into DirectX are all these mechanisms for managing the frame rate in relation to the graphics adapter (the setting on the graphics card that tells the monitor how fast to refresh) based on older technologies. Will all of DirectX be rewritten? Eventually... But there's so much legacy stuff out there that a solution has to be applied to meet the needs of the current hardware and software, and maintain some kind of compatibility with legacy hardware and software. So an imposed 60 fps cap is applied - and in the case of DBC, it's not only limiting the refresh rate, but it ends up limiting the timing that processing takes place (because, I believe, of some new workings in Windows and DirectX).

I've run code in DBC that reports frame rates anywhere from 1 to 999 FPS and I've never observed tearing. I have observed that the programs perform faster or slower depending on the sync rate; and I have timed loops and have seen that they have faster or slower iterations. That is why I believe the video display is capped in DBC to the monitor refresh but the processing is limited to how much power your computer has relative to the Sync Rate. So if people want to continue to use DBC and want to distribute their apps and games, it's important to figure out how to make it perform best.

Enjoy your day.
Robert The Robot
17
Years of Service
User Offline
Joined: 8th Jan 2007
Location: Fireball XL5
Posted: 20th Dec 2008 18:12 Edited at: 20th Dec 2008 18:23
That was a fascinating read, and a lot of useful information. I've never really understood what goes on with all the graphics hardware, but now I'm getting a bit of a feel for it. You've given me a lot to think about!

I'd never quite realised what tearing was - I thought it was a kind of "double vision" effect I'd noticed when running a spinning cube at 500fps. It went so fast that I thought I was seeing about three of it, but that must just have been persistance of vision!

Could I just ask, though, would I be correct in thinking that by removing the 60fps cap and allowing 500fps or more (through the setup.ini file and the load mp3 commands) I'll be making each (now faster) Sync prepare a new image for the screen but behind the scenes, DirectX will only allow 60 of them to reach the monitor in each second?

"I wish I was a spaceman, the fastest guy alive. I'd fly you round the universe, in Fireball XL5..."
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 20th Dec 2008 21:48
Quote: "Could I just ask, though, would I be correct in thinking that by removing the 60fps cap and allowing 500fps or more (through the setup.ini file and the load mp3 commands) I'll be making each (now faster) Sync prepare a new image for the screen but behind the scenes, DirectX will only allow 60 of them to reach the monitor in each second?"


I am only responding based on my limited knowledge and observations and am by no means an expert or anywhere close to having expert knowledge in any of the discussed topics; including the workings of DBC, DirectX, Windows, and any mechanical devices that have been or will be mentioned. Further reading on these subjects is highly recommended and using any of the information I am submitting or have submitted in this post or within this thread you use at your own risk.

Now that the disclaimer is out of the way!

I highly doubt running DBC at a higher Sync rate will do anything but make your programs run faster. The Syncronization should be a program timing mechanism and not a monitor refresh rate determiner. If the drawing of the graphics was faster than the screen actually could be redrawn then you might experience something that looks like flicking, or maybe the top half of the screen not lining up with the bottom half. I

I think the cap can be removed as it was non-existant in the past. The only problem could be if somehow the new DirectX tries to change your video adapter frequency - which doesn't really make sense.

Quote: "It went so fast that I thought I was seeing about three of it, but that must just have been persistance of vision!"


Slow down the rate at which the cube rotates. This example runs at about 783 FPS on my machine but the cube rotates nice and slow and smooth with no "motion blur."



Enjoy your day.

Login to post a reply

Server time is: 2024-03-29 12:27:22
Your offset time is: 2024-03-29 12:27:22