Ideal target framerate?
Blitz3D Forums/Blitz3D Beginners Area/Ideal target framerate?
| ||
| Hi folks, I'm working on my first game in Blitz3D -- it's 800x600x32 (window), 2D, tile-based, no scrolling. My question is regarding framerate/screen updates because I'm a little concerned (possibly unnecessarily) about the CPU load on my engine so far. Every frame draws the entire screen from a pre-drawn graphics buffer, does a little sorting and timer updating and draws players, updated tile animations, etc. My system is P4 2.4GHz & Geforce 4 Ti4200. At 60 fps, the CPU load for the game process is 89-97% (this is basically just an idle game test too, nothing much going on). If I drop to 50 fps, it's about 40-70% CPU load. I also tested 40 fps but this felt a little bit jerky... So... if my CPU has so much load, how are slower processors going to handle it? Or is it not even something to worry about? --Leto |
| ||
| Try some of these links for more info. Since your game is 2D the delta timing tutorial will probably be what you're looking for. http://www.blitzcoder.com/cgi-bin/articles/show_article.pl?f=gamemorduun03212002.html http://www.blitzcoder.com/cgi-bin/articles/show_article.pl?f=johnblackledge09202003161847.html http://www.blitzcoder.com/cgi-bin/articles/show_article.pl?f=jl2k11032002164857.html |
| ||
| Thanks for those, Axeman. Guess I'm just worried about the performance on slower processors :) |
| ||
| Don't draw the entire screen if you don't have to. For instance, Windows uses a technique called 'dirty rectangles'. Only the 'dirty rectangle' parts of the screen need updating so only those rectangles ARE updated. |
| ||
| 2D tile map, what to do is to draw all the tiles that are onscreen, plus a border of tiles which lie offscreen, and draw these all onto an imagebuffer, larger than the screen. Then, when u scroll, only draw in the tiles that are needed. |
| ||
| At 70fps it will use about 98% cpu load. At 80 fps, it will use about 98% cpu load. At 100 fps, it will use about 98% cpu load. Notice a pattern emerging? Basically, anything below 70, and you're introducing delays which cause slowdown on the cpu and therefore more CPU time. Simply because you're using 98% CPU time doesn't mean thats the fastest your program can go - Blitz simply chews up all idle CPU time. If you turn off frame limiting and vsync, you'll probably get about 200fps, still with 98% CPU load. Most 2D games will work pretty well on slower processes as long as you're not using TFORMIMAGE or resizing/scaling any images. The fact your cpu usage is high doesn't reflect how much power is required to run the game. A simple "REPEAT:RENDERWORLD:FLIP:FOREVER" will use 99% CPU time, even on a P4 3.4 Extreme. The only way to really find out if your game runs okay on slower processors is testing. Submit a demo to the forums, let a few people try it out, and ask what kind of CPUs they have and how it performed. As far as what Wolron was saying about 'dirty rectangles' - only needing to draw the parts of the screen that are updated - the fastest way to achieve this is via buffer copying. After the flip, copy the FRONTBUFFER to the BACKBUFFER. Then, just draw the changes on the backbuffer that have been updated. No other drawing required. FLIP it, and these changes are reflected while the rest stays the same. +BlackD |
| ||
| In addendum to my previous post - the reason you're getting lighter CPU load at lower framerates is because you're using framelimiting - ie, simple delaying. Delaying is a waste of CPU time. In the time you delay the frame, Blitz could have already rendered the entire next scene (even if its only 0.05 seconds). Sure - in early programming we all start out controlling framerate by delaying - but when you feel suitably advanced enough, you need to switch to deltatiming. Do a forum search for Delta Time to get a feel for it. Basically, rather than limiting the framerate to control CPU load, you let the program run as fast as it possibly can. Then, each frame, you see how much time has elapsed since the last frame, and update entity movements (or 2d graphics movement, whatever) relative to how far they should move at a given rate. If you want a character to move 50 pixels a second, and a hundredth of a second elapses between frames, then that frame, just move the character half a pixel (it'll sort itself out fluidly while playing). This way you're using the CPU as optimally as possible, and it'll run at the same speed on slow and fast CPUs. If someones computer can only run at half the speed required to move a character 50 pixels a second, then each frame it'll move the character 2 pixels. Get the idea? :) It takes a bit of getting used to and a couple of extra functions to write, but its the most efficient way to time a game. You can use this timing system not only for player movement, but also for everything else - animations, hud updates, etc. Most modern games use delta timing as opposed to frame limiting. You can see it in use by loading up a 3D game that your CPU can't handle (For your computer, try PainKiller or Doom3 at high res). When you move around, the character doesn't move slower as a result - it "jumps" about, giving the "jerky" effect that occurs when a computer isn't powerful enough to run a game at a minimum speed. Thats because each frame, no matter how long it took between frames, or no matter how short, it updates the player movement/enemy movement/animations/etc at the same constant rate. +BlackD |
| ||
| Thanks a lot for the replies :) |
| ||
| No problem, glad to help. :) |
   |