high resolution love.run function for 0.8.0

[raidho36]

That returns control to the OS requesting resume execution ASAP. Pretty much the same as sleep ( 0.001 ), but explicitly specifies not to wait any extra time, be it even mere millisecond.

[Davidobot]

If you only send one horse carriage of mail per week, a horse carriage is good enough... unless you actively run into a problem with an implementation or find something worthwhile to improve, there's no need to improve anything.

Why are you arguing? If you want to use this tweak, use it if you don't want to use it, just don't use it. Also, I actually agreed with raidho36, if something works, that doesn't mean you shouldn't get sometime better or more efficient. Just look at Nuclear Energy, it is good enough, but Fusion is the way to go.

[davisdude]

I don't think it's not that we don't need a better love.run function, it's that on old/bad computers, calling it so many times would only lower the framerate and game speed.

[Boolsheet]

That returns control to the OS requesting resume execution ASAP. Pretty much the same as sleep ( 0.001 ), but explicitly specifies not to wait any extra time, be it even mere millisecond.

The way you describe it sounds like it's wasting cycles for no reason.

You want to relinquish the time slice, right? There are several issues with that. Giving up the time slice only makes sense if you know that there are other threads that are applicable and ready to take it over. Otherwise you just fuck with the scheduler and cause additional overhead. Only the Windows Sleep function implements this behaviour and the other implementations of SDL_Delay may just sleep 1 ms instead.

Unless you have the complete picture of what's executing on the system, it's probably best to trust the scheduler.

[kikito]

Looks like my habit to conduct counter-constructive conversations with little to no valid argumentation and attempting to point out others' mistakes out of nowhere bites pretty hard.

Your habit of writing in a harsh tone to people disagreeing with you bites much, much harder. You are derailing your own thread with personal attacks.

Be efficient. A little work on social skills would benefit you greatly. For instance, your code would be better, as you would get more feedback. So put some effort there.

That returns control to the OS requesting resume execution ASAP. Pretty much the same as sleep ( 0.001 ), but explicitly specifies not to wait any extra time, be it even mere millisecond.

Actually, that risks blocking some threads out (those with lower priority than the LÖVE thread), at least on windows. See

http://joeduffyblog.com/2006/08/22/prio ... t-manager/

[raidho36]

Thanks for the input, kikito. I didn't knew this little fact about sleep function. I searched issues associated with it and come to a conclusion that it's actually only an issue in theory, reproducable, but with chances of actual encounter in real life right next to zero. This theoretical issue stems from the fact that sleep(0) requires another thread to be scheduled for running to give up CPU slice, and if priorities are messed, there could be no other threads schedueld, which results in 100% processing time consumption and starvation of all other threads. In reality, everyone strongly discourages everyone from changing default priorities, because even without this little thing, it causes a lot of problems. The only reason you would change the priority is absolute and dire need for your app to be realtime, such as nuclear plant power core data processor program, which can't let any other app occupy it's processing time. Programs like system daemons might have different reasons, but still, setting high priority means that your program would rather other programs starve than give up it's slice, and setting it to lower means that being CPU starved for undefined amounts of time this thread is perfectly okay situation. Additionally, Windows has daemon that resolves threads starvation.

The video game in default priority that runs on generic PC is not the case where this kind of problem could possibly arise. Not within LÖVE's implementation. But thanks for clarification.