clarry: dtgreene is a technical person and so am I. The devil is in the details, and I believe we both find it interesting to discuss these details. I'm sorry that you don't.
ColJohnMatrix: lol Excuse me,
what? I already did and added
actual code that provides a working example. Your response stepped beyond that into the realm of criticism, obvious condescension, and strawman, and frankly I've seen nothing from you giving you the credentials to do so. You're some unbelievable piece of work...
But, by all means, show your code sample that's a vast improvement... I'm waiting.
I don't understand why you take it so personally. I'm just pointing out technical deficiencies in the approach you present, nothing more. The purpose is education (the very point of this thread), not condescension. There's no need to get upset.
I'm not interested in boasting with credentials but I do software for a living, anything from kernel & drivers to userspace. Dealing with these sort of details is something I do and have done for >two decades. And yes I've fixed games that run bad because of bad design. And yes I've debugged issues that come down to interaction with the scheduler or poor timing mechanisms. And yes I've written game loops.
Of course you wouldn't take my word for it, so instead of trying to convince you, I'll just point out that I'm not the only professional developer who has come to the conclusion that it's a good idea to yield the CPU:
https://github.com/TTimo/doom3.gpl/blob/master/neo/framework/Session.cpp#L2588 Sadly, Doom 3 has other sources of jank (that can be worked around)...
You're conflating multiple issues, somehow attributing them to this approach (et al), and then by proxy deflecting to me for demonstrating... What you seem to fail to grasp is these things aren't the issues that you think they are. Not unless you're working on a much larger game design or something for modern consoles where it becomes critical.
It's more like you live in the same fantasy world where (unfortunately) many hobbyist game developers live, they don't understand operating systems much at all and just see an idealized view of the abstractions it presents from the application's perspective. In such a world, it's fine to pretend the scheduler does not exist and won't pre-empt your process that never yields. It's fine as long as you don't mind the performance implications or don't care that it'll needlessly stutter on some systems and drain the battery and run hot.
Size of game doesn't matter, in fact simple 2D games that *should* run perfectly but somehow have jank *and* make the CPU fan on a low-end laptop scream for mercy are what really made me want to dive into this shit. Big, complex 3D games often have so many other sources of jank going on that it doesn't matter much (and again they can just blame peoples' hardware whenever there's some issue, without even trying to understand it). Of course, at some point big and complex 3D games age and become old and simple 3D games and players realize the code could be better:
https://github.com/ioquake/ioq3/commit/e5dbce839a478038297a2d7e13fad234b7ac1286
A vast amount of games use the same technique listed above with minor tweaks, generally adding delta physics, and the things you seem to think are issues just aren't. In short, your thoughts on this are vain nonsense that sounds great on paper but doesn't hold up to obdurate practical reality. You think you're "being technical", but you're just being pathetically pedantic without cause.
This "pedantry" does not come from paper or ideals, it comes from experience with real software (including games) and OS kernels.
I'm becoming convinced you guys have Aspergers.
Assburgers is a curious way to spell experience. But I like it.