New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Limit framerate #4
Comments
IIRC, running probably redraws the screen each step. You want running to be fast, so you certainly don't want to limit the framerate then. Displaying animations is a different issue. We'll need something there, but actually I wanted to deviate from NetHack w.r.t. animations anyway by including a more flexible time model. For example, in NetHack certain events such a zapping a wand are always instantaneous. I'd like them to be just really fast, but a player/monster fast enough might still just step out of the way ... |
Hmm, interesting. Why not. About running, I guess it's a personal preference, if the run should look instantaneous or if you want to see all the intermediate positions and at each speed. My point is, if we have fast enough machine and don't limit the framerate, the running will always look instantaneous, because the game engine frame duration, times the distance of the run, will still fit within one physical screen frame duration. The same with other animations, but I'm OK with your model and in it, such animations are bound by the game-time and not framerate at all. |
The "step out of the way" is implemented as LambdaHack/LambdaHack#27. The "show all frames, even if player too slow" idea is moved to LambdaHack/LambdaHack#19. Closing. |
When we have ASCII animation, e.g. for acid rain, it will be essential to set a proper framerate so that the effect is shown at proper speed. I guess something like 5 frames per second could be OK.
This is also related to issue #3 because if framerate is unlimited and the machine fast enough, autorepeat is disastrous even if we flash input after each frame. With flush and slow framerate a cat walking over a keyboard will not necessarily lead to disaster and repeated commands, like running or searching, should always stop if a monster appears, so they are a safe way for quick play.
The text was updated successfully, but these errors were encountered: