Hacker News new | past | comments | ask | show | jobs | submit login

I'm not a game dev, but rough guess: the framerate is artificially limited to some 'sane' range by the equivalent of a short sleep() which is cancelled by an input event. More devices, more events, more chance to prompt the next frame early?



Yep, almost certainly what's happening.

It's very common to constrain your central "game loop" for several reasons. A game like Hotline presumably has some basic loop like "process inputs, process events, update AI plans, process AI actions, redraw screen". When the logical tasks are easy (e.g. most of the AIs are dead and you're standing still), that's essentially just a busy-wait that redraws your screen as fast as it can. Constantly maxing system resources is obnoxious, and it can be jarring when things slow back down. 40FPS might look just fine, but you can still 'feel' the change when you ramp up and down from 60FPS, so it's nicer to just cap the whole thing at 40FPS. Mouse inputs probably don't adjust the cap itself, but to avoid laggy responses they're usually interrupts which might refresh the screen.

A fun aside: some games fill out the time until the next redraw with more "thinking time" instead of sleep(), which leads to bizarre behaviors like an AI that gets smarter when you turn down the graphics settings.


Yes, a typical artifact of not resuming the remaining sleep after the event handling.

Does not work with pushing random keys only because those are buffered separately.


Not gonna lie that is hilariously ingenious if its the case.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: