Aces High Bulletin Board
Help and Support Forums => Technical Support => Topic started by: airhog99 on April 18, 2007, 09:15:39 PM
-
I have changed device drivers and even mucked with the hardware due to frequent lockups in AH. They seemed to start after I upgraded my computer (OS and HW), so the suspicion was naturally on the new stuff.
Now I have finally tracked down the problem to the video setting for capping frames per second! If I set it to max 60 fps, then a lockup will happen soon or withing 15 minutes for sure. If I set it to "unlimited" I can play for hours, and AH seems rock-solid. (Unlimited seems to cap at 60 fps anyway for some reason.)
If Hitech Creations can't reproduce this I will be glad to produce more detailed information on my system. Shortly, I have:
AMD Dual Core at 2.2 GHz. 1 GB 800 MHz RAM.
GeForce 6800GT PCIe, 256MB.
nVidia 430 mobo circuits.
-
seems like tech support is a bit limited here. Guess this is just community run and possibly there is another official method?
-
Yeah, I'll look into it. This post might help someone though.
-
The cap is there for video cards which have a problem with tearing (not honoring v-sync). Iti s optional to use. If your card does not honor v-sync and it is having a problem when using this option, then just send in a DXDIAG output with a description of the video settings using in the game.
As per the help documentation:
"The option to limit framerate is recommended if you are seeing blue flashes while running Aces High II or if you are experiencing numerous lockups."
If the lockups continue, then there are usually other issues at hand. But that is a guess without seeing the DXDIAG output.
Originally posted by Sincraft
seems like tech support is a bit limited here. Guess this is just community run and possibly there is another official method?
There is phone and E-mail support. I would say the bulletin board has the lowest priority, but is a good source for reaching out to the community.
-
Originally posted by Skuzzy
The cap is there for video cards which have a problem with tearing (not honoring v-sync). Iti s optional to use. If your card does not honor v-sync and it is having a problem when using this option, then just send in a DXDIAG output with a description of the video settings using in the game.
As per the help documentation:
"The option to limit framerate is recommended if you are seeing blue flashes while running Aces High II or if you are experiencing numerous lockups."
Ehh.. And in my case the fps-limiter caused lockups..
I initially set the limit in order to save some CPU cycles for other things running on the machine. It is bizarre that a fps-limit should cause lockups. (fps-limiting in Flightsim X works just fine, BTW.)
Originally posted by Skuzzy
If the lockups continue, then there are usually other issues at hand. But that is a guess without seeing the DXDIAG output.
There is phone and E-mail support. I would say the bulletin board has the lowest priority, but is a good source for reaching out to the community.
I haven't had a single lockup since I changed to "Unlimited" fps. With fps set to 60 I sometimes get a lockup even as I exit the settings page. ("Lockup" normally means the process stops responding. Occasionally it managed to bring down the machine.)
-
9 hours for a response is pretty good in my opinion.
Complaining 4 minutes after a post is a little early, don't you think?
After all, you posted after 10pm.
Also, you used this setting for other things running on your machine. Another 'don't do' while running Aces High.
And per Skuzzy's post, you used the frame limiter for what it was not intended for. Why would you even use it if your frame rate was at 60 when you used the unlimited setting?
-
The frame rate limiter will not free any CPU cycles. The game still does the same amount of work.
-
Originally posted by airhog99
Ehh.. And in my case the fps-limiter caused lockups..
I initially set the limit in order to save some CPU cycles for other things running on the machine. It is bizarre that a fps-limit should cause lockups. (fps-limiting in Flightsim X works just fine, BTW.)
I haven't had a single lockup since I changed to "Unlimited" fps. With fps set to 60 I sometimes get a lockup even as I exit the settings page. ("Lockup" normally means the process stops responding. Occasionally it managed to bring down the machine.)
I'm curious how you know what actually caused your lockup. The fact that you think your saving CPU cycles indicates a less then stellar grasp of the ineractions between the game your CPU and your GPU. It's certainly possible that AH has conflicts with other programs and is locking up. Many folks use FS autostart to limit processes while playing AH.
Some VC drivers work better with AH then others. Skuzzy has gone out of his way to provide detailed recommendations on settings & drivers for various VC's and CPU/memory combo's. My 1st question would be are you running AH with the "proper" VC drivers and at settings appropriate for your computer?
-
Try looking at the posters' IDs before you jump in.
Try not to worry about WHY I use an existing feature in the program.
Originally posted by fuzeman
9 hours for a response is pretty good in my opinion.
Complaining 4 minutes after a post is a little early, don't you think?
After all, you posted after 10pm.
Also, you used this setting for other things running on your machine. Another 'don't do' while running Aces High.
And per Skuzzy's post, you used the frame limiter for what it was not intended for. Why would you even use it if your frame rate was at 60 when you used the unlimited setting?
-
Originally posted by humble
I'm curious how you know what actually caused your lockup. The fact that you think your saving CPU cycles indicates a less then stellar grasp of the ineractions between the game your CPU and your GPU. It's certainly possible that AH has conflicts with other programs and is locking up. Many folks use FS autostart to limit processes while playing AH.
Some VC drivers work better with AH then others. Skuzzy has gone out of his way to provide detailed recommendations on settings & drivers for various VC's and CPU/memory combo's. My 1st question would be are you running AH with the "proper" VC drivers and at settings appropriate for your computer?
I'm curious too.
Why wouldn't a lower frame rate potentially save CPU cycles? Please explain in detail, as my computer engineering education is getting older by the day.
I have killed and uninstalled a lot of junk already. I only run a music server in the background, and it seems to cause no problems.
Yes, som drivers are worse than others, which is why I have tried four different revisions. Turns out they all worked the same (no difference when it comes to lockup) and the latest revision works just fine.
-
The game still has to calculate all the information, which makes up a frame of data, regardless if it is displayed or not. You simply cannot stop doing real-time calculations.
Unpredictable results have been known to occur when running other active programs in the background of a DirectX application. DirectX was designed to use 100% of the CPU.
-
Originally posted by Skuzzy
The game still has to calculate all the information, which makes up a frame of data, regardless if it is displayed or not. You simply cannot stop doing real-time calculations.
Unpredictable results have been known to occur when running other active programs in the background of a DirectX application. DirectX was designed to use 100% of the CPU.
So what is the internal time resolution in that case?
If what you say is correct, then there must be an optimal frame rate that exactly corresponds to the internal time resolution (assuming the graphics and bus can handle the FPS).
I find it a bit hard to believe there are no display output related calculations that are fps related, but if you say so...
-
Originally posted by Skuzzy
The frame rate limiter will not free any CPU cycles. The game still does the same amount of work.
Dude, I think you are flat-out smoking crack on this one. Limiting the frame rate will seriously reduce CPU use, if you are running the game at a high (well over sync rate) frame rate when unlimitted. There's a ton of work that gets done on the CPU while renderring a frame that will happen 80 times per second instead of 200 times.
Check it with the task manager (when not Atl-Tabbed, when which y'all should set a frame rate cap, so that it doesn't consume all CPU, btw.)
Or show me a tool that shows otherwise.
Or just go ask your boss.
-
Originally posted by fuzeman
And per Skuzzy's post, you used the frame limiter for what it was not intended for. Why would you even use it if your frame rate was at 60 when you used the unlimited setting?
The only reasons that I've heard of NOT using vertical-sync is for benchmarking, and because some early games actually ran the physics differerently based on frame rate (early Quakes), which could give a player an advantage. Otherwise, it just causes artifacts, and uses unneccessary CPU cycles.
-
My understanding (generically) is that the current generation of GPU's handle a significant amount of these issues on the VC. The application is being run on the CPU. The rendering is being done on the GPU. AH is historically a CPU dependent application, the bottleneck in "performance" comes at the CPU. Modern day GPU's are not utilized at anything near full potential (in most cases). There are in fact programs looking to offload more and more true calculations from the CPU to GPU (one premise in an odd way of the Sony cell). One example would be a falling plane part. The game has to calculate the fluttering control surface (you can watch it all the way down till it hits the ground BTW) for all players. You wont see it unless you orient your in game view the same way....but the math still runs. Now your "view" dictates what your GPU renders and your FR dictates how often it renders....but these are primarily GPU cycles. The entire purpose of the memory and computing horsepower {VC} is to transfer the burden of rendering from the CPU to the GPU. The GPU itself free's up the CPU cycles. A current generation card is often left waiting for the CPU....it renders faster then the CPU calculates. Your "issues" have nothing to do with CPU cycles (or GPU cycles) but are related to the interaction of various proccesses running on your computer.
-
Originally posted by SkyGnome
The only reasons that I've heard of NOT using vertical-sync is for benchmarking, and because some early games actually ran the physics differerently based on frame rate (early Quakes), which could give a player an advantage. Otherwise, it just causes artifacts, and uses unneccessary CPU cycles.
Your not "using" CPU cycles...just GPU cycles. The game is chugging away regardless....from everything I can gleen AH is still very much a CPU dependent game...it will use all the CPU resources you have.....regardless of what you think your GPU is doing. Your GPU is not generating CPU cycles....its accepting output generated in real time BY the CPU. 99% of the time a later generation is waiting on a CPU output...thats why framerate in AH is more CPU dependent then VC dependent. It's capped by the CPU's ability to crunch all the numbers....not the GPU's ability to render the output. Anything that effects the effeciency of the CPU limits "thruput". The reason for V-sync is simply so your VC doesnt render frames your monitor cant display. If your VC renders 85 fps and your LCD can only display 60 then your dropping 25 fps of info (hit sprites etc) so you may appear to ghost shots or the other plane may appear to "miniwarp". This has no effect on your CPU cycles one way or the other. The CPU still calculates all the variables realtime regardless of what your VC configuration displays....
-
Originally posted by humble
Your not "using" CPU cycles...just GPU cycles. The game is chugging away regardless....from everything I can gleen AH is still very much a CPU dependent game...it will use all the CPU resources you have.....regardless of what you think your GPU is doing. Your GPU is not generating CPU cycles....its accepting output generated in real time BY the CPU. 99% of the time a later generation is waiting on a CPU output...thats why framerate in AH is more CPU dependent then VC dependent. It's capped by the CPU's ability to crunch all the numbers....not the GPU's ability to render the output. Anything that effects the effeciency of the CPU limits "thruput". The reason for V-sync is simply so your VC doesnt render frames your monitor cant display. If your VC renders 85 fps and your LCD can only display 60 then your dropping 25 fps of info (hit sprites etc) so you may appear to ghost shots or the other plane may appear to "miniwarp". This has no effect on your CPU cycles one way or the other. The CPU still calculates all the variables realtime regardless of what your VC configuration displays....
Open your vid card control panel, select force vsync.
Pull up task manager, go to performance tab.
Run AH. Sit in the tower with clipboard off screen. Wait a bit.
Close AH, note level of CPU use on history graph.
Go to vid control panel, force no vsync.
Run AH again, etc.
As long as there's a decent delta between your sync'd and unsync'd frame rate, it's very clear from this that using vsync lets the CPU sleep a bunch.
It also makes sense if you actually know how this stuff works, and have actually written this sort of software, instead of just read 'net babble.
-
(http://www.az-dsl.com/snaphook/vsync%20off.jpg)
(http://www.az-dsl.com/snaphook/vsync%20on.jpg)
Just as I expected there is no difference in CPU usage with V-sync on or off. In a properly configured system there wont be. If your getting anything different you have misconfigured your system.
I agree, it makes sense if you actually DO KNOW how this stuff works. V-sync has no bearing on CPU demand (at least as far as AH goes). I ran AH offline in the tower while doing this. That provides for a constant demand level...if you run it online you will get random variations due to enviornmental factors.
-
If I need to know something about computers, I look to Skuzzy's opinion, if I need to know something about airplanes, I look to Widewing's opinion. No need to question eithers' conclusions. (If ya need to know ANYthing about ANYthing else, ask my wife, who apparently DOEs know it all)
-
Originally posted by bj229r
If I need to know something about computers, I look to Skuzzy's opinion, if I need to know something about airplanes, I look to Widewing's opinion. No need to question eithers' conclusions. (If ya need to know ANYthing about ANYthing else, ask my wife, who apparently DOEs know it all)
I'm always amazed at folks arguing this stuuf with the guys who develop the game. On a broader basis however the reality is that the old "if a bear $%!^'s in the woods...." line means that the game modeled the smell even if no video card was around to "hear" it. The game (any similiar game) handles a tremendous volume of distinct objects. when a guy in a windmill fires of a round in TT its modeled regardless of if you can "see" it in your particular view orientation. Its trajectory is modeled and its impact is modeled and its crater is modeled...regardless of what your VC does. All your VC does is render that portion that you "see"....since you always have a view orientation that demand is relatively constant. The data stream relevent to that view is real time....not based on what you render. In effect the CPU is generating far more then you ever use.
The biggest "issue" right now is that the raw processing power of the GPU exceeds many CPU's and developers are trying to offload workload to the GPU from the CPU. The thought that your GPU is somehow "loading" your CPU is fundementally wrong....
-
Originally posted by bj229r
If I need to know something about computers, I look to Skuzzy's opinion, if I need to know something about airplanes, I look to Widewing's opinion. No need to question eithers' conclusions. (If ya need to know ANYthing about ANYthing else, ask my wife, who apparently DOEs know it all)
Ain't that the truth....amen bro:aok
And I thought only my wife knew everything:furious :furious :furious
-
after the last update I have been having alot of lock-up's during the day, now to the point that I can not play in the day time. At night no problem.
My system had been runing great with everything max out.
-
Originally posted by humble
I'm always amazed at folks arguing this stuuf with the guys who develop the game.
I only argue with them when they are flat-out wrong. ;) And frankly, from reading his posts for several years, I really don't think Skuzzy has a very broad computer science or engineering background, or that he actually writes rendering code, at the very least. This doesn't make him a bad resource on how to get AH running for you, of course.
Your screenies are unreadable due to your dual CPUs making the sum of the two CPUs difficult to interpret (and you can't use the percentage marker on the left, as when AH is alt-tabbed, it goes wild and pegs the CPU - which I wish they'd fix.)
Here's mine. #1 is AH with Vsync on, pegged at 85fps, #2 is with vsync off, running around 120-150fps. I also booted with /onecpu so that the graphs are readable. Folks who doubt, try it for yourself - just make sure that you are running at settings that will allow a higher framerate with vsync off.
(http://alf-learning.org/local/EQ/taskmgr.jpg)
P.S. For a guy with "humble" as his name, you sure aren't! ;)
-
I run dual headed and can see my task manager while I'm using AH. My CPU load usually howers around 20-30% while I'm running the graphics at 60 fps. I know the graphics card can handle at least 120 fps (since it occasionally went up to that when the timing was screwed with Win2k and dual core).
This means that AH is neither CPU-bound, nor GPU-bound. AH is a relatively light application compared to many 3D programs nowdays.
As to why the CPU should be at 100% for things to be right, as someone claimed before, I just don't follow the reasoning behind that.
Run it on a slow CPU with a good graphics card, and it will be CPU-bound.
Run it on a fast CPU with a poor graphics card, and it will be GPU-bound.
Run it on a fast CPU with a good graphics card, and there will be free cycles in both processors.
-
I just stumbled over this as I was googling for how to set vsync in the new driver:
Selecting Vertical Sync (vsync) from the NVIDIA Control Panel does not affect DirectX applications.
Due to architectural changes in the new Windows Vista Window Display Driver Model (WDDM), the graphics driver can no longer disable vsync from its own driver or Control Panel. Selecting this option from the NVIDIA Control Panel will have no affect on DirectX applications.
http://www.nvidia.com/object/vista_driver_news_022207.html
So if you use Vista and change vsync in the nvidia driver you won't be doing anything at all, it seems. (I use XP.)
-
You can see the same type of varience (just look at CPU #2) in my system. No question that turning v-sync off creates a "table top" effect on CPU usage. However that doesnt change really change the base CPU demand IMO.
If we take 3 systems...
on a lower end system the graph will "flatline" either way since the CPU is running maxed out either way.
on your graph the CPU only tops out 20-25% of the time with V sync on, 100% with V-sync off....
on mine the system doesnt ever "top out" but overall thruput per cycle is higher with V-sync off...
my cpu line....
(http://www.az-dsl.com/snaphook/dual%20view.jpg)
tried to duplicate what you had...
I havent played with other features to see what CPU varience is (i have everything at max) at default or various AA/AF settings high res...
This is the 1st system i've built that never maxes out running AH...I dont even stop anything and I can run anti virus etc in background with no performance hit. I have no arguement that additional GPU requests require more "work" per CPU cycles. However that work is minimal compared to the "base load". I dont feel your "saving CPU cycles" ever with AH. Is the workoad per cycle variable....sure. Does the configuration of your system and quality of your GPU effect the CPU workload....sure it does. I simply dont agree that your saving CPU cycles. No question your graph clearly shows a higher workload per cycle....in fact it looks like your CPU tops out 20-25% of the time with V-sync on and 100% with it off....
So with V sync off it certainly appears your system is CPU bottlenecked {with 1 processor running}...
-
Oh, I found the setting for vsync in the new nvidia settings stuff, and with vsync off I get around 80-90 fps and the CPU howers around 50%. With vsync on I get 60 fps and the CPU howers around 30%. A significant difference, especially if you run a single core CPU system where one setting might eat all cycles wheras the other setting might leave 40% free for other things.)
I guess my 6800 GT, with every possible quality setting maxed, only does about 90 fps. I did notice tearing when running without vsync, and see no reason to not sync.
-
humble,
What is "workload per cycle"?
P.S: Now AH has started to go unresponsive after Alt-Tab'ing out of it..
So anoying...
-
Airhogg,
I'm not going to try and be what I'm not. So I'll try and explain my understanding...
A CPU can process a certain number of instruction sets. Anytime a CPU tops out at 100% its reached apoint that it is not handling the number of tasks it gets...so the process is CPU bottlenecked. When you reach that point you require more CPU cycles to acomplish a given task. Variable CPU workload under 100% simply means the CPU isnt being taxed to its maximim capacity...
The game still has to calculate all the information, which makes up a frame of data, regardless if it is displayed or not. You simply cannot stop doing real-time calculations
This is skuzzy's statement above, the CPU use by AH is constant regardless of framerate. Now video cards may or may not use CPU cycles to process frames. Each generation of GPU is more powerful and more and more is done on the VC. This is also specific (my understanding) to how the developer writes the code. The biggest potential benifit to a multicore CPU like the cell is that it can have anunlimited number (in theory) of proceccing elements. As it stands it has 1 true CPU and 8 processors that allow a program to assign tasks to each.
Your not saving anything specific to AH with V sync on or off. If you look at sky's system you can clearly see his CPU is capped out with V sync off...so no question he's putting a higher demand on the CPU....but that is coming from his VC....not from AH. (I have no clue what VC/drivers). I'm running a 7900GT with the recommended 84.66 drivers. I agree that v synch off tops your system off at its highest useage level (you can see he's also capped with it on...just not all the time). I dont think V-sync adds any additional overhead. My system never runs higher due to v-snyc...but it does run with a similiar table top....so no question even my GPU is using the CPU. Look at the #2 CPU and you'll see my "usage" with V-sync off is averaging 80% with little drop...on the v-sync on it tops at 80% but spikes down to 60%...
Your problem occures with V-sync on, which according to skygnome is less intensive. From my perspective your CPU's capacity is binary...it either can or cannot handle the load...anything less then 100% gives you seemless operation....once you bottleneck your system it cant handle the load and things wait in the que....
In every system I've ever had before AH ran at 99% CPU all the time. The goal was to stop as many other processes as possible so AH would process as much as it could in a CPU cycle.
-
Most people really don't know what the heck is going on inside their computers, and I've seen a lot of weird statements here and elsewhere. Statement's that are more akin to old wife's tales than facts.
Now, when it comes to a "less than stellar grasp"...
-
I have a EE and have been practicing it for over 30 years. Let's just stop the personal attacks. They are not productive. None of you know how the game actuially works. And I am not going to go into details about that, for obvious reasons. I have also written a rendering engine as well.
As far as the game goes, there is no difference between locking at 60FPS or running with vsync enabled or disabled. The game loop which renders each frame does the the same thing in all three circumstances. However, DirectX can stall the game loop by not returning from a draw call. This only happens in a stall condition inside of DirectX or the video card driver and it is rare for that to happen.
The only difference is the video card driver and the DirectX stack. Yes, I did not speak to those components. Those components can/will effect the amount of CPU time used based on the video configuration. I was in error in the way I presented the data earlier.
The video rendering is not done by the game, unless software vertex processing is chosen.
-
I only argue with them when they are flat-out wrong. And frankly, from reading his posts for several years, I really don't think Skuzzy has a very broad computer science or engineering background, or that he actually writes rendering code, at the very least. This doesn't make him a bad resource on how to get AH running for you, of course.
Lol , obviously you have an axe to grind with skuzzy,but what i cant understand is how someone on the outside of HTC can tell someone on the inside of HTC that they are wrong when it come's to THEIR own product? Who are you to queston Skuzzy's background ? The only thing you have accomplished in this thread has been to show how arrogant you are .
-
Originally posted by 38ruk
Lol , obviously you have an axe to grind with skuzzy,but what i cant understand is how someone on the outside of HTC can tell someone on the inside of HTC that they are wrong when it come's to THEIR own product? Who are you to queston Skuzzy's background ? The only thing you have accomplished in this thread has been to show how arrogant you are .
I don't have to have built something to understand how some aspects of it work - and this thread is an obvious confirmation of that.
In this case, Skuzzy made a false statement that was potentially relevent to the problem of the initial thread poster with the lockup problem, and refused to be corrected. I think that people who are in a position that leads others to believe what they say without question have a real obligation to be careful that what they say is correct. Mistakes happen, but those people also need to recognize that and double check accordingly when the facts don't agree with their statements.
As to why I'm a banana about it, it's partly that I'm a banana, and partly my own devious designs. ;)
As to the lockups, one might want to make sure that the voltages out of the PSU and those indicated by the motherboard monitor are stable and within spec both under load and idle. A problem with regulation somewhere could cause a problem that doesn't show up under full load. It could be any number of other unrelated things though - these are toughies.
-
Originally posted by SkyGnome
As to why I'm a banana about it, it's partly that I'm a banana...
If I got anything out of this thread, I did get that ..
-
Originally posted by Skuzzy
However, DirectX can stall the game loop by not returning from a draw call. This only happens in a stall condition inside of DirectX or the video card driver and it is rare for that to happen.
With vsync on (and with frame-rate pegged against it), this "rare" "stall condition" happens every frame, until the monitor is done presenting the current frame.
-
Actually it is pretty rare, but I guess that is a somewhat subjective term. What you visually see is no where near the granularity of what can happen. If the game was consistently stalled, the video output would consist of small jitters or non-linear motions. This would happen as the time between each fram draw would be very inconsistent. Remember, the game does run triple buffered, which helps alleviate this situation.
And in some driver/video cards, they actually dump a buffer in favor of a new one to reduce the chance of stalling.
And in a worse case scenario, such as a very slow video card, with a very fast CPU, it would happen more often.
By the way, I did not make a false statement, per se. But I did fail to take into account the DX stack and video card driver in my previous statements, which I have already corrected.
If you want to drive that home, then feel free to. I make mistakes from time to time. I do my best to be accurate, but I am not perfect. I do not need to be insulted in order to correct my mistakes.
-
Skuzzy,
you didnt make any error at all. I had absolutely no problem understanding what you ment (and I'm sure 99% didn't). Basically the amount of "work" required by AH is constant. Any additional overhead {for rendering}required is specific to the computer in question. Differences in configuration & components will effect what amount (if any) additional overhead is placed on the CPU.
My broader question is pretty simple. A CPU cycle is like an airplane seat...its filled or its not. There is no inherent benifit to an "open seat"....so marginal variations in workload do not effect "total thruput"....the system is in effect bottlenecked or its not. Looking at either SkyGnomes CPU usage chart or mine you can establish a "maximum demand"...in both graphs that maximum is identical with V sync on or off...its not ever higher specifically due to v sync. I certainly agree that Sky's system "tabletops"...but he either way his max demand is the same.
So my perspective is that the "workload" required to calculate and render a frame is constant in any system {for that system}. Enabling or disabling V-sync wont change that. So the basic demand placed on the CPU does not go up. In a system that is misconfigured or less efficient or overloaded you may get a temporary break in demand...but your maximum demand is unchanged.
Basically all this is doing is proving all the time and effort you spend in providing "best configuration" 411 is well spent in providing help in "streamlining" a system so a noob like me can run my box with none of the issues Skygnome seems to have.
I guess I just dont see how you would view any GPU specific rendering demands as an AH issue. I wonder just how different these figures would be between various drivers and the same VC?
-
Originally posted by Skuzzy
Actually it is pretty rare, but I guess that is a somewhat subjective term. What you visually see is no where near the granularity of what can happen. If the game was consistently stalled, the video output would consist of small jitters or non-linear motions. This would happen as the time between each fram draw would be very inconsistent. Remember, the game does run triple buffered, which helps alleviate this situation.
And in some driver/video cards, they actually dump a buffer in favor of a new one to reduce the chance of stalling.
And in a worse case scenario, such as a very slow video card, with a very fast CPU, it would happen more often.
By the way, I did not make a false statement, per se. But I did fail to take into account the DX stack and video card driver in my previous statements, which I have already corrected.
If you want to drive that home, then feel free to. I make mistakes from time to time. I do my best to be accurate, but I am not perfect. I do not need to be insulted in order to correct my mistakes.
Could you please expand on what "stalled" means in your explanation. Would it freeze up the video output and stop any processing in it's tracks (like I and others have experienced), or are you talking about something else?
-
Humble. What is setting your CPU to 50% at idle? If I have 4% at idle I'm into shutting off start up programs. If 50% is idle CPU you nedd to shut down some background programs, badly.
-
AH was still running, what your seeing is the CPU use specific to rendering the frames. With my system the additional overhead is "almost" identical. Open the task manager and then run AH sitting in the tower...minimize it and you'll see your CPU load without rendering and with. I'm on another computer I'm reconfiguring, I'll post my CPU use from the other box in a sec here....
(http://www.az-dsl.com/snaphook/AH%20profile.jpg)
The "flat line" at roughly 50% is AH minimized. The preceding higher platue is with the rendering load. My "arguement" with Skygnome is in a higher end system properly configured v-sync on or off should not effect that higher load level by more then a fractional %......
-
Humble, I did make a mistake. I stated an absolute without properly mentioning the other variables in the equation. Not a good thing to do as you end up wrong more than you are right. I worded that very poorly.
We have little to no control over DirectX and the video card driver/hardware. They are going to do what they do when they want to do it. We have three layers of software under us. DirectX, the video card driver, and the video card firmware. The CPU is involved in driving all but the video card firmware.
-
OK........
Now I'm totally confused....
(http://www.az-dsl.com/snaphook/AHoldsystem.jpg)
This the box I'm reconfiguring. It's a compaqI was using but it had "issues" related to my Nvidia 7900 on its ATI chipset (onboard VC). This box uses the onboard card so I'm guessing its using hardware vertexing. I'd still have expected some level of CPU use seperate from rendering...here it drops back to the floor when U minimize AH.......
-
When you minimize AH, we stop rendering altogether. So you lose the CPU cycles DX and the video card driver was using up during the render time.
Everything else is still being done. But if you are offline when you are doing this, there just is not much for the game to do.
-
ahhh....
Since I didnt load the patch on this box I loaded it up offline....was scratching my head a bit...so the base footprint is actually very low. It's all the online "realtime" load that creates the overhead....makes sense once you turn the lightbulb on for me:)....