Fix input polling in Linux curses build

[Falconne]

Should hopefully fix #3948

Will need someone who can reproduce the issue to test if this works.

[atomicdryad]

Was able to make the game lag and reproduce the inertia effect (double MAPSIZE & DAYLIGHT_LEVEL + updatedb ); this fixed it. I'd imagine the effect is the same for devices that strain normally.

[axujen]

Tested on Linux ncurses build and it works as intended.

[Falconne]

Regarding #3787, in theory this change should have no effect in Windows because the codepath doesn't change for SDL or wincurses. Only Linux curses handling has changed.

[kevingranade]

Good point, on the basis of that I'll go ahead and pull.

[kevingranade]

Dwarfkoala, no windows user has ever reported an overbuffering issue to me,
didn't know there was a problem there too :P
Will have to look into what needs to happen to make a similar fix on
windows.

[Falconne]

I was surprise to hear about it too. The way the input polling works in the SDL and wincurses code makes it very difficult to get noticeable buffering unless the game is running seriously slow. If you're using the wincurses build, it might be worth switching to the SDL one, or vice versa, to see if it makes a difference. And if you're compiling yourself make sure to compile the RELEASE version (the Makefile defaults to DEBUG).

[dwarfkoala]

I just switched to SDL.

WHAT A DIFFERENCE.
I don't know why I haven't switched for this long.

On Fri, Nov 1, 2013 at 10:39 PM, Anuradha Dissanayake <
notifications@github.com> wrote:

I was surprise to hear about it too. The way the input polling works in
the SDL and wincurses code makes it very difficult to get noticeable
buffering unless the game is running seriously slow. If you're using
the wincurses build, it might be worth switching to the SDL one, or vice
versa, to see if it makes a difference. And if you're compiling yourself
make sure to compile the RELEASE version (the Makefile defaults to DEBUG).

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/4006#issuecomment-27615291
.