Making a C++ program not wait for input

Z

Zalbag

Limp Gawd
Joined
Aug 24, 2002
Messages
330
Hey guys,

I am writing a small pong game and I am trying to figure out how to make it so the program keeps drawing the ball (and running test cases of where the ball's location is) even though the program is waiting for the user to input something.... Make sense?

I am using C++

Any help would be greatly appreciated
 
sounds like you need a timer class. But I don't really know much C++ so I can't be of any more help.
 
multi threading maybe?

my extent of multi threading was a little program in java just to try it out, i made a progress meter that kept refreshing on the command line based on a variable that i kept randomly increasing to 100. not of much practical use though
 
In a Breakout game I had to make in assembly, I used a DOS interrupt that would check for any input (keystrokes) in the input (keyboard) buffer... if the buffer was empty, process would continue, otherwise it would extract the keystroke and perform the necessary operations.

I believe you can use those DOS interrupts in C++, however there may be a simpler but similar way using an input buffer.
 
You could always look into kbHit() & getch(). It's been a while, but I believe it went something like this:

Code: 
char ch;
while(playing)
{
    // code to move ball
    
    // This will only execute if the user pressed a key, otherwise, it will continue
    //   going through the loop
    if(kbHit())
    {
        ch = getch();
        // do stuff depending on what key was hit
    }
}

It's not cross-platform of course, and it probably needs a LOT of tweaking, as I havn't used this sort of thing in many years, but it should be a start. One other thing, though. I believe the arrow keys (and some other keys, like F1 - F12) send an initial character of ASCII value 0, and then another character right after to tell you which special key was pressed, so if you want to use the arrow keys, you'll have to do some testing to figure out what the second character is. :cool:
 
i remember making games on my ti 83 in ti basic. there would be a loop that did stuff and at the end i would have a getkey, well if it was complicated enough, there was a very noticable delay between when you pressed a key and when the action occured since i guess you can only have one thread in ti basic (sorry a bit OT)
 
Your going to need to create another thread to read input and send the input through a pipe to the main program. This is pretty advanced stuff, I dont think I could even do it, my classes never went that deep into C. And I already have a full plate of stuff to teach myself.

(Im sure there are pleanty of api's out there that will make this alot easier on you)

http://www.cs.cf.ac.uk/Dave/C/CE.html -If you dont know how to get started, this will get you going.
 
^^ but isn't that just like my game on my ti 83, if it's complicated enough, there may be a delay from when the key is pressed to when the action is performed (granted i guess it would have to be /really/ complicated on a modern computer to notice a difference on a command line game but it's more a matter of programming principle. it seems like a shortcut to rely on one using a fast computer to compensate for poor programming
 
OK, let me explain a little bit more, tim,... this is what is going to happen:

You press a key, that keystroke goes into some system buffer... not some buffer you've set up in your C++ prog.

What your C++ prog does, as it iterates through the loop, is call up that system input buffer and checks to see if there is any keystrokes in the buffer. It does not wait for a key to be pressed, it checks to see if a key has already been pressed and is waiting in the buffer (that's what a buffer is...). If there are no keystrokes, fine! The call returns a null flag and you can continue your process. If there is a keystroke, you extract the key and perform the necessary operations... most such buffer calls will automatically clear the buffer after you read the key.

eg.

//pong stuff processing
call KeyboardBuffer
if ContentsofBuffer != null
then //perform operation based on whatever keystroke is in ContentsofBuffer
//continue pong stuff


Calling the buffer does not wait for input....
 
tim_m said:
^^ but isn't that just like my game on my ti 83, if it's complicated enough, there may be a delay from when the key is pressed to when the action is performed (granted i guess it would have to be /really/ complicated on a modern computer to notice a difference on a command line game but it's more a matter of programming principle. it seems like a shortcut to rely on one using a fast computer to compensate for poor programming
Click to expand...

There'll always be some lag between change in state and change of the rendering of the state. Doom3 is sliced into 60 changes of game state per second, and rendering can be even slower than that, depending on hardware and settings. You should NEVER add threading (or any other complexity) to a system where there won't be a benefit provided by it that is greater than the difficulties presented by adding it. In the case of his game, it retrieves data from the keyboard buffer and renders things based on that and other rules. Using another thread to handle keyboard input won't get him anything unless the rendering takes so long that the keyboard buffer can get totally filled before being checked, which in his case should be a totally non-existant problem (especially since if it takes that long to render, the program would be a total failure, no matter how much keyboard input it could accept).
 
theDot said:
OK, let me explain a little bit more, tim,... this is what is going to happen:

You press a key, that keystroke goes into some system buffer... not some buffer you've set up in your C++ prog.

What your C++ prog does, as it iterates through the loop, is call up that system input buffer and checks to see if there is any keystrokes in the buffer. It does not wait for a key to be pressed, it checks to see if a key has already been pressed and is waiting in the buffer (that's what a buffer is...). If there are no keystrokes, fine! The call returns a null flag and you can continue your process. If there is a keystroke, you extract the key and perform the necessary operations... most such buffer calls will automatically clear the buffer after you read the key.
...
Calling the buffer does not wait for input....
Click to expand...
actually, in ti basic, calling getkey does just that. if a key has been pressed, it returns a number for that key else it returns 0, it doesn't wait. if in ti basic you wanted to wait for a keypress then it would be like while getkey = 0, same idea in c++ i guess

CH, good point about complexity, i obviously wasn't thinking about that at the time of my previous post. KISS right? :p
 
theDot said:
No, come on guys it's not that hard!

Look: http://users.wpi.edu/~kuttyb/projects/Keyboard.htm

http://msdn.microsoft.com/archive/d...put/using/devicedata/bufferedkeyboarddata.asp
Click to expand...

Actually it is that hard.

MMLib is a 3rd party SDK that does the hard work for you, but I can not speak to how difficult MMlib is to use.
DirectX implementation is a little out of the scope of a console application.
OpenGL provides similar abilities also, but again a little out of the scope.

Speaking of scope, what compiler and platform are you developing this on Zalbag?
 
Cardboard Hammer said:
Using another thread to handle keyboard input won't get him anything unless the rendering takes so long that the keyboard buffer can get totally filled before being checked,
Click to expand...

It's possible that polling the keyboard is expensive and takes away time that would be better spent doing something else. If a thread can be created that sleeps most of the time, then reacts when some input is received, you really are better off.

Polling is something a programmer almost always wants to avoid.

.B ekiM
 
Hate to sound like a newb, never tried it before. How exactly do you check stdin for input without having to place the data someplace?

I was playing with stdin->_base which seems to be the buffer, but doesnt react as one would expect. Oh yeah, I would greatly appreciate it if you could go ahead and explain how to do so with c++'s input streams as well.
 
not even close. You could just constantly keep checking the keyboard buffer and see whats up. No the most efficient, but hardly creative and its very simple.

edit: beaten
this crap is hardly complicated.

Daemon1313 said:
It would have to be multi-threaded or you would have to get very creative.
Click to expand...
 
its not as simple as that. Unless there is an interrupt available on your chip you have no choice but to poll. If you are programming for a microcontroller, many times it is much easier to poll your databusses that dont have interrupts than to deal with all the overhead required to make another thread. After all, even if you do somehow write your own OS for the microcontrolelr (or even a pc) and its listening for something that doesnt have an interrupt, its just going to poll anyway so you are back to square one. Multithreading is not always more efficient. It all depends on the process.

mikeblas said:
It's possible that polling the keyboard is expensive and takes away time that would be better spent doing something else. If a thread can be created that sleeps most of the time, then reacts when some input is received, you really are better off.

Polling is something a programmer almost always wants to avoid.

.B ekiM
Click to expand...
 
Whatsisname said:
its not as simple as that.
Click to expand...

Well, it is, if you're only considering Windows ... like we were here.

Whatsisname said:
Multithreading is not always more efficient. It all depends on the process.
Click to expand...

Nope, it isn't. And I didn't say that it was.

What is "the process"?

.B ekiM
 
the process is "a process" in general. It was a general statement. Back to critical reading for you.

And actually, if you consider you're running in a windows environment, it is actually simpler, because you can use the windows message pump to get keystrokes for you, and it can be done in a very easy manner.

mikeblas said:
Well, it is, if you're only considering Windows ... like we were here.



Nope, it isn't. And I didn't say that it was.

What is "the process"?

.B ekiM
Click to expand...
 
Whatsisname said:
Back to critical reading for you.
Click to expand...

How does the efficiency of multithreading depend on the process? Do you mean that it depends on the specific application?

Why would it depend on the process? If I start two copies of NOTEPAD.EXE, I have two processes. Why would multithreading be better for one instance of NOTEPAD.EXE than the other?

At any rate, I think you must have meant "inductive" instead of "critical".

Whatsisname said:
And actually, if you consider you're running in a windows environment,
Click to expand...

Thing is, the console application that CoolID says he's writing doesn't get a message queue. If he tries to make a message pump, it won't have anything to pump because the console window is owned by Windows, not the application, and the application doesn't see its messages.

But, yeah: if he did have a GUI window that could accept keyboard input, he'd be able to wait for the input messages and avoid at least some polling.

.B ekiM
 
process as in application of an algorithm some sort, not process as in asdfgh.exe

mikeblas said:
How does the efficiency of multithreading depend on the process? Do you mean that it depends on the specific application?

Why would it depend on the process? If I start two copies of NOTEPAD.EXE, I have two processes. Why would multithreading be better for one instance of NOTEPAD.EXE than the other?

At any rate, I think you must have meant "inductive" instead of "critical".



Thing is, the console application that CoolID says he's writing doesn't get a message queue. If he tries to make a message pump, it won't have anything to pump because the console window is owned by Windows, not the application, and the application doesn't see its messages.

But, yeah: if he did have a GUI window that could accept keyboard input, he'd be able to wait for the input messages and avoid at least some polling.

.B ekiM
Click to expand...
you can cheat that and use WinMain (or whatever the hell it is) in a console window and use all the good stuff on windows in console. However, it's seriously frowned upon.
 
Daemon1313 said:
Actually it is that hard.

MMLib is a 3rd party SDK that does the hard work for you, but I can not speak to how difficult MMlib is to use.
DirectX implementation is a little out of the scope of a console application.
OpenGL provides similar abilities also, but again a little out of the scope.

Speaking of scope, what compiler and platform are you developing this on Zalbag?
Click to expand...

Microsoft Visual Studio .NET (2003) - Academic, Windows XP Professional.

I talked to my C++ teacher and inside a library he gave us at the beginning of the course is a function to do asyncronous input. No this was not class work, I am in Programming 1 at FullSail and the current topic is the basic datatypes and basic functions. I am pretty fluent with C++ so I decided to start writing a pong game...
 
use opengl or something so it can have pretty colors.

Zalbag said:
Microsoft Visual Studio .NET (2003) - Academic, Windows XP Professional.

I talked to my C++ teacher and inside a library he gave us at the beginning of the course is a function to do asyncronous input. No this was not class work, I am in Programming 1 at FullSail and the current topic is the basic datatypes and basic functions. I am pretty fluent with C++ so I decided to start writing a pong game...
Click to expand...
 
Whatsisname said:
you can cheat that and use WinMain (or whatever the hell it is) in a console window and use all the good stuff on windows in console. However, it's seriously frowned upon.
Click to expand...

Well, you can implement that stuff in your regular main() entry point. A console app, by definition, doesn't get a WinMain()-style entry point.

It's not frowned-upon; or, at least, I don't know who frowns upon it. Lots of apps do it, and many console apps actually must do it; if they use OLE, for example, they'll want a message pump because they might create a proxy that ends up using hidden windows.

But even with a message pump in the console's main() implementation, the keystrokes given to the console window don't go into the message pump. They're input messgaes, and input messgaes are targeted. You'd have to create a real GUI window to get the messages. And that GUI window needs to have focus (and the console window therefore doesn't have focus) so such a slution presents the user with something pretty, well, goofy.

Maybe a system-wide keyboard hook would work. That would be nice, since you don't have to poll.

.B ekiM
 
mikeblas said:
It's possible that polling the keyboard is expensive and takes away time that would be better spent doing something else. If a thread can be created that sleeps most of the time, then reacts when some input is received, you really are better off.

Polling is something a programmer almost always wants to avoid.

.B ekiM
Click to expand...

He's making a Pong type game for personal interest. Time spent on programming threading would be more "expensive" than polling the keyboard in this case.
 
Whatsisname said:
use opengl or something so it can have pretty colors.
Click to expand...

It does have pretty colors :) Download: http://jftesmer.org/pong.exe

WARNING: My "version" is nowhere near complete. It's heavily bugged (but not bugged enough to screw anything up ;) ). If you get to the main game and it's stuck in a "loop" just hit 'q' and it will quit. I am currently redoing the whole thing using OOP. If you would like to see my complete version, just let me know and I will post it "when it's done"
 
Cardboard Hammer said:
Time spent on programming threading would be more "expensive" than polling the keyboard in this case.
Click to expand...

Maybe, maybe not. It depends on what he wants to learn.

.B ekiM
 
Zalbag said:
It does have pretty colors :) Download: http://jftesmer.org/pong.exe
Click to expand...

wow, I was expecting something a lot more basic. The ball only moving when you hit a key is kinda funny :D

How you implement the solution to this at this point really just comes down to what you want to get out of it. Simplest solution would be to use kbhit() like was suggested by someone (don't remember who). This will work but will be a bit laggy and you won't really learn anything new. Multi-threading it would probably be the best solution, but depending on your skill level could be difficult. Learning to handle multi-threaded applications is a very important skill to have if you are looking at getting very deep into programming. Or you can delve off into one of the many multimedia interfaces: directx, opengl, mmlib, etc.

If you want to get really sick, you could just re-write it as a windows application with MFC since you using visual studio.
 
try
#include <windows.h>

#define KEY_DOWN(vk_code) ((GetAsyncKeyState(vk_code) & 0x8000) ? 1 : 0) //Get Keys pressed

and to use it if(KEY_DOWN(VK_RETUN))
do stuff
 
You must log in or register to reply here.
Back
Top