I'm currently writing a game engine, and I've hit a bit of a snag. The game won't be extremely tasking on the CPU as far as logic and AI go, but graphics will be a different story. The game will have an almost constant background, which changes only a small amount throughout the game, and any number of sprites on the screen, from 1 to 100 or more. Even I'm not sure how many will be on the screen at once. Anyway, my question is, should I bother to detect whether or not the screen needs to be updated, and update only when the screen would change, or should I not bother and update every frame?
In my games I usually update as fast as the computer will let me, if that means 12 frames per second or 212 frame per second that's fine. (Although I do have an option to slow it down in the options for people with crappy laptop displays that only refresh at 25hz). Then when you move a unit it has to calculate the time it's been since the last frame update and the speed it's travelling and move it that many pixels. This is the most efficient and best looking way. Also are you going to have a mouse in your game? Becuase a game running at 12fps can look really choppy, simply starting a new thread which handles the mouse can make it "look" smooth even at 12 fps for the main game, but the mouse will update at 60fps. But yah, do as many fps as you can! See ya, Ben
Well, I know updating only when necessary is going to be the fastest. That much is obvious. When I update every frame, I can only eek out about 24 FPS, but when updating only when necessary, without a timing function in the game yet, I can yield about... 200,000 FPS. Okay, that's cheating, I know...:) However, I have figured that updated only when it's necessary, I can probably obtain between 40-60 FPS, if not faster. This number obviously depends on the number of currently displayed sprites (and their size) which need to be updated. My problem is that, in order to update only those sprites which need updating, I'll have to check through all of the sprites to find the sprites which need updating, and blit them to the screen where they need to be (compensating for the Z location, and redrawing the background in that area also). I'm pretty sure this will be the fastest by far, but I was wondering if anyone knew of a better (faster in execution or programming time) way to accomplish this task. If not, I'll knuckle down to the grindstone, but I thought I'd ask first. :)
Cyberben: dont let it update faster then 30-60fps..it will eat you memory bandwith ...and for no visible advantage If anybody chooses to update ONLY required squares... well think about it a lot...before...what will happed to your game speed if suddenly 100 sprites enter the screen after just ONE was moveing around...? eh? is this going to happed (game logic can prevent it?) if not your safe...if yes...better update allways (like in a RTS with 600 units or so :) ) but dont do the background every frame also...or do it in a system ram buffer and then update just some "dirty rectangles" into the video back buffert ...to save some extra AGP/PCI bandwidth... For small games however "update allways" method its just fine :) as for games with many... many units...in screen
BogDan: I'm not sure what you know aout memory models but this will not affect memory at all! It will be the same only faster (when possible CPU Speed permitting) and BTW there was a HUGE post about Game frames per second on GameDev which does conclude (with proof) that >60FPS if benifical visually, many monitors now sync at 120hz! IF all of a sudden every unit in the game enters the screen all that will happen is the FPS will drop (The amount it drops depends on the machine on a machine with >32mb of video memory it might now drop as everything will be done in hardware on a computer with a 4mb video card it will drop rather obviously!) Thanks for the concern anyhow, but I've done my homework on these issues... ;) See ya, Ben
Cyberben: well lets say you are in 800x600x16 this makes a frame=960k lets say approx 1Mbyte...if you update the video backbuffer from a system backbuffer ar 20fps its 20Mbytes/sec at 120fps its 120Mbytes/sec...this will eat ALL Memory bus bandwidth...no othere operations between the CPU and the memory chips will be possible :( remember that memory is Dynamic and works in RAS/CAS cycles...so a PC133 7ns chip will only do half (average) thansfer rate (if no special cycels are used) So basically you have a bottleneck here...even if the CPU is able to work at 1Gigahetz..it can only read/write memory at 133megahetz or lower. Yes i know cache memory helps here BUT there is no way a 1Megabyte frame will fit in the L1 cache or even in the L2 cache.. Again even if the Video Board has 32Megabytes of RAM...a simple animated sprite: 8 headings x 10 steps in that direction x 64(dx) x 64(dy) x2 (16 bits)=655k for a simple ground unit an animated air unit (32 headings) is 2.6megabytes per unit you will need fire animations or other effects...so if you have 20 units in your game is 20x2.6Mega=50Megabytes of video RAM... a normal decent 2D RTS game CANT keep all sprites in video... Actually you can't keep any sprite in video (besides mouse and interface) if you want to make any alpha blending... so you will be transferinf the unit sprites from system to system also ...eating MORE bandwith... think about it :)