[опять 25] Таки хочу накалякать игру

Я не понял в чем я не прав? то о чем я твержу это почти стандартный подход в написании любых приложения, как минимум под винду.. а еслиб весь софт гонял бы в циклы по своему усмотрению, все бы тормозило и грелось. Я не спорю что программы в конце концов работают циклично, потому и не завершаются, но если например у вас есть окно и на нем выводится статичная картинка, стоит ли перерисовывать ее каждые 100мс, или же нужно дать ОС решить когда тебя перекрыли и пусть вызывает функцию только тогда? конечно второй подход..

Я не понял в чем я не прав? то о чем я твержу это почти стандартный подход в написании любых приложения, как минимум под винду..

В идеале программа должна хорошо работать в широком диапазоне фпс. Можно работать со временем записанным нецелым числом и ничего не параллелить, дело автора, можно делать и так и так.

а еслиб весь софт гонял бы в циклы по своему усмотрению, все бы тормозило и грелось.

В главных циклах нужно делать саморегулирующиеся паузы и регулировать частоту выполнения как тебе надо. Потоки в первую очередь нужны потому, что расплодилось много библиотек требующих чтобы их делали ядром программы, или даже однажды включив, их невозможно выключить кроме как вместе со всей прграммой (есть метод run но нету close), потому что основные пользователи используют их для клепания морд и им отключения не нужны. Если не хочешь писать программу вокруг библиотеки или гуйтула то нужно пихать их в поток, ничего лучшего не придумано.

но если например у вас есть окно и на нем выводится статичная картинка, стоит ли перерисовывать ее каждые 100мс, или же нужно дать ОС решить когда тебя перекрыли и пусть вызывает функцию только тогда?

В таком случае нужно дать движку указание не стирать предыдущие кадры и, если тебе новый кадр не нужен, делаешь в рисующем цикле прыжок (goto, если кто не понял) от начала к концу, в котором находится sleep(x) Происходит копипаста предыдущего кадра но счётчик фпс покажет что кадр отрисован. Вопрос в том, что не всегда заранее известно, будет ли этот кадр отличаться от предыдущего (может боты решили что-то там замутить пока ты ворон считаешь) и нужно ли делать прыжок.

Ты не поверишь, но в любой программе под винду есть цикл. Просто он может быть спрятан внутри фреймворка. В винде следующая итерация цикла начинается, когда что-то случилось, в игре, когда прошло 1/FPS секунд. Разницы никакой.

у вас есть окно и на нем выводится статичная картинка

Речь про игру, где картинка статичная разве что в меню настроек.

Да ребята причем здесь игры,тактики написания кода для всего одинаковы.. Все о чем я говорил основывается на былом опыте писания под винапи(правда давно это было), там даже для открытия простой форточки из-под чистого апи нужно задать коллбэк функцию.. для таймеров тоже (это и есть нормальный способ задания "цикла"), кстати есть и мултимедия таймеры - очень точные.. Все это широко используется, потому что очень логично Реагировать на события (пусть и таймер), нежели постоянно проверять ввод.. Я много чего подзабыл так как много лет ничего не пишу, пускай меня поправят те, кто активно кодит, только скажу что в моем подходе ничего нового нет и не привязан он к фреймворкам (если ОС за такую не считать), даже под ДОСом было такое, не помню как называлось, можно было создавать такой код(софтовые прерывания), который вызывался автоматически при некоих событиях, так писали резидентные программы работающие прозрачно -антивири, или русификаторы клавиатуры,... О многопоточности и речи небыло тогда!

кстати есть и мултимедия таймеры - очень точные..

Рад что где-то можно задавать точные паузы в микросекундах не нагружая при этом процессор.

потому что очень логично Реагировать на события (пусть и таймер), нежели постоянно проверять ввод.

В этом случае ты не можешь управлять событиями. Не можешь их генерировать, стирать ненужные до обработки, нет, если пришло 100 ненужных событий то отрабатывай в порядке очереди или изобретай «забиватель болта». А ввод можно проверять не всегда а только когда надо, не объясняя системе подробностей.

даже под ДОСом было такое, не помню как называлось, можно было создавать такой код(софтовые прерывания), который вызывался автоматически при некоих событиях, так писали резидентные программы работающие прозрачно -антивири, или русификаторы клавиатуры,... О многопоточности и речи небыло тогда!

Благодаря Билли ДОС не успел развиться до нормальной многозадачной ОС но вплотную к этому подошёл. Ещё десяток лет развития и всё в досе появилось бы. Думаю и у тебя также, если не забьёшь, то через несколько лет захочешь и движки и потоки, и кнопку «сделать зашибись». Сделай демку с одним объектом и отпишись о результатах.

если пришло 100 ненужных событий то отрабатывай в порядке очереди или изобретай «забиватель болта»

В каком случае может прийти 100 ненужных событий?

Использую события для всего — и для ввода, и для сети, и для графики. У меня был долгий путь к текущим принципам построения приложений, но они работают идеально и просто и в сложном сетевом приложении с тяжелой графикой и анимациями, и в 200-килобайтных программах для телефонов с 200 мгц процессорами и тормозной jvm.

В каком случае может прийти 100 ненужных событий?

Жму на кнопку в гуёвине, запускается окно с графикой, гуёвина блокируется ибо больше не нужна а выключить нельзя. Графика отработала, её окно закрылось, гуёвина разблокировалась и тут же начинает обрабатывать лишние клики случившиеся до запуска гуёвины.

Использую события для всего — и для ввода, и для сети, и для графики.

Попробуй использовать классы не так, как того хотят авторы - столкнёшься с ограничениями и неидеальной логикой которую так просто не исправишь. Если пропатчишь исходники базовых системных либ, то получишь несовместимость с новыми версиями, оно тебе надо?

Не знаю, у меня в основных приложениях все свое (и ввод, и графика, и сеть, и интерфейс), так проще. Так что использую классы именно так, как хочет автор)

В сторонних библиотеках — да, часто бывает, что навязываются определенные ограничения к возможным подходам написания приложения. Но у их разработчиков есть на это право.