Input in timed loop

[glo]

Hello, Im new here, and to programming as well.
After walking through some basic tutorials I thought it would be nice to try something myself, though Ive ran into some trouble:
I'd like to make some simple game that will have a timed tick rate and operate according to it - say the loop only lasts 0.1 secons.
I can make the loop wait for that given time like this:

void main() {
  while (x) {
    printmaze();
    monstermove();
    readinput(c);
    playermove(c);
    wait(time);
  }
return
}

Though I'd also like to read for input - like most games do - this is where I run into a problem: reading for input stops the loop from continuing until it reads it, and I basically want the game to continue ticking no matter what / stop reading for input after x amount of time.

What approach should I be taking? Any suggestions are welcome, thanks.

[n3v]

from an outside prospective, it looks like you're in way over your head. first of all, your answer is different depending on which library you're using. if you're just doing it in a window with gdi or some winAPI, you're going to need to get your input from a message to your window. if you want to get input for a left click, add WM_LBUTTONDOWN to your message loop.

If you don't know what i'm talking about or where to start, go to www.winprog.org/tutorial/.

if you find that impossible to understand, have patience, you'll get it. make a few programs in the command line, and get pretty comfortable with that.

by the way, to answer your question, to time things, use the Sleep() command. when you use it, the processor won't do anything in that operation for the amount of milliseconds you put into the processor. so, for example:

while (x) {
Sleep(100);
dostuff();
}

this loop will run dostuff() after 100 milliseconds, or 0.1 seconds.

[glo]

Thanks for taking the time to look into my problem.
Im not using any library yet, what im trying to achieve is a simple game-like program that will execute under the gnu shell (or dos). For that matter I wont need windows programming, just yet.
If I didnt make myself clear, the functions I posted are just to give you the idea of what I want to do. To be specific, I use a printf() loop to print the maze, usleep() to wait, and getchar() to read input from the keyboard etc.
What I am asking is - how do I prevent my main loop from stopping to read the input, while still being able to read input real time? if this is the right approach of course.

[n3v]

ok, if i understand this correctly, you want a loop to periodically update certain variables in the game, such as a monster location, every 0.1 of a second, but you also want to be able to process input. if you're wanting to program in dos, i don't really know anything about dos programming, so i can't really be of help, but i can say that constantly moving graphics in the command prompt is basically impossible. moreover, in the command line, when it waits for input, the program is not running any functions, it's waiting for you to input something and press enter, then it will continue. actually, i'm not 100% sure that it's impossible to have a process running in the backround of that, but i certainly have no idea how to do it.

[glo]

I see.

Though I am not sure what Im trying to do is actually the way to achieve my goals.
Let's take good old Doom for example - Monsters kept moving even though you did not press a key. So basically, how is it possible to get some input but keep the game going?

I realize this may be beyond the scopes of a simple game-like program. If this is the case, I will have to give up for now. I will appreciate a short explanation or a link to one if it is possible, though.
Thanks.

[n3v]

doom, believe it or not, was in 3d. i'm not sure what graphics library it used, but it was pretty cutting-edge for it's day. shame though, that dos games don't work in newer windows versions (well, i think they do, but you have to download special programs to emulate them.)

needless to say, though, it does go beyond the scope of a beginner programmer. don't fret though, strides forward have been made in the fields of programming since then, making it much easier to create a game like that. however, it's still not suitable for a first program. but i will be happy to guide you in the right direction:

when it comes to the moving graphics that you want, the command line is a big no-no. i mean, some people pull some creative and clever little functions out of their sleeves and make the command line seem a little fancier, but it's still not the way you'd want to go when it comes to graphics.

the first thing i thought when i wanted to move into graphics was "alright, one step at a time, first i'll just try some basic graphics in a windows window." so i screwed around with the win32 gdi for a while. let me just tell you, if your goal is to make games, and hopefully more complex ones in the future, just forget about the win32 gdi. however, if you think you might want to make another kind of windows program, the win32 gdi will probably come in handy. a good place to start is www.winprog.org/tutorial/

Opengl. I'm personally such a noob that i haven't even started yet. however, this is the way you want to go, even for a 2d game. it's a lot simpler than trying to fool around with gdi, and it can be used for almost all game ideas, 2d or 3d. there's a great tutorial here: http://nehe.gamedev.net.
i'm not really one to say, but i think it's kinda complicated. you should have a somewhat solid grasp on the command line before you dive into that, or any graphics, for that matter.

[glo]

Right then, thanks for guiding me in the right direction.
I suppose command line games are not worth the effort when theres an Opengl option.
I will look into Opengl then.
If anyone does find a nice and easy trick to solve this problem I'd still like to know though.

[Quantum1024]

You just need to use a function which checks for keyinput whithout blocking. If your compiler has the non-standard header file conio.h then you can use _kbhit() which will return imediately, true or false if there is a key waiting in the console's input buffer. If there is a key waiting you can then call _getch to get the key.

Windows has GetASyncKeyState, linux might have some functions for doing this.

[glo]

Interesting
If my Cygwin compiler does not have conio.h, is it possible to install it?

[Quantum1024]

If you could do that you'd need an accompanying library to go with the header file and I doubt you'd ever find a portable console library. What is your eventual target platform or do you want it to be portable?

[n3v]

i figured there was some way to get the command line to act all fancy like that, but in all honestly, is it worth the trouble? well, actually, foobar-ing aronud with the command line for your first few attempts probably isn't a bad idea. the important thing is, before moving into the rough stuff, to know a multitude of key concepts: objects, classes, structs, pointers, arrays and the like.

I just think, in my opinion, that doing a bunch of work to get the command line to do that isn't worth it. even though it might still run backround processes, it still can't renew the graphics constantly without getting seriously confusing. if you want to have periodically changing graphics, i just think it's a big mess waiting to happen on the command line.

[Quantum1024]

it still can't renew the graphics constantly without getting seriously confusing.

What graphics? Console applications aren't like DOS, they can't do anything other then text unless you'd count ASCII art as graphics.

[n3v]

i mean like, if he had an ascii art maze, then constantly updated it, to move the person and monster around, it'd have to scroll by every second or two, and it would get seriously confusing.