Skip to content
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

Closed
Mikolaj opened this issue Oct 6, 2010 · 3 comments
Closed

Limit framerate #4

Mikolaj opened this issue Oct 6, 2010 · 3 comments

Comments

@Mikolaj
Copy link
Member

Mikolaj commented Oct 6, 2010

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.

@kosmikus
Copy link
Contributor

kosmikus commented Oct 9, 2010

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 ...

@Mikolaj
Copy link
Member Author

Mikolaj commented Oct 10, 2010

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.

@Mikolaj
Copy link
Member Author

Mikolaj commented Feb 22, 2012

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants