Printable View
Yea, I worte a program in VC++ 6.0 and it works fine on one of my XP computers (as in it uses 100% of the CPU when running), but when I run it on another computer at school it is only given about 4% of the CPU and runs really slowly... How do I make it use all of the processing power of the computer?
You mean waste CPU cycles? I really really doubt your program is efficiently using the entire processor. It's likely just wasting CPU cycles inefficiently. What's the point of hogging all of the processor time? I really doubt your program needs the full CPU to function.
Quzah.
OS on school computer?
Do you have Administrator priviges on school computer?
What does program do? Why do you want all the processing power?
Welcome.
gg
OS at school is XP, I have full administrative powers, I am writing an OpenGL program in a Win32 application. I want to use the full processor because the way I am currently setting the program up, it is too slow when it is only using 4% of the processor due to the fact I wrote it on the other computer, and I am trying to make a semi-realistic solar physics program and speeding up the rate at which i increment my variables not only changes the proportions, but also reduces the accuracy.
Another note: I checked the school computers and it is not limiting the amount of CPU usage, it is limiting the amount of times my game loop actually occurs. I checked it by adding an increasingly large loop that does nothing while watching the CPU usage. The program does not slow down at all with a loop of 1 million itteration running because the computer only sets the amount of times the game loop occurs... I do not want this because if I wanted to cap anything it would be the calculations and not the frame rate (after all, what is a graphical simulation without nice graphics?)
In Windows, there are process and thread priorities that dictate how much CPU time a thread recieves. However, it is highly unlikely that the other 96% of the CPU is being used by higher priority threads. Can you see where the other 96% of the CPU is being used, if any (System Idle Process)? Also, there's a huge difference between CPU ussage and frame rate. Are you measuring the frame rate? How does the frame rate differ on each PC? What are the stats on each PC?
gg
There are several ways. First you do not need to slow down the computer. You need to base your frame updates on elapsed time. This takes into account the time it took to render the frame as well as the speed of the current computer.
You can use timeGetTime() which has its flaws in accuracy or QueryPerformanceCounter() in the API that is extremely accurate.
You should run timeDeltaPhysics at a pre-determined rate but you don't have to. You don't have to include 2 different time deltas but it is normally good to separate any physics frame calculations from actual graphics update calculations.Code:void Render(float timeDeltaFrame,float timeDeltaPhysics)
{
PhysicsEngine.Update(timeDeltaPhysics);
//Update everything else on timeDeltaFrame
}
Or it could be that you have a crappy video card at school and the CPU is waiting on the GPU to process the geometry...
The 100% CPU is using software rendering while the 4% CPU has the benefit of 3D hardware to do the work.
(an interesting thought)
gg
Doesn't matter. They should run at the desired framerate regardless of speed, software, hardware, etc.
That's your job to get it to run at the same speed regardless of platform.
You're pretty funny. So Doom 3 should run at the same speed on an AMD K6-200 as it does on a Athlon 64 3800? Care to change your statement, because noone writes software like what you describe. That's why there are "minimum system requirements". Furthermore, you've never played a PC game, or what? No games run "at the desired framerate regardless of speed, software, hardware, etc". That's just an absurd statement.Quote:
Originally Posted by Bubba
Quzah.
Incorrect quzah. You pick a baseline system requirement and that is what you shoot for. The FPS that I shoot for on lowest system is normally 30. If the computer in question cannot run your code at 30 FPS in any way shape or form then yes it does not meet the minimum specs. But frame rates for graphics and frames for physics are two different things. No matter which system you are on, during 1 second or 1 frame all objects should move the same amount of distance. If they don't you will get sync problems especially online. If you are not coding for multiplayer this might not be an issue but everything should still be based on elapsed time. And yes I have a library of over 300 games and have been gaming since the 8088 processor. I play online games all the time and when I'm not coding I'm gaming. Don't act as if I'm a newbie at the gaming world because I'm not. A little common courtesy here would be nice.Quote:
You're pretty funny. So Doom 3 should run at the same speed on an AMD K6-200 as it does on a Athlon 64 3800? Care to change your statement, because noone writes software like what you describe. That's why there are "minimum system requirements". Furthermore, you've never played a PC game, or what? No games run "at the desired framerate regardless of speed, software, hardware, etc". That's just an absurd statement.
Quzah.
For instance if I create a game it might really smoke on one computer and really trudge on another. If it trudges too bad then I would say that computer does not meet my targeted system specs. However if it trudges on a top end system then its obviously my code or my algos. Essentially you shoot for the baseline system that you think everyone out there has access to. Or you could shoot for extremely high specs like DOOM 3 or some newer FPS's. Regardless though the actual gameplay should run at the same speed regardless of the frame rate. I guess that is what I was referring to.
Older games that did not take clock cycles into account will be so fast on newer systems they will be unplayable. But if they did take into account clock cycles and they were shooting for 30 FPS as their cap, then that game should run on every system at a cap of 30 frames per second. The cap should not be exceeded or the game might run at well over 200 FPS, the physics/motion portions would be so fast as to be uncontrollable, and you couldn't play it. Some older games suffered from this. But games like Dynamix's simulations and Sierra simulations should (if they could run in XP) run at the same speed as a top end system running the same game.
So I guess I'm talking more about a step up to a faster system than a step down. Your code should run the same speed as in one should not be fifty times faster on a computer that is fifty times faster. I'm looking into multiplayer code and syncing the systems when there are about ten billion computer configs out there is a tough issue - one which often causes lag for the fast systems since they must sync with slower systems, or slower systems must sync with fast systems on slow connections.
But in this case and for this thread a simple time based approach will work.
Here is a small example.
Note that this does not implement a cap on the framerate. This only computes the current framerate. Simply pass your elapsed time or timeDelta (change in time over one frame) to this function and it will calculate frames per second. From that then you can calculate how to cap your FPS to a certain value. When you do this your code should never run faster than the frame cap depending on the accuracy of the timer. It might never reach your frame cap, but it will never go over it. This is a good way to time sync your code. So now when that guy walks across the screen on a Pentium 52000 IA1024 uber super computer he will move the same speed as he did when he moved on your old Pentium 4 2 GHz processor. Now you can see though why you should use a sep FPS for physics and graphics. You want graphics as fast as possible, but you want physics to be the same on all systems. So basically on faster systems you are updating the screen more each second, but the actual graphical data has not changed.Code:unsigned long FrameCounter;
float ElapsedTime;
float FPS;
void CalculateFPS(float timeDelta)
{
FrameCounter++;
ElapsedTime+=timeDelta;
if (ElapsedTime>=1.0f)
{
FPS=(float)FrameCnt/ElapsedTime;
ElapsedTime=0.0f;
FrameCounter=0;
}
}
Sorry so long but that needed some clarification.
Apparently you don't have Quake III then, do you?Quote:
Originally Posted by Bubba
You should know by now that most of us old timers read with the "-pedantic" flag. Which means, say exactly what you mean, or it'll be interpreted as you wrote it. ;)Quote:
Originally Posted by Bubba
Quzah.
I prefer doing this:Quote:
Originally Posted by Bubba
It's faster, cleaner, shorter and updates the FPS variable once per frame instead of once per second.Code:void calculateFPS(float timeDelta)
{
FPS = 1/timeDelta;
}
No, I don't have Quake 3. But I just got Joint Ops by Novalogic. I'm not really into Quake's and Unreal's though I have most of em. I'm more of a simmer and tactical FPS guy. But hey, I love all games. Hope I didn't come off too harsh but its not always easy to explain what you mean here.
And drax I like that method much better. Will certainly change mine. Thanks.
Wow, thanks a lot, but now i need to find a way to keep the angle changes, movement, text, and everything else in proportion as I switch to time based... *sigh*