0
\$\begingroup\$

This is also what I want to makeThis is my ideaThis is what I want to make.

I want to structure my program as shown in the first two images, but I don't know how to get make two game loops happening simultaneously. The arrows show the flow of data.

** I figured that having the engine processing everything from the system in the background, it would make my game run much more smoothly as well as open memory for my game to function since everything coming from the system already be handled.

The game loop would be a normal game loop and the game would only interact with the handlers.

The handlers would take everything from the engine and make it a more easily accessible version. The only handler I know of that needs interact with the engine be graphics, so it be its own circle.

The second loop is the engine, which i want to be processing everything from the system in the background while my game be running. It would have a win32_platform class--the "circle"--that processes everything from the system and everything leaving the engine is in a platform_external class--the tall ellipse

I want to avoid multithreading since I read somewhere that multi-threading is slower than hardcoding a game engine.

\$\endgroup\$
6
  • 2
    \$\begingroup\$ AFAIK, Windows things are events queued, so at the beginning of your Main class game loop, you start off by processing all those events and changing the state of the game class, you can queue the inputs in your own key handler, etc. Processing the events in its own loop in parallel of your own game loop is calling for synchronization nightmares and likely without the speed gain you're expecting. \$\endgroup\$
    – Vaillancourt
    Commented May 3, 2023 at 14:31
  • \$\begingroup\$ Do you intend to make the engine faster by running the rendering loop and the input loop on two different threads? \$\endgroup\$
    – Philipp
    Commented May 3, 2023 at 14:31
  • \$\begingroup\$ I wanted to have my normal game loop, but with the engine processing everything from the system in the background. \$\endgroup\$
    – IcedSalad
    Commented May 3, 2023 at 16:48
  • 1
    \$\begingroup\$ @IcedSalad In the question you wrote you want to avoid multithreading, but also that you want "two loops to happen simultaneously" and "run things in the background". Multithreading would be the way to accomplish this. So you seem to be contradicting yourself here. Or maybe you don't fully understand what "multi-threading" means? In the last sentence you compare it to "hardcoding", which means something completely different. \$\endgroup\$
    – Philipp
    Commented May 4, 2023 at 12:48
  • \$\begingroup\$ how does "in the background" not imply multithreading? \$\endgroup\$ Commented May 5, 2023 at 19:50

1 Answer 1

1
\$\begingroup\$

This is a hard question... Like really hard to answer.

First suggestion

Purchase a hardcopy of "Game Engine Architecture" by Jason Gregory or a book similar to it. And read it, write down notes, summarize what you learn in a notebook etc... (this is a 1200 page book). You have a lot of learning to do.

The mechanics

There are multiple ways to do what you want to do from single thread processing to multi-thread (parallel) processing.

I would start by making it a single threaded process. Have a function that performs all required physics engine calculations for a single time step.

Then have a function that performs all required game logic calculations for a single time step.

(Or reverse the order if you want to)

While you are writing both functions, make certain to design them so that you can place either one on top or bottom... Also, also you want to design them so that if they were to to run at the same time it wouldn't break things... Then add in message queues to communicate from your game logic to your physics Engine...

Assuming that all of your step sizes are the same...

class PhysicsEngine:
private:
    # reference to a message queue, PhysicsEngine does not own this.
    MessageQueue<>& message_queue 
    # reference to game object list. Physics Engine does not own this.
    list<GameObjects>& game_objects 
    void step() {
        #! do one time step of calculations for your game engine stuff. read the 
        # message_queue and apply it's effects to the relevant game_object.
    }

class GameLogic:
    # reference to a message queue, GameLogic does not own this.
    MessageQueue<>& message_queue 
    # reference to game object list. GameLogic does not own this.
    list<GameObjects>& game_objects 
    void step() {
       #! do one time step of game play logic... 
       # Read user input, AI calculations etc..
    }

    void main() {
       for (;;) {
          game_logic.step()
          physics_engine.step()
       }
    }

If you do a good enough job separating the game logic and game engine's area of concerns you should be able to split the 2 into a multi threaded environment without any extra work. Make a game logic thread, and a game engine thread. More work can be done to further parallelize the computation, but that starts becoming complicated.. Could put the AI on its own thread... multi thread the physics calculations (Which is by itself a multi person/multi-year million dollar project).

\$\endgroup\$
3
  • 2
    \$\begingroup\$ "More work can be done to further parallelize the computation, but that starts becoming complicated.." One just needs to keep in mind that retrofitting multi-threading to an existing engine is much more complicated than planning for it from the start. \$\endgroup\$
    – Vaillancourt
    Commented May 4, 2023 at 16:31
  • 1
    \$\begingroup\$ @Vaillancourt True... but if you haven't built a single threaded game engine you cannot make one that runs on 2 threads. If you haven't built one that runs on 2 threads you cannot make a truly multi-threaded one. \$\endgroup\$
    – Questor
    Commented May 4, 2023 at 16:36
  • \$\begingroup\$ I agree with you! \$\endgroup\$
    – Vaillancourt
    Commented May 4, 2023 at 16:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .