Hey. Thanks for all the feedback so far.
I think a lot of the issues are because I designed the physics really poorly - and is reliant on your framerate (which is REALLY BAD practice). I'll look into trying to fix - but sorry for any of the issues you've run into and I appreciate the really good feedback so far.
Agreed that tying anything but display updates to frame rate is a very bad thing. Better to have a stable and reliable "master clock", such as one with a period of 100 milliseconds (small enough that only bad "system lag"/overload would be apparent o human perception). Ideally, that should be he only clock anything is "tied to" -- even the frame rate should be based on the master clock. Likewise, the main game loop, event detection, event processing (keep detection and processing as two separate steps! That way, in a shooting game for example, both entities shoot each other simultaneously, both get detected _first_, then handled after all other detections), and idle hand-off (giving time back to the OS so it can handle other system and user tasks, screen updates, etc.), should all be based on the master clock. In a complex system, you could assign each to a separate thread and/or CPU/core.
As a start, I suggest you search for and read Robert Nystrom's "Game Programming Patterns" (You can buy it in print, of read the free version online).
