In regards to having more draw steps than update steps, I agree that it would be peculiar, but there may be situations there it theoretically could be useful. For instance if you interpolate between two consecutive game states (I have heard that some physics simulations support interpolating between two states, though I don't know much about it), or extrapolate from the previous game state. I agree that it seems like a lot of work and a lot of complexity and potential issues for no or very little gain, but it is still something that has been talked about. But I don't have any beef with not bothering with it in any way
.
In regards to sleep functions that have a granularity of 1 millisecond or more, it is only impossible to get a higher framerate than 1000 if you sleep in every step. As IsmAvatar mentioned before, it is possible to fudge it by not sleeping in every single step, and this is what I implemented some months ago when seeking to improve the fps-handling for both Linux and Windows. That is also why it has been possible for some time now to get a fps of more than 1000 on Windows even when the implementation used Sleep.
In regards to whether the fps issues have anything to do with different rates for the updating and the drawing, I agree, but they do have something to do with the fps-handling in general, at least if you want to support it in the engine. And that can be useful. If you just call screen_redraw() 5 times in an alarm event, you risk the draw events not being properly spaced out, depending on how fast drawing is and how many resources there are available. And that can be difficult to deal with correctly and accurately manually in the game, and much easier if done at the engine-level. But it seems that we agree that such functionality should not be supported by us, so that case is closed. Besides, if someone really wants to do that, they can always fork, modify and extend their version of ENIGMA.
Josh, I don't understand the point you are trying to make regarding the CPU scheduler. First, I think the CPU scheduler you describe is not generally representative for the CPU schedulers found on Linux or Windows. For instance, look at the CFS (
http://en.wikipedia.org/wiki/Completely_Fair_Scheduler) CPU scheduler for desktop Linux. According to the Wikipedia page, it does not penalize processes that sleeps a lot, but tries to ensure that they get their share of the CPU when they need. Your description of a scheduler that puts the program to rest until the user interacts with it if it calls sleep too often seems very wrong. If I call sleep(1 millisecond) in a program once in a while, I think it would be utterly horrible if the CPU scheduler with a CPU not under heavy load just decided to put my application randomly on hold for several seconds because the user has not interacted with it. I really don't think there are any CPU schedulers out there like that. I also don't know how useful it is to use a GUI program like a calculator as an example of what will happen; a GUI program like that with no non-user-activities (apart from the rare sending of information of usage data, but that can be implemented by using a timer and getting events that way) waits on external events instead of sleeping, and just let its framework redraw things for it. I don't know if I understand you correctly, or if my description and understanding here of CPU schedulers and all that stuff is accurate, it has been a while since I looked at CPU scheduling.
Second, I don't think how the CPU scheduler schedules things should have much impact on how timing happens. As long as the CPU scheduler is somewhat rational and efficient, I think it is fair to expect the fps-handling to have full fps when there is no load on the system or the game, and degrade smoothly when there is some load. This also brings me to other requirements for the fps-handling. Apart from having full fps with no load, and degrading smoothly under increasing load, I also have the requirement that if there are sudden stops, ie. one step taking far too long compared to other steps, that the fps-handling does not suddenly go through a lot of steps, causing the game to jump a lot in time, in order to catch up. It took a while and a fair amount of work, discussion and feedback to get it right, but I think the current implementation fulfills those requirements pretty well.
In regards to the users' expectation, while it is not smart of them if they expect their game to run at full fps independent on the load or the machine, I do think it is fair if they expect the performance to degrade smoothly if the game is run under stress and/or on a machine with few available resources.