Jump to content
  • Advertisement
Sign in to follow this  
graveyard filla

"non blocking" console input ?

This topic is 5463 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

hi, im currently working on networking my old pong clone... anyway, i want to give the server some commands, but the problem is that cin >> doesnt return till the user puts in input and presses enter. is there some way to rig it so that its "non blocking"? i guess i could just take input w / SDL, but its kind of a pain to get the raw input and stuff using SDL so id rather see if theres some other way to do it. thanks for any help.

Share this post


Link to post
Share on other sites
Advertisement
if you are using a console program then you may be able to do (pure C style)


#include < conio.h > // console io

...

int c;

for (;;) {
if (_kbhit()) {
c = getch();
// do whatever you want with c
} else {
// no kb input: do whatever you want
}
}



HTH,

Share this post


Link to post
Share on other sites
Quote:
Original post by Emmanuel Deloget
if you are using a console program then you may be able to do (pure C style)
Nonstandard and platform-specific.

Fact is, non-blocking console I/O is nearly an oxymoron.

Share this post


Link to post
Share on other sites
so basically the only way around this is threads? also, why is it an 'oxymoron' ? do you think its a bad idea for me to do this or something? like i said, its for a server for my pong game (but will soon be expanded to the server for my 2d RPG), and id like to be able to do things on the server like type in commands such as "ping so and so" or "display users" or "kick soandso", etc.

thanks for any help.

PS - if threads are the only way... are they really that big of a deal to learn / use? ive never even tried to learn them before because i've had no use for them. are they tricky to use or is it pretty much strait forward or what?

Share this post


Link to post
Share on other sites
SDL will let you deal with threads in an easy and cross-platform manner. The important thing is to make sure both threads don't try to use a variable at the same time. For example, if you have a string storing the command the user wants executed, you want to make sure the main thread doesn't try to read it while you're in the process of setting it, or you don't try setting it while the other is reading it. You would use a mutex for that. You lock it before you use it, and when you're done with it, you unlock it. If the other thread tries to lock the mutex, SDL_LockMutex will wait until the first thread has unlocked it before returning.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Threads are dangerously easy to use badly.

It takes ten seconds to fire off another thread and half-assedly synchronize it with your main thread using common variables - and it'll probably work in 99.9% of cases. Problem is, unless you know what you're doing you'll end up with a program that crashes once in a blue moon, or only on other peoples' computers, due to a timing issue.

Read up on synchronization and concurrent programming and you should be OK. Despite what Oluseyi said, though, if you aren't worried about platform independance _kbhit() will do the trick. Even if you are, just #define WaitForKey _kbhit and use #ifdefs to switch in the appropriate value for the current platform.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
If you don't care about being platform independent, this will work on *nix-based machines. I don't know what headers include it, but it's part of the sockets implementation



fd_set read_fds, master; // File Descriptor set
struct timeval tv;

tv.tv_sec = 1; // Seconds
tv.tv_usec = 500; // Microseconds (NOT milli)

FD_ZERO(&read_fds); // Zero both of the structures
FD_ZERO(&master);

FD_SET(STDIN, &read_fds); // Add sockets to the set in the same manner.

master = read_fds;

for (;;) {

// As soon as data arrives on STDIN or another socket in
// the fd_set, this function will notify you of it, if
// nothing happens after the time specified in the timeval
// structure, execution continues.
select(STDIN+1, &read_fds, 0, 0, &tv);

if(FD_ISSET(STDIN, &read_fds)) { // Check if there's input from STDIN
// There's input, do something with it.
}

read_fds = master; // Reset the File Descriptor Set
}

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
Despite what Oluseyi said...
That's not despite what I said, that's exactly what I said: "Nonstandard and platform-specific."

The console is a largely serial mechanism, so the facilities designed for it are designed around serial processing. Asynchronous processes, events, etc are more naturally suited to an asynchronous user environment (duh) like the GUI. All the posts after mine have merely confirmed my assessment.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!