• Advertisement
Sign in to follow this  

Is Window Manager a part of an engine?

This topic is 1465 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I am designing window management for my engine and I have a dilemma. I don't know if I should make the Window Manager part of the engine, or keep Window Manager as an gateway between user and the engine which sends window events to the engine. And the engine does all the work.

 

In my current design, there is an Engine object, which on its own is a FiniteStateMachine, so its responsible for changing the game states. It also performs the main loop in my game. Then I attach a WindowInterface to my engine (can be SFML or SDL or whatever). The MainLoop of an engine is implemented this way:

int Engine::run() {
    Timer timer;
        
    while(running) {
        auto event = window->pollEvents();
        if(event) {
            if(event->getName() == "closed") stopRunning();
            peekState()->sendBeforeUpdateEvent(event);
        }
            
        peekState()->update(timer.getElapsedTime<Timer::seconds>());
        window->preRender();
        peekState()->render();
        window->postRender();
        timer.reset();
    }
        
    return 0;
}

But I am thinking maybe this design would be vise-versa, where the window sends events to the Engine instead of Engine receiving them from the Window, and the loop happens through the window instead of the engine.

 

So, every simple implementation (whether its SDL or SFML or something else), the "run" function must be implemented over and over; from programmer point of view it sounds more work. But It makes more sense to have something similar to that from Engine Design point of view, instead of more code writing point of view.

 

Please give me advice on this situation. I don't know how to keep it. Its not about anything but the actual Engine design.

 

Thanks,

Gasim Gasimzada

Share this post


Link to post
Share on other sites
Advertisement

Windowing systems are one of many subcomponents inside a user interface system, which itself a is a subcomponent inside the engine.

 

For a major engine it is very unlikely that game objects will directly interact with windows. Game objects interact with other game objects in the world. They might provide some callbacks as part of a base class that can be overriden, and they might call some general purpose UI functions, but they shouldn't really know anything about the mouse cursor or window coordinates or screen sizes.

 

Instead game objects will interact with the UI system, and the UI system will do the magic of populating images and text and numbers, converting button clicks into animations and audio events and game object events.

 

A game object might run a function like "run the store purchasing UI screen using these parameters". Game objects might also have functions requesting what to display as a tooltip popup but they wouldn't directly create the windows, just provide a string of content, like "Quiver containing 4 magic arrows". 

 

All the details of managing windows for display, of showing pages of UI data, of handling clicks an beeps and blips as the user clicks on the screen, or as the user presses hotkeys, or as the user does any interaction (hence "UI") should be entirely handled within a UI component. The UI component converts those into game objects for everything else in the engine to consume. No other system should directly interact with the user.

Share this post


Link to post
Share on other sites

But I am thinking maybe this design would be vise-versa, where the window sends events to the Engine instead of Engine receiving them from the Window, and the loop happens through the window instead of the engine.

Then you are second-guessing yourself for no reason.
Normal applications may be event-driven, but games are not. Not even when input is concerned.

There is little need for a window manager at all. A window is simply a gateway for the operating system to send external information to the game. The game does not need to be a slave to this; this information (whether it be inputs or anything else) should be retrieved by the engine at its own convenience at a specific and well defined point within the game loop.
Until that point, all inputs should be cached and the game loop should keep running.
 
It may be possible to glean some ideas from my post on General Game/Engine Structure.


L. Spiro

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement