Which graphics are you using.

>thanx in advance.
For what? You didn't ask a question. You totally overused periods, but I don't see a question mark anywhere in your post.

What you talk about is not called "parallel programming" but event-driven programming. Event-driven programming is common for graphical programs which use widgets and windows. I wrote a snippet using GTK http://www.daniweb.com/code/snippet737.html where you can see how the event-driven program works. You can use GTK drawing area if you like, but the general principles are the same. There, in the end of the function main, is a loop that is called a "game loop", which is for anything that has to happen all the time continuously. But you see that the special functions shall be registered for events, such as key press, delete and destroy. These functions are called the event handlers, so that when some event happens, the function which handles that event would be called, while the main loop would go ahead as if nothing happened.

I'm sorry for replying so late, but i couldn't explain more before, because there were not much programming examples for such graphics games. Now i made one and posted here in snippets, a GTK version of the original xasteroids (which was written with xlib) http://www.daniweb.com/code/snippet744.html

In addition to keyboard input etc, you see there, that a frame is prepared in every game loop, and then the expose event would be ordered to write the frame on window. The frame is made in pixbuf, which is nothing else than a picture in memory, the pixbufs can be copied into each other, modified in various ways, and loaded from image files of different formats, or embedded into the code as strings. There is also a thorough collision and bouncing implemented, this could though be a simpler one for the round objects such as asteroids, but it could be good for the objects with less round shape, so maybe that too would be useful for you when writing a cricket game, or for anyone who wants to write a similar game.

As i said earlier, GTK is a good thing to use, if you are not going to write 3d games, because GTK is free, not anyhow commercial, and truly cross-platform, and it's useful to learn it because it is also a good api to write graphical user interfaces, such as various dialog boxes and menus, the gnome desktop and many other important applications were made with it. Therefore i think that GTK is the best graphical api for these who learn c programming. Some say that GTK is slow for games, but such opinions must only be based on some superficial knowledge about GTK. Why one may claim that GTK is slow, is because GTK has to deal with so many things, such as menus and dialog boxes, it certainly spends more time in every loop for processing these things. But say that you want to make 20 frames in a second in game, then very insignificant percentage of time would be spent for system processing, and drawing the picture in memory is not anyhow slower than with any other graphics api.