Sorry your browser is not supported!

Would anyone find an interrupt-driven increment or decrement of values. You supply the time frame, start time and amount to increase, and then read the required value at anytime.

i was thinking how useful this would be a few weeks ago, can i have one?

I expect so.

I was thinking along those lines with how one may design a whole game. Where each "thing" "does" whatever in relation to "TIME" not cycles - So When its time to render - or poll info or whatever - its where you expect it to be regardless of machine clock speed.

Yes, that's an excellent way to design a game. That way, when someone comes along 5 years from now with a computer that's 20 times as fast, they just get 20 times the framerate, instead of the game going to fast to play.

I don't think you really need to use interrupts to implement what you're asking for. I'd set up a couple of arrays, VALUE and INCREMENT. VALUE will hold the current value of each variable, and INCREMENT will hold the amount it should change by, per second. Then, each time through your game loop, check how much time has passed since the last time through (call it INTERVAL). Then, for each element, say VALUE(n) = VALUE(n) + INCREMENT(n) * INTERVAL.

Hmm...I just realized that if you're limited to a resolution of 1 milisecond, errors will accumulate rapidly. It would be better to just keep track of how many miliseconds have elapsed since the start of the game and calculate from that. You'd need to keep track of an extra set of data if you want to start the timer in the middle of the game, but it's not very complicated.

Yeah - basically - I've done a similiar thing when playing around with the language. I would basically grab Timer() value at beginning of my loop and each entity would compare this to a previous loop iteration's timer() value. (save the new time as the old time for next one - but save the difference (elapsed time) first because that's what I use to base my calcs on. If you want fluid motion - you would use the "elapsed Time" to calc how far it should travel - or animate - or whatever - or for a simpler - less fluid depending on what your doing (and simpler) is if TimeElapsed > TimeInterval then DO whatever

Any one who has done Windows Programming (message loops) might kinda see how this works - rather for polling for messages - you nail all your "entity" routines - and each only executes if its time to do so.

The hard part about all this is each entity routine has to be smart enough to deal with 1: more time elapsed then you planed for - possibly meaning two steps are warranted - (like the millisecond thing you mentioned) - 2: Each Entity Movement needs to "step" oriented so it doesn't bog down the other entiries - EXAMPLE: if you want to move a limb - and give a big bird to elmo - your routine needs to be smart enough to do it one step at a time in a similiar manner - if you just move it - it will not be fluid at all.

This is where my days of writing multi tasking OS code comes to mind sorta. This also brings the concept of multi threading to mind. That's where one program can have multiple little programs all running at the same time and you can check the status of any one of them you want - and they can even be started and forgotten just to clean themselves up - EXAMPLE: Blow Up Bad Guy Thread - Automatically handles the explosion - removing the dead dude - the noise - meanwhile your FirstPerson has already left the room and you can still hear the dying dude screaming and your main loop doesn't even bother with it - its a dead issue .. hehehe

To summerize: We can't use threads (i dont think ) in DBPRO: So writing routines in a "per Step" basis - using timer() as reference point - you can simulate a truly multi-threading application- though this requires work for sure BUT your Program WILL run virtually identical on a system 20 years from now - Wish they did that to old Wolfenstein - A Classic

He goes so fast (good CODE!) my monitor would probably catch fire if I tried to play that now hehe