Acceptable Framerate
BlitzMax Forums/BlitzMax Programming/Acceptable Framerate
| ||
| I began writing my game with the assumption that 60fps was ideal. I've been improving the graphics with Anti-Aliasing, Shadows, etc and am witnessing a performance hit. It's not drastic but leaves less resources time to process game logic. My question is what would be considered an acceptable framerate? 60? 40? 30? maybe even 20? Thanks! |
| ||
| IMHO it's more important to get a steady framerate than a very high one. I perceive stuttering as more annoying than a game that has only 30 fps vs. a game that runs with 60 fps but not consistently so. YMMV, though. |
| ||
| IMHO it's more important to get a steady framerate than a very high one. +1 I perceive stuttering as more annoying than a game that has only 30 fps vs. a game that runs with 60 fps but not consistently so. |
| ||
| I perceive stuttering as more annoying than a game that has only 30 fps vs. a game that runs with 60 fps but not consistently so. +1 Which means that depending on the kind of movement in your game, 30fps could be better than 50fps because on a standard 60Hz screen the 30 fps will give you constant, linear motion while 50fps could be erratic |
| ||
| Your rendering and logic should be separated, and your logic should be locked at a framerate that suits the gameplay. (EG: You might want it locked at 30 updates per second if it's an action game, 60 if it's a twitch game, or merely 10 if it's a hidden object game.) Then you can decide whether to let your renderer run as fast as it can (which is desirable for hardcore PC gamers) or lock it to a sensible frame rate as well. Since you're talking about shadows and anti-aliasing, I'm going to assume it's a moderately action-ish game, at least. In which case you could try locking both at 30 and see how that looks. You still need to separate logic and rendering (if they're not already) because there will always be hardware that can't render the requisite frames. Dropping frames is bad but lagging on input is very bad. |
| ||
| 60 or 30 |
| ||
| Why should a hidden object game only have 10 fps? All examples I have played/seen don't exactly have copious amounts of complex animations and only show some "colorful star explosions" when a certain object is found or some simple image dissolves etc. Rendering such stuff "fluidly" should be no problem for most PCs still in use today if the OS is compatible with the game. Especially considering that most HOGs aren't supporting 1080p anyway... My advice would be exactly the same as with most games that render moving graphics: Go for 30 stutter-free fps if you can't get stable 60 (because 99.9% of all TFTs support that) - and always try to support VBlank (which shouldn't be a problem for BM thanks to Flip). |
| ||
| > Why should a hidden object game only have 10 fps? 10 is a bit low but... Hidden object games are very often bought and played by people with very low spec hardware, running at 10 or 20 FPS often means it will work well on lower spec hardware. |
| ||
| think they talked about 10 "ups" (updates per seconds) not 10 renders ("fps"). So they just check clicked spots every 100ms and then start eg an explosion-animation. Problematic here is just one thing: if you have more than 10 animation sprites ("frames") you want to display within 1 second, you will run into problems ... As logic and render are decoupled the logic has to take care of what frame to display (else the animation would be the faster the more fps one has). Some developers are doing it differently: PhysicsUpdate X times a second LogicUpdate Y times a second Render Z times a second So instead of just taking care of "graphics" and "movement" we also have a call to do other things. So this means: to have your bullets correctly fly towards a wall, we have enough updates for physics. But the logic update (checks if you clicked somewhere ... GUI etc.) could be run less often a second. bye Ron |
| ||
| I think at anything less than 16fps it really starts to feel draggy. For any hidden object type of game it should be easy to have smooth framerates even on old machines because they're not exactly throwing around tonnes of fillrate. |
| ||
| if your hidden object game has some "up to fullscreen"-assets which should be displayed simulatenously you will see some serious fps-drops on "aged" computers. And remember, the beginning of the century already had 1024x768 desktops and laptops. I know - they wont be your customers.... but hmm never say never. how do you come to the value of "16 fps" ? 16 because 2/3 of 24 (which is known from movies) ... hmm. bye Ron |
| ||
| Those HOG customers with older computers either know damn well that their PC isn't exactly "hot stuff" anymore or they simply don't even recognize frame drops as a problem. For them it is either normal or nothing they even see... |
| ||
| Yeah... you sound like a vendor selling up to nothing. "if you are old, you wont buy that ferrari" "if you look poor, you surely are not wealthy".. They surely know that they do not have the best computer in the world, but they might like your product - and give it a try. That is why optimizing the basics can help increasing your sales. We do not talk about 1-2% of performance... we talk about 50+%. bye Ron |
| ||
| Why should a hidden object game only have 10 fps? Why waste processor cycles doing things that don't need to be done when you could be focusing those cycles on making animations smoother instead or simply saving heat and power - since I'm sure laptops are popular for casual games. All of your examples are about rendering, and as Derron already pointed out, I'm talking about logic, not rendering. In a hidden object game, logic would be things like checking the mouse and hitboxes. As long as your logic is fixed, you won't miss clicks, it'll just take up to a 10th of a second. Is that really unresponsive for a hidden object game? If it is, try fifteen then. So they just check clicked spots every 100ms and then start eg an explosion-animation. Problematic here is just one thing: if you have more than 10 animation sprites ("frames") you want to display within 1 second, you will run into problems ... As logic and render are decoupled the logic has to take care of what frame to display (else the animation would be the faster the more fps one has). If those sort of scenarios were truly a problem, such a setup would be virtually useless. Anything which moves in your game is a logic function, so everything would be very jerky if you only updated your logic every 100ms. Your rendering loop should "tween" (essentially a linear interpolation) between two logic frames. Sprite positions, scale, rotations, colours, animation, particles - they can all be tweened. Although, since particles don't really need to be fixed unless they're ultra-realistic and involve collisions - you could probably not bother fixing them at all. Mark (Sibly) posted a very simple sample in the Blitz3D code archives many years ago. If memory serves, BlitzMax doesn't have this functionality inbuilt but it's not hard to implement it yourself. I still consider Glenn Fiedler's article "Fix Your Timestep" to be the "bible" on the subject if you're interested. http://gafferongames.com/game-physics/fix-your-timestep/ So this means: to have your bullets correctly fly towards a wall, we have enough updates for physics. But the logic update (checks if you clicked somewhere ... GUI etc.) could be run less often a second. I can see that making a lot of sense for games where physics are an important factor. Games where bullet collisions have to be perfect would definitely want to run more physics cycles than basic GUI cycles. We do not talk about 1-2% of performance... we talk about 50+%. Indeed. I've never worked on a hidden object game, but I would imagine some have pretty complex 2d collision checking at a pixel level. Even with modern hardware, that's not trivial. You're hardly going to be offloading it to the GPU, after all. Doing it fifty times a second when you might only need to do it ten or fifteen could make a huge difference. |
| ||
| @tweening frames (animation) I am not really fine with the approach of having logic ("which sprite frame should i show next - time for idling animation? walking?") mixed slightly into the render functions. That is why for "me" this is a problematic thing with updateCycles/s < frames/s (with frames = portions of an image containing an animation frame). @fix your timestep Already using it for a long time now. But rewrote it this week to make sure it does what it should do because I had problems with the BlitzMax-Floats: (tween + (1-tween)) <> 1 So a figure absolutely relying on the tweened position jiggered around a bit ("shaking"). At the end I had to make a helper function which takes out the jiggle. 'returns the tweened value between the aimed value and the backup value 'if avoidShaking is true, the old value is returned if the position did 'not change that much Method getTweenResult:float(currentValue:float, oldValue:float, avoidShaking:int=TRUE) local result:float = currentValue * getTween() + oldValue * (1.0 - getTween()) if avoidShaking and Abs(result - currentValue) < 0.1 then return currentValue return result End Method Maybe that is only a BlitzMax-problem (somebody knowing workarounds?). Conclusion: I might have a too narrow view of "logic updates" with doing all "non draw" parts there (eg. "spritePos :+1", "alpha :*0.95" or such simple one liners) - like you said much is possible as soon as you take the tweenValue into account. For me each (with 10 logic/s compared to 60 render/s) logic thing done with logic saves cycle time. If having to check / take into consideration tweening for every sprite change it is done 5 times more than needed per second. I know... if I doubled logic to 20/s I would also double other calculations... hmmm tradeoff... so it surely is just a matter of ones project. bye Ron |
| ||
| I prefer this article: http://www.koonsolo.com/news/dewitters-gameloop/ |
   |