• Lets_Eat_Grandma
    link
    fedilink
    English
    arrow-up
    2
    ·
    5 months ago

    All I know is what many have said time and time again. There is one main thread that everything else depends on, so no matter how much horsepower you throw at it you are constrained by whatever logic or calculation that one thread is doing.

    For all I know it’s a memory bandwidth thing or even a disk access thing pertaining to that one thread which makes everything else wait. They use their own homegrown engine and there’s a bottleneck in the code somewhere, obviously.

    I’m kind of surprised they don’t have something that’s more scalable because they built a new engine for X:Rebirth which came out in 2013. Maybe they started the engine rebuild before dual core and quad core cpus were mainstream in the late 2000s.

    • ulterno@lemmy.kde.social
      link
      fedilink
      English
      arrow-up
      0
      ·
      5 months ago

      Well, when you make a multithreaded application, usually there is one main thread, which controls everything else, timings and all.

      The alternative

      is to have all threads know how to sync with whichever other thread they need to sync with, whenever they need to. This way tends to be more difficult (and I am yet to think of a use case and application methodology for this method).

      Now usually you make sure not to have any blocking function (large calculation or file R/W requiring HDD fetching) on the main thread. Maybe they made some mistakes in this regard in their previous games and did better this time.

      From what I see, it seems like they didn’t use the graphics API (seems to be Vulkan) properly enough, for which I can’t do anything, given my lack of exp with it. Perhaps a god time for me to delve into Vulkan.