Reading char from stdin without waiting for input

I think you would have to look at the ncurses library .. or the pdcurses library for the Window's equivalent to avoid any platform specific requirements.

I think you would have to look at the ncurses library .. or the pdcurses library for the Window's equivalent to avoid any platform specific requirements.

That would be cheating. :P I want to see what can be done with standard C alone.

That would be cheating. :P I want to see what can be done with standard C alone.

Prepare to be disappointed. ;)
http://c-faq.com/osdep/cbreak.html

I also had the same problem in past,
I think, if you are using Turbo C, under <dos.h>, there is a function called kbhit(), checks keyboard hit.

while(1){
               // Ball movement codes,
               if(kbhit()){
               //check input ASCII and move your paddle.
              
              }
              //exiting loop conditions
}

kbhit() function is in conio.h library and conio.h is not a standard library which is not what Hiroshe want

Is it standard behaviour for a key just pressed to outpower a key being held down? ie. The user holds down the space bar for the whole game, and the "up" key out powers the spacebar? If not, than I guess I'll have a theird key for "stay still".

Is it standard behaviour for a key just pressed to outpower a key being held down? ie. The user holds down the space bar for the whole game, and the "up" key out powers the spacebar? If not, than I guess I'll have a theird key for "stay still".

As you saw in the link...

Prepare to be disappointed. ;)
http://c-faq.com/osdep/cbreak.html

The standard behavior is to do nothing in particular for any keypress, save the return key.

Only when the user is satisfied and presses the RETURN key (or equivalent) is the line made available to the calling program.

Hmm... Then I guess the best I can do in standard C is to pause the game and get the user input (up, down, still) befor continuing on.

I'm too stubborn. :P Maybe instead of the space bar, get the user to hold down return. Just write an input function that ignores '\n'. That way the stream continuously updates. Would this work? I'll try it at home.

Nope, It didn't work. When I hold down return and press a character, it wait's for the another return. Thanks for helping.

Standard C doesn't have anything to do with it.

You need to modify the input stream's mode to "unbuffered". You probably want to turn off "echo" also.

Both of these things are OS-dependent things to do. What OS are you targeting?

Standard C doesn't have anything to do with it.

You need to modify the input stream's mode to "unbuffered". You probably want to turn off "echo" also.

Both of these things are OS-dependent things to do. What OS are you targeting?

I'm not targeting any OS. That's the challenge. Any standard C code should be able to run on any computer that has full support for a C compiler. I'm trying to write the program so it's 100% standard and 100% portable. Why would I do this? I don't have a clue. :P

I can deal with an extra character printing to the screen in a standard way. I can also handle all the graphics in a standard way. Just need to get the user input without inturrupting the game. I already suggested switching stream mode's in my first post. It look's like the best way to handle it is to have a theird key for "no input".

Standard C doesn't have any concept of console or graphics displays. Hence, what you are trying to do is technically impossible.

If you are using a graphics library then you should be able to get unbuffered keyboard input from it.

Otherwise, how are you doing the pong game in console? Whatever library you are using should have a way to get unbuffered keyboard input.

Every display and every computer system is different. Libraries like NCurses are written to help mitigate those differences, but they ultimately are OS/hardware bound. There is no such thing as a standard C display.

Turning off buffered-input and echo is really not that difficult to do, nor is polling the keyboard for any ready input.

All we want to know is: system/OS for each target.
Then we can point you in the right direction for the necessarily OS-dependent methods to do what you want.

Holding down a key to keep the program running is, IMO, not a good design decision.

The point is to make it portable, not make a good game. I'm not going to make a game that's been done 1000's of time whithout a twist. The game will compile on any computer that supports C, I am not targeting any platform. Keep the thought of using a 3rd party lib out of this thread!

Assuming that the terminal is no smaller that 80x80 and no bigger than 160 high, graphics are simple without using a library. Use your brain power, you can figure it out. I'll even give you a hint: Figure out a way to erase the screen (can be done in one line of code). Then the rest should be obvious.

>Turning off buffered-input and echo is really not that difficult to do
Read my first post. I already suggested turning off the buffer. Is it portable? (my original question)
Also, turning off echo is not possible in standard C. But it was never a problem. I can deal with it.

I already figured out how to do everything besides get user input. I have already suggested turning the input stream's buffer off. I already asked if it is portable. It seems, even though bad, you can only do it by having a theird input key for "do not move".

Assuming that the terminal is no smaller that 80x80 and no bigger than 160 high, graphics are simple without using a library.

Q: How can I clear the screen?
A: Such things depend on the terminal type (or display) you're using. You will have to use a library such as termcap, terminfo, or curses, or some system-specific routines, to perform these operations.

:icon_razz:

For clearing the screen, a halfway portable solution is to print a form-feed character ('\f'), which will cause some displays to clear. Even more portable (albeit even more gunky) might be to print enough newlines to scroll everything away (although of course this leaves the cursor at the bottom of the screen, not the top).

Yup, newlines. :P

Well, Hiroshe, since your brain power is obviously so much greater than mine, the answer to your input question is simply: you've already figured it out.

Writing portable code has nothing to do with avoiding system dependencies. Rather, it has everything to do with how your code is bound to those dependencies.

But, since you so knowingly disagree, you can continue without me.

Well, Hiroshe, since your brain power is obviously so much greater than mine, the answer to your input question is simply: you've already figured it out.

Writing portable code has nothing to do with avoiding system dependencies. Rather, it has everything to do with how your code is bound to those dependencies.

But, since you so knowingly disagree, you can continue without me.

I marked it solved at post 10, so yes I have already figured it out. You can't. Simple as that.

As long as the code can run on a platform with: a keybored, 80x80 ascii terminal and support for C, It would be (for this thread)"portable."

I know what you mean by "how your code is bound to those dependencies," but as I said, that was not the goal. If I was making the game for real, I would follow your advice (good advice which I agree with), however I want to do something different (just for the sake of doing it). I didn't mean to say your advice was not helpful, but it's out of scope.

Thanks for helping.

Sorry I was so grouchy.