Delay(1) - Where to put it using GAF?
BlitzMax Forums/BlitzMax Programming/Delay(1) - Where to put it using GAF?
| ||
| Hi All, One of my testers has complained that my game which uses GAF (Grey Alien's Framework) and BlitzMax (of course ;) ) is using too much CPU and therefore it causes his laptop to overheat, which in turn slows the CPU and slows the framerate of the game... Its been recommended to me to put Delay(1) in my main loop, which will give the CPU space to breathe... but I am unsure where to put it... and how it will affect the GAF fixed rate logic cycles. Any ideas? Thanks Steve |
| ||
| Its been recommended to me to put Delay(1) in my main loop, which will give the CPU space to breathe... but I am unsure where to put it... and how it will affect the GAF fixed rate logic cycles - Put it just before (or after) the flip command - Logic rates should be OK -- it's only 1/1000th of a second, after all. |
| ||
| Thanks xlsior, I'll try that once I get BLide to work again... |
| ||
| A logic rate of 200 is a bit...unorthodox. Try dropping to to 60 or 120. |
| ||
| A logic rate of 200 is a bit...unorthodox Why? I understand the code, but not the reasoning behind the 200 rate... Jake must have chosen it for a reason. |
| ||
| A complete guess - there's not much point updating the logic faster than the screen can refresh each frame? |
| ||
| I would think 120hz is the most you'd want for logic, but maybe 200 for user input, but only if you can get it that fast, otherwise there's not much point. That said, higher hz rate for fixed rate logic helps with collision detection accuracy and avoiding things flying right through other things. |
| ||
| Same here...I'm actually using 120 for my logic rate and it's plenty for input detection and collision accuracy too. Maybe he chose 200 because he got a speeding ticket for $200. /shrug I think it's a quality issue too. I'd be much more apt to buy a framework from say, SSwift, Flameduck, or even Nilium(Noel) etc.... You can tell by the INSANE amount of pure Function calls in his framework that it was a lot of...shooting from the hip. There's much better/efficient ways to construct a framework than how he did it IMO. You can go into the BMax source and see how Mark set up his code...I would use that as a good template to start a framework. |
| ||
| 200 is nice and smooth and allows for good collision. I avoided 120 as I wondered if double the refresh rate might generate some moire-like timing oddities where it's almost in sync then slips out then goes back in etc. Never tested that so can't say for sure. My original timing routine was based on some code by Mike Boeh (Retro64) but that was at 500Hz and I thought that was excessive so I slowed it down. 200 has worked nicely for all my games but I considered making my latest game at 120Hz but never did in the end. As for Chroma, thanks for your expert opinion. |
| ||
| What is the reason for using more than 60Hz? The video card updates the monitor only with 60Hz. All scenes build between these 60 pictures are never visible. So why stress the video card? It is completely useless. Maybe there is a need for updating the world with more accuracy (User-Input or Collisions), but never a need for doing more than 60 Renderworld a second. The collisions ar not based (depending) on the last DrawImage-instructions, but always are "created on the fly". Test it: you can check your collisions without painting anything, without FLIP, etc... Or am I wrong? |
| ||
| I think it's because you can never render at exactly the same speed as monitor refresh (if a frame takes 1% longer, then too slow it's missed the render) so it's a good idea to go slightly higher than this to keep things smooth. |
| ||
| Midimaster wrote: The video card updates the monitor only with 60Hz. All scenes build between these 60 pictures are never visible. So why stress the video card? It is completely useless. But my video card updates the monitor at 75Htz.Czar Flavius wrote: think it's because you can never render at exactly the same speed as monitor refresh (if a frame takes 1% longer, then too slow it's missed the render) so it's a good idea to go slightly higher than this to keep things smooth. But then you will run into the reverse issue of getting the occasional double update per frame. The only way to ensure one update per frame and a smooth speed is to force the monitors refresh rate and tie your logic to that directly. Well I say ensure, but even that won't ensure it. |
| ||
| Yeah basically I wrote the framework when people still had CRTs that it was possible to run at 120Hz, so I wanted higher than that to keep it smooth, so there'd never be any frames missing. Sure if you get double update per frame it wouldn't look smooth if everything moved at *integer* coords but I moved everything by floating point so it did look smooth. |
   |