As discussed on Gitter and in accordance with #18, these changes make it possible to set a relative cap on the frames per second of a screen. For example, running
g := termloop.NewGame()
g.Screen().SetFps(60)
would handle input and draw to the screen at a rate of no more than around 60 FPS. This is done through a simple sleep command, as per http://gameprogrammingpatterns.com/game-loop.html#take-a-little-nap. By default (or by running SetFps(0)) no FPS is set. I've also edited _examples/collision.go as a further example of screen.SetFps in action.
The main motivation for setting the FPS is to reduce the impact on system resources; running termloop with the mainloop executing as fast as possible can result in high CPU usage, for instance. Establishing a reasonable limit can greatly improve performance without much or any impact on gameplay.
Since the current approach is fairly basic, there's still room for improvement. Updating a game based on screen.TimeDelta() should still function properly, though the FpsText utility seems to be a bit buggy. Also (and possibly related to the FpsText bugginess), a simple sleep doesn't prevent the game from running slower than the set FPS, but that's less critical to the use case as of right now.
JoelOtter
commented
9 years ago
As discussed on Gitter and in accordance with #18, these changes make it possible to set a relative cap on the frames per second of a screen. For example, running
would handle input and draw to the screen at a rate of no more than around 60 FPS. This is done through a simple sleep command, as per http://gameprogrammingpatterns.com/game-loop.html#take-a-little-nap. By default (or by running
SetFps(0)) no FPS is set. I've also edited_examples/collision.goas a further example ofscreen.SetFpsin action.The main motivation for setting the FPS is to reduce the impact on system resources; running termloop with the mainloop executing as fast as possible can result in high CPU usage, for instance. Establishing a reasonable limit can greatly improve performance without much or any impact on gameplay.
Since the current approach is fairly basic, there's still room for improvement. Updating a game based on
screen.TimeDelta()should still function properly, though the FpsText utility seems to be a bit buggy. Also (and possibly related to the FpsText bugginess), a simple sleep doesn't prevent the game from running slower than the set FPS, but that's less critical to the use case as of right now.