5E Product Walkthrough Playlist
Page 1 of 7 123 ... Last
  1. #1

    CPU multi-threading planned

    Ahoi.

    Are there any plans on making FGU CPU multi-threaded? Like calculating all LoS on its own thread (or may even PC and NPC on their own), networking on its own thread, dice rolling and/or combat tracker automations, drawing of maps and fx, LUA extensions/scripts and the like...

  2. #2
    Multi-threading will be considered when needed and when appropriate. Some things are already multi-threaded (Ex: Networking/Sharing), some things are under consideration for multi-threading (Ex: LoS calculations), and some things can't be multi-threaded (Lua engine and UI interaction).

    Regards,
    JPG

  3. #3
    - Good to know that networking is multi-threaded, so that the networking threads can keep doing its work when everything else is bottlenecked.

    - LoS calculations lead to drops in frame-rates when tokens are moved, so this would likely benefit from multi-threading. Good to know that it's already under consideration.

    - Are Lua scripts interpreted during runtime or compiled when a campaign is loaded? Loading a campaign is bottlenecked by a single mono thread and takes 20 seconds even on my 9900K (while no progress bar is shown). Couldn't anything of this be balanced over more CPU threads? Like compiling different modules/extensions on different threads? Some of my players are on weaker PCs and connections, so speeding up the startup time would be appreciated.

    -

  4. #4
    Quote Originally Posted by Weissrolf View Post
    - Good to know that networking is multi-threaded, so that the networking threads can keep doing its work when everything else is bottlenecked.

    - LoS calculations lead to drops in frame-rates when tokens are moved, so this would likely benefit from multi-threading. Good to know that it's already under consideration.

    - Are Lua scripts interpreted during runtime or compiled when a campaign is loaded? Loading a campaign is bottlenecked by a single mono thread and takes 20 seconds even on my 9900K (while no progress bar is shown). Couldn't anything of this be balanced over more CPU threads? Like compiling different modules/extensions on different threads? Some of my players are on weaker PCs and connections, so speeding up the startup time would be appreciated.

    -
    A progress bar for initial campaign load would be great, too, but might further increase load times as some initial calculation would need to be done to figure out everything that needs to be loaded.

  5. #5
    Just like in the olden DOS day: anything that moves helps to show that the program did not freeze. Most of these progress bars don't properly predict time/percentage anyway.

  6. #6
    Quote Originally Posted by Weissrolf View Post
    Just like in the olden DOS day: anything that moves helps to show that the program did not freeze. Most of these progress bars don't properly predict time/percentage anyway.
    For this I would recommend one of those 'pulsing' progress bars or a spinning circle type loading indicator (which is probably what you mean).
    Early-on with my newest group (who were all new to FG) most did not have patience and kept thinking the program had failed and would close/re-open which would start the loading all over again!
    It is good practice to be patient but also counter-intuitive to many people who are used to responsive UIs (and most people are not patient).
    Last edited by bmos; November 10th, 2020 at 13:41.

  7. #7
    While we are at it: FGU can take a long time to start (especially after updates) while seemingly being frozen "not responding". A progress indicator would help then.

  8. #8
    And yes, make that progress indicator multi-threaded if needed, so that the whole process does not stall to a seemingly frozen state.

  9. #9
    I have to underline this repeatedly: FGU desperately needs multi-threading for its UI elements. Today I had to tell 5 players that: No, FGU did not crash, despite it saying "not responding". It's just so busy processing stuff that its sad single-threaded process had no resources spare to keep its UI animated and responding.

    After a promoted "complete rebuild from the ground up" this is an inconceivable design/implementation choice for 2020 software. FGU is brand-new and already feels like 20 year old software.

  10. #10
    Unfortunately, a small team that can financially maintain itself doesn't get the needed infusions of modern software development practices through attrition and new hires. Freezing UI while crunching is indicative of using the UI thread to do calculations, which in any current software is a no-no, but especially in a game engine. The fact the problem exists is indicative of bad architecture, which is indicative of ... and so on.

    Unfortunately many available tutorials for the Unity engine tend to do everything on the UI thread and only developers that already know what they are doing would be able to say "hmm, wait a second here..." As a platform Unity seems a bizarre choice to me when there is at least one other non-gaming platform that would seem to be a better choice if only because it doesn't come with all the extra overhead of a full game engine and the constraints it brings. Plus, every Unity engine update tends to break things.

    The amount of effort to fix bad architectural design in the a project built in the Unity Engine would be cause to rewrite all by itself.

    I'm thinking we either live with it and continue using FGU, or we don't and we don't.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
DICE PACKS BUNDLE

Log in

Log in