I'm not sure how this translates to ECS architecture - probably depends on your library, but if you're in charge of the main loop it shouldn't be a problem.

This reminds me of:

https://thedailywtf.com/articles/Hidden-Tax-Moves

"Wait, let me try," Bruce said, grabbing the mouse.

"Whoa, what just happened?" a teammate exclaimed. "What did you do? A ton of traffic just came through!"

Prove that the story is real ;)

At one company we had a deployment script written in English. That support from India would execute. Except they would occasionally inject their undocumented codes to fix their own issues.

That and the component oriented distributed monolith that ran on single machine. It was monolith architecture but it was made to run on multiple machines. However it was never distributed and starting the components was an arcane science.

I feel like game programming in general is one big "we set a global variable" :)

You would implement it almost the same as a standard Windows GUI -- using an event handler loop that marks the screen as "dirty" and needing a refresh if it has changed.

Where it would immediately break down is ongoing animations. If you stopped moving your mouse, then animations would stop. Of course, you can set up the event loop to continue triggering if there are animations going on, but then you basically have a standard game engine loop running most of the time.

Personally, I'd be happy if games simply paused rendering when minimised. Some games do this, some don't.

Thanks for entertaining the idea!

But yeah, games don't need to render any frames while minimized. I do feel like this should be the operating system's responsibility as well, but then, a lot of games still have the graphics rendering and other parts of the game linked tightly together.

Yes, please.

It drives me nuts to have GPU fans spinning when game is minimized, paused, in the loading screen, turn based and no inputs, etc.

Here's an example using it, it's well suited for "desktop applications", the shorthand to use it is `desktop_app()` https://github.com/bevyengine/bevy/blob/1c5c94715cb17cda5ae2....

https://github.com/bevyengine/bevy/

The OP only mentioned that he wanted to stop outputting frames. Animations, physics, input, etc should still happen normally.

game loops usually call into simulate and render entrypoints.

There's state potentially mutated by simulate.. render looks at that state and potentially produces a new output to present on-screen.

Typically the render entrypoint returns a status indicating whether a new output was produced or not to put on-screen. If no output was produced you don't flip pages. So in a quiescent situation with nothing changing, render returns "don't flip" and you just leave the existing page displayed til the next iteration.

How you track the internal game state / dirty vs. clean state is implementation detail behind those simulate and render entrypoints and depends greatly on the type of game.

That's probably oversimplifying it, I don't know anything about graphics programming.

Event queues are used to track things in long duration across multiple frames, like user input, animation sequences, sound sequences, pending state update, pending physics update, pending AI update, etc.

In each frame, check the event queues. If they are empty, sleep. Otherwise, process the events in the queues. For user input, do the state update correspond to the input, like update the camera position.

For ongoing animation, advance the steps in the sequences. When an animation sequence completes, remove it from the queue. Same for sound.

For pending state update, run the update. E.g. the ship is moving, do the state update on velocity and position. For ECS, you might end up calling or not calling the systems for the item type for batch update. E.g. when the bullet queue is not empty, you might just run the bullet related systems over all bullets for simplicity. When all the bullets end and the queue is empty, the bullet related systems are not run.

The physics queue would have items being simulated. Run those. Physics could run at a slower rate like 5fps, so the queued items can be skipped most of the times. Same with the AI items in the AI queue.

Whenever there's a state update, mark the screen as outdated. At the rendering step, run rendering if the screen is outdated. It's simpler to just run the whole rendering for any change. Ideally, when there's no events in the queue or the state updates are not triggered, there's no need for rendering.

This applies to using ECS or not. ECS is for tracking states of entities and do batch update with systems.