Jump to content

  • Log In with Google      Sign In   
  • Create Account


Is Window Manager a part of an engine?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
3 replies to this topic

#1 Gasimzada   Members   -  Reputation: 206

Like
0Likes
Like

Posted 18 January 2014 - 10:19 AM

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



Sponsor:

#2 frob   Moderators   -  Reputation: 19853

Like
3Likes
Like

Posted 19 January 2014 - 01:03 AM

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.


Check out my personal indie blog at bryanwagstaff.com.

#3 L. Spiro   Crossbones+   -  Reputation: 13004

Like
4Likes
Like

Posted 19 January 2014 - 01:54 AM

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
It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums

#4 Gasimzada   Members   -  Reputation: 206

Like
0Likes
Like

Posted 19 January 2014 - 07:21 AM

Thank you for the help! I was thinking in the wrong direction but not it all makes sense.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS