CPU load, VWait
BlitzPlus Forums/BlitzPlus Programming/CPU load, VWait
| ||
| In a game I'm working on I have a pretty "normal" setup, with a main loop that calls a draw() function at the bottom. The game uses delta timing, and can run as fast as it likes without messing up the game timing. The problem is that this loads the CPU a lot, and that's bad if you are running something in the background or have a laptop and don't want to drain the battery. There is an option in the game to wait for the monitor, this adds a simple VWait before the draw() function is called. I thought using this would also prevent the game from using up all CPU, but I was wrong. If I use a VWait the CPU load goes up to almost 100%. If I add a timer it still goes up that high. But if I keep the timer and remove the VWait, it does NOT go up! FPS is stable at 75 at all times, but if I add the VWait the CPU load goes up to 100%. What is this?? Has anybody run into this problem? -- Martin Gunnarsson |
| ||
| If you throw in a "Delay(10)" after your vwait/flip commands it'll force your game to give up the rest of its time slice each frame, and it'll use vastly less processor. |
| ||
| But that will make the game run even slower on older systems where it probably is slow already. |
| ||
| Do you want to use 100% processor or not? If you don't, you're going to have to give up your time slice of the processor. |
| ||
| @all For the best flickerfree performance use: VWait Flip False |
| ||
| EpicBoy: I want to use 100% CPU on system that requires that to run the game smoothly, but not on ALL systems. Hansie: I already use that, and it's completely flicker free, that's not the problem. Thanks for the tip though. |
| ||
| I want to use 100% CPU on system that requires that to run the game smoothly, but not on ALL systems. You see that is the problem because: The game uses delta timing, and can run as fast as it likes without messing up the game timing. You are going to have to decide on an acceptable frame rate...maybe when the game first starts up grab the millsec, then enter a loop to count out say 100 VWaits...see how long that took so you have some idea of what the users refresh rate is and calculate the target FPS... then as the game is running keep an internal FPS counter and every few seconds or so check if it's greater then the calculated target FPS rate...if it's over then start heavily useing the Delay 10, giveing up OS timeslices to other apps...if the FPS is lower fire up the delta time, frameskip routines, all that stuff... If you want to use 100% CPU on system that *requires* that to run the game smoothly, but not on ALL systems....then you are going to have to qualify what those requirements are. |
| ||
| Try something like this Btw this part defines your Fps FrameMs = 1000 / 60 This would be 60 frames a sec Graphics 320,240,32,2 FrameMs = 1000 / 60 SetBuffer BackBuffer() Repeat ClsColor MilliSecs(),0,0 Cls start_time = MilliSecs() ;do your stuff here Flip end_time = MilliSecs() delay_time = FrameMs - (end_time - start_time) If delay_time > 0 Delay delay_time Forever |
| ||
| Use waitevent() and a timer (which can be caught as event $4001). When the program hits waitevent() it'll stop hogging the cpu and wait for an event (a timer in this case). One the event takes place the program can do all it calculating and rendering and then take a breather when it hits the next waitevent(). Waitevent() doesn't just have to be used when programming apps. |
| ||
| Yes, I've tried using a timer, and that works great. I still don't understand why there is a difference between a timer that limits the framerate to 75 and a VWait with a refreshrate of 75. |
| ||
| FrameMs = 1000 / 60 >>>This will never return you a floating point, so, it will never be a software 60hz... |
| ||
| But can't you see the strange thing here? If I have a program running at 75 FPS, limited by a timer, it hardly uses any CPU at all. But if I add a VWait before or after the timer-wait, the program uses 100% CPU, just like that! I think it's very very strange. Am I missing something? |
| ||
| Thats because timers are set-up by the OS...you use waitimer or delay and the OS will stop executeing your program and only return once the timer/deley event has occured....useing VWait means your program enters a loop where it checks the VWait refresh flag, if it has refreshed it exits the loop, if not it checks again...and again...and again untill the flag has been set...during this your program has 100% control of the CPU....but during a waittmer/delay...your program gives up CPU control to the OS, and the OS only returns CPU control to the program once it senses the correct time has elapsed. |
| ||
| That's odd, shouldn't a VWait be able to work like a timer? I mean, that would be so much better. |
| ||
| If you figure out what the users refreash rate is and create a timer at the same frequency, and use it to time your game then yes. Windows doesn't require knowing about anything moniter refreash rates to function...but as it is a multi-tasking OS it does need to keep track of application time slices, and be able to switch from one application to another...so when you use VWait, you are hogging not only your applications timeslice, but other applications as well. |
| ||
| Yeah. What I meant is that the VWait in Blitz should work like a timer, that would have been much nicer. |
   |