Well with mechabirdo, using time obviously is an issue because I didn't realize that I was building the game around a 'tick' model instead of a 'real time' model so I didn't see the problem in mixing them. For stuff like BEPRO, I'm never using time calls. I'm measuring things by ticks. So if there is lag, the game slows down and that's just the way the cookie crumbles.
I generally don't like using times like delta time because you get movement that isn't totally predictable. For example if you have a jump that's like, every frame, set y to like...
player.y - (jumpheight * (timedelta * 60))
The * 60 is nice because it makes the timedelta roughly around 1 when running the game around 60fps and makes a lot of numbers make more sense. But whatever. So lets assume on a normal frame it looks like..
player.y + (jumpheight * (timedelta * 60))
(436) - ( 10 * (1) )
So we get a position for that one tick of 426
So lets craft a totally impractical situation where it takes 5 frames to get to the peak of the jump and theres no gradual acceleration or deacceleration. If we do this 5 times, we get 286. If the game is running only a 30 FPS, what happens?
(436) - (( 10 * (2 (due to the lower frame rage) )
This makes us move 15 frames per tick and what was 5 ticks at 60fps is now...... 2.5 ticks? Yikes. So our final position in the air is either. 296 or 276, both of which are 10 frames off of what we want.
In a real world situation, with jumps that go on for awhile and bigger numbers, the variance can be as low as a pixel. That can still matter, but it can be designed around. But here comes another nasty situation. Lets say the game moves at 60 fps and then like, near the top of the jump arc, the game lags -- especially if it lacks for a moment into the 10s of FPS. You can get a significant jump boost from there. Now you can limit that too by say, capping the minimum FPS at 30 (anything under 30 produces slow down) but still, this all adds to a lot of uncertainty. When working on BEPro, the NES style made me forgo all of this. Every pixel matters when your character can precisely jump a 48 pixel gap. It seems more legitimately NESy too.
There are other tricks and work arounds too that might show up in future games. One method is controlling how much something's logic loops and mix that with time delta. For example you can have the player's platform code run like, 180 times per second. At 60 frames per second, the platform code for the player will run 3 times. at 30, it'll 6 times and at 120 fps, it'll have to well, alternate the amount of updates each frame. But in practice it shouldn't be so hard to notice gives you totally reliable jump arcs and stuff. You can then use standard time delta for things that don't particularly matter much.