Event driven vs "game loop"

Hi!

I was thinking about how one would implement a text editor for instance. With a game there is a game loop that checks for input, processes some data and then renders as fast as it can over and over again. For an editor I just assumed that it would be more event driven - nothing needs to happen unless the user does something.

I was also thinking about implementing my own GUI, immediate mode style. Mostly to learn and because the idea seems pretty great. But that made me think that I would probably need a "game loop" for the editor too (for some reason), which in turn made me wonder why not use "game loop" for any and every application? I mean, if games can do it then a text editor should be able to do it as well, shouldn't it? It feels like it would give me much more freedom to do anything. I might just decide that I want my scroll bars to be affected by gravity so that once you let go of it the page will scroll back down as if falling, or add christmas lights to the menu during christmas.

Any thoughts?

/Robert
That's exactly how you write GUI applications on most systems!
1
2
3
4
5
while (running)
{
   WaitForNextMessage/Event(...);
   ProcessEvent();
}

This is how you do GUI events for Win32, X11 (Linux), OSX and even SDL.

Only difference it that for games you want Peek, not Wait for next message. If there is no message you want to update game state and render. For GUI applications that's not really needed. They can use low resolution timers (on Windows SetTimer function) that produces events/messages if you need some action to happen periodically.
Yep, everything that @mmozeiko said.

The only thing I'll add is the in the typically event-driven model, instead of directly invoking the functions to do the processing within your loop code, there is an indirection path that broadcasts the event through a dispatch mechanism. Then functions that have hooked into that event can be invoked.

Otherwise, it's all pretty much the same.
I'm sure this has been mentioned some place or forum but I've never found it.

You can create your own events, like UPDATE_PLAYER, UPDATE_PHYSICS, etc and post them to a window. The events can trigger each other, so the UPDATE_PLAYER event handler can post a UPDATE_PHYSICS when it completes; or it can post another UPDATE_PLAYER or any other event it wants to. You can post more than one event and string them together.

The trick is how to sequence the events. You need to insure that the message queue is never empty but you could simply default to UPDATE_PLAYER.

- tim
Why would you want non-empty event queue, if you are writing text editor?
Empty queue makes process go to sleep, so it doesn't use CPU. This means lower CPU temperature, quieter CPU fans, and longer battery life on laptops.
Hmm. I think I misread the post. I thought the idea was to mimic a game loop that uses PeekMessage.

An editor has a static display between event and is reactive so you would want to yield back to the OS with no input.

- tim