Printable View
Hey,
I'm working on a 2-D game currently where i'm stuck in the mid-way. The problem is that i'm unable to implement a timer which executes with another function simultaneously. I know i have to use threads but i'm a beginner and i don't have the slightest clue on how to initialize threads. I'm looking for something other than threads which can get me out of this.
Any help would be greatly appreciated.
Additional details: OS-Windows 7 and platform is Emulated turbo C
> Additional details: OS-Windows 7 and platform is Emulated turbo C
Here's an idea - ditch the 20+ year old fossil and get a compiler that is compatible with your real operating system.
> The problem is that i'm unable to implement a timer which executes with another function simultaneously
Why don't you do everything in a single thread?
Most people seem to head for threads when they should be looking for the appropriate non-blocking calls.Code:do {
if ( keyPressed() ) {
ch = readKey();
doPlayer(ch); /* do something with the player */
}
doNPC(); /* do something with all the NPC's */
dead = checkGameOver(); /* still alive? */
redrawScreen(); /* redraw the screen */
/* sync or wait - keep smooth updates and a decent frame rate */
} while ( !dead );
I would get MS Visual Studio (Express) and XNA (game development) framework, both are free.
XNA will take care of many of the 'under the hood' things like this, saving you a lot of time.
Unless you have a reason to use C (over C#).
@Novacain - I have to use turbo c..there's no other option for me..:frown:
@Salem - If i execute the whole thing in one thread..what is happening is after i press a key the timer is getting executed but the next key pressed is only being detected after the time has elapsed :frown:
> what is happening is after i press a key the timer is getting executed but the next key pressed is only being detected after the time has elapsed
Then you need to write it in another way.
You implement a timer as some counter which gets incremented by a small amount each time around your game loop.Code:do {
if ( keyPressed() ) {
ch = readKey();
doPlayer(ch); /* do something with the player */
}
doNPC(); /* do something with all the NPC's */
dead = checkGameOver(); /* still alive? */
// a non-blocking approach to timers
if ( ++clockTimer == 50 ) {
// update the HH:MM:SS display string
updateGameTime();
clockTimer = 0;
}
redrawScreen(); /* redraw the screen */
/* sync or wait - keep smooth updates and a decent frame rate */
/* Let's say that whatever it is, it results in a frame rate of 50Hz */
/* which means this loops every 20mS */
} while ( !dead );
thank you Salem :) i got that code executed..but i have another doubt..what is the timer has to show ticking seconds..??:confused:
If you have a timer in a game that has to show ticking seconds ... use the wall clock time for it? Via the gettime() function?
If you are wondering about how to do say 11:59, where the colon blinks on and off every second, then look at the ti_hund field (hundredths of a seconds) in the structure gettime() fills in. If it is less than 50, draw a colon, otherwise draw a space.
If you want N periods in a second, then draw a colon if ((.ti_hund * N) % 100 < 50), a space otherwise.
@Nominal Animal - remember, the OP is working in "emulated TurboC", so it's twice removed from being anywhere near a decent system.
I remembered; the gettime() function should be available in that environment.Quote:
Originally Posted by Salem
It's frigging frustrating, though, to work in such an environment. It might be interesting if it was for a purpose -- say you're specializing in fixing old factory robots or something --, but I don't think that's the case here (at cprogramming.com) that I've seen; you'd first teach current systems, then the differences to old systems, I think. I believe the choice of "Turbo C" or "emulated Turbo C" is just due to the sheer stupidity/laziness of the instructor/institution, and an absolutely colossal waste of resources.
Not just because these students will learn stuff they won't be able to use in real life, but because they will have to un-learn the bad habits they will learn, before they can learn how to work with current systems. That unavoidable un-learning step is the one that really makes me sad: just think of the wasted effort and the amount of frustration that ensues, for absolutely no gain whatsoever.
Worse yet: these programmers may eventually write utilities and applications that I will use, and I will get frustrated on how often they crash and how bad their user interfaces are. No, I find that unacceptable. If others want to torture themselves, let them; but keep them away from the open marketplace where I might be accidentally subjected to their twisted, sick output.