Linux Shell Game Input

I'm writing a simple Linux Game in C++ for school, I've been using getch for my input controls for Up Down Left Right. The problem is that getch blocks the program from continuing. Online I gathered that kbhit may be a better option, except there are over 10 different kbhit.h's and they dont fucking work. if(getch) in a while(1) loop would be totally fucking fine if i could have like a 1ms timeout for getch so if there is no key pressed the screen keeps going. What do?

H...IBT? If you use ncurses or whatever you can switch to non-blocking I/O. But if you want smooth keypressed/released detection, you're better off with SDL (Hold a key down in the shell and note the delay between the first printed character and the rest, this is guaranteed to happen in textual input, unless you change it globally in some config.)

Have you tried getting out yet

its an alternative to taking the rest of the class you little shit, the rest of the program is simple im just hung on this, ill dick around with curses i guess.

>>4
HEY FUCK YOU is all.

lrn 2 select()

this is you, faggot ->

troll do not know about my SDL?

Why don't you read your fucking curses man page, OP?

Read SICP.

spin getch() off into its own process and it won't block the original process. you can synchronize on a mutex or a channel or whatever you want. since the two processes would only be sharing a char, you probably don't need to synchronize at all

>>11
Better yet, have the new process simply report its input via a pipe.

>>12
LOL 0/10

>>1
The standard game loop is dead simple.


while (1) {
    read_input();
    update_state();
    redraw_screen();
}

On Linux, you have many options for making a read_input function that doesn't block waiting for input.

1. Use select or poll.  These functions tell you which file descriptors are ready for reading/writing so you can use them without blocking.  (See man 2 select)
2. Use non-blocking IO.  Put fd #0 in non-blocking mode, and it will give error EAGAIN / EWOULDBLOCK if there is nothing to read.
3. Use ncurses, which can do all of this for you automatically.
4. Use a GUI.  SDL is a library of mediocre quality in general, but it does do basic stuff like this pretty easily.

NOTE: Don't make the newbie mistake of reading only one event in your read_input function.  Read all pending events, and only redraw the screen once there are no more events in the queue.

>>14
YOU HELPED HIM!!!

>>14
SDL
U MENA ALLEGRO

>>16
He should mena SFML at this point.  It's 2010 for Sussman's sake!

>>17
C++, pig disgusting.

>>18
There are C bindings, silly :)

why are all you retards suggesting linking against some retarded library just to grab keyboard input? doing it yourself is like ten lines, tops.

>>17
SFML is written in C++ and provides an efficient, object-oriented design. It relies on standard patterns and idioms to provide a simple and robust framework.

>>21
everyone knows real ENTERPRISE software is written in Coffee

>>22
I think it would be better if you wrote Coffee.

>>23
Thanks for the tip, will do so in the future.

>>20
Yeah, you shouldn't link against libraries, ever.  Like, all you need is the syscall opcode which is like one line of assembler.  You especially shouldn't link against something like ncurses, which is well-tested, works practically everywhere, is installed practically everywhere, and allows the programmer to use ECMA-48 control codes on a wide variety of terminals portably without having to read the 108-page ECMA-48 specification.

Only trolls will tell you not to use libraries.  The ncurses library can put your terminal in raw mode so you don't have to look up a bunch of escape sequences and parse / emit them by hand.

>>25
DFTT

>>26
Discrete Fourier Transform Training?

>>25
so you don't have to look up a bunch of escape sequences and parse / emit them by hand.
Bah, who needs to look up escape sequences? ncurses isn't as universally portable as you might think. I found out the hard way that forwards compatibility between point releases is not something you should rely on. Still, use it.

>>25
do you think reading from stdin isn't well-tested, doesn't work practically everywhere, isn't installed practically everywhere, and has any need at all for ecma-48 control codes? if you do, then you're retarded

protip: all you need is the read syscall, which is like one line in language

>>29
I'm not quite sure you know what is trying to be achieved here.

>>29
protip: all you need is the read syscall, which is like one line in language
And a copy of the terminfo for your terminal. Oh wait.

>>31
>his terminal emulator doesn't pass keyboard input on stdin
laughingputin.jpg

>>32
There is a lot you don't know about terminal emulation.