Timing executable inside

Miscellaneous Forums/General Discussion/Timing executable inside

The Forum Archive is locked. These are the original blitzbasic.com forums, kept so their posts can still be read and searched. No new topics, replies or edits can be made here. To join the conversation, head over to the Blitz3D+ forums.

Done.

Basically I hooked up my favorite test machine. I had to hunt for wires and so forth but here goes... it's a P2-400mhz machine running windows 2000 and a TNT1. Yep, the old crummy first TNT card.

With my timing code, it is smooth as silk, truely smooth on all flip modes with 100 objects regardless of settings.

I tried the Torque 2D shooter demo and it slowed down to the point of locking up, so that proves what a lame platform that is.

In my timing demo, I noticed something though. It looked vaguely *still playable* at 1000 objects, but a little over, say 1,200 objects, it began going slow-large steps-slow, and so on.

I narrowed this down pretty quickly to the timing of Millisecs(). You see, I have a portion of code that detects discrepencies in millisecs.

If your time difference between the last call to millisecs and this call is over 200ms (about 5fps), it resets my timing routine. This works a treat for dragging the window, or any misc delays.

However, my finding is, for a puzzle game, 5fps is still acceptable! This is because the mouse isn't delayed and you can still interact just fine with it. What are your thoughts on resetting time if the difference in millisecs is large?