Starfinder Playlist
Page 3 of 7 First 12345 ... Last
  1. #21
    Due to the way rulesets have full control over display of all aspects of the tabletop and that information is handled in the main thread through a Lua engine, your best bet is to reduce the amount of material loaded in your campaign to improve performance. If you have every module ever created for say the 5E ruleset open in FGU, it's going to slow down the UI. Close the ones you don't need open.

    Regards,
    JPG

  2. #22
    Thanks for chiming in, well appreciated.

    Both rulesets and extensions do not have to be loaded by the main thread, though, even when they need to run in the main thread. FGU proves that itself, because the everything loaded as "Load Part 1" is not loaded by the main thread. So no problem keeping the UI alive and displaying a busy animation via main thread.

    Then I wonder what "LUA engine" means? I assume that the LUA scripts are not interpreted but compiled by a JustInTime compiler? Does that compilation of multiple scripts/ruleset/extension files have to be done in sequence by a single thread?

    Due to the way rulesets have full control over display...
    What way is this? Could the way maybe be changed? Judging by another big software title I suspect not (so easily):

    World of Warcraft suffers from the very same problems. My 170 LUA addons scripts are all loaded by one main thread and then run by the WOW main thread.

    The latter (run) can lead to a script causing massive FPS drops down to a complete halt. There are lots of extra threads running alongside the main thread, though, putting all kinds of extra load on other cores (mainly GPU/output related stuff I suspect, have to switch back from DX12 to DX11 to check).

    The former (load) is solved differently compared to FG. What WOW does is that after each (or maybe a bunch) of scripts are loaded it updates the UI to fill the progress bar a bit and respond to the OS. It's jumpy, there are massive fps drops in between (from 1200 to 0), but it keeps the process responding and gives the user a sense of progress.
    Last edited by Weissrolf; November 21st, 2020 at 09:00.

  3. #23
    Quote Originally Posted by Weissrolf View Post
    Thanks for chiming in, well appreciated.

    Both rulesets and extensions do not have to be loaded by the main thread, though, even when they need to run in the main thread. FGU proves that itself, because the everything loaded as "Load Part 1" is not loaded by the main thread. So no problem keeping the UI alive and displaying a busy animation via main thread.

    Then I wonder what "LUA engine" means? I assume that the LUA scripts are not interpreted but compiled by a JustInTime compiler? Does that compilation of multiple scripts/ruleset/extension files have to be done in sequence by a single thread?


    What way is this? Could the way maybe be changed? Judging by another big software title I suspect not (so easily):

    World of Warcraft suffers from the very same problems. My 170 LUA addons scripts are all loaded by one main thread and then run by the WOW main thread.

    The latter (run) can lead to a script causing massive FPS drops down to a complete halt. There are lots of extra threads running alongside the main thread, though, putting all kinds of extra load on other cores (mainly GPU/output related stuff I suspect, have to switch back from DX12 to DX11 to check).

    The former (load) is solved differently compared to FG. What WOW does is that after each (or maybe a bunch) of scripts are loaded it updates the UI to fill the progress bar a bit and respond to the OS. It's jumpy, there are massive fps drops in between (from 1200 to 0), but it keeps the process responding and gives the user a sense of progress.
    WOW is a completely different engine to Unity and has completely different requirements. Also WOW is a BILLION dollar game with 16 years of super high funding and literally hundreds of people working on it at its peak. Even a team that big had problems ironing out the millions of lines of code that contained bugs and errors. It took them 5 years to figure out how to fix latency issues with spell casting (and it still has issues)

    Do a C++ programming course and learn how coding works. I used to back in the 1980's (in assembly, not C) - A piece of code that runs perfectly when you step thru it line by line often doesn't do as expected when its running and takes hours to figure out.

    With a massive program like FGU getting the basics up and running first are the priority, then bug fixing and streamlining occur - which then create new bugs which need to be fixed (and that is why sometimes things get rolled back).

    Also even though multi-core CPUs have been around for a long time now, the mindset of many programmers is still "one thing at a time" because humans brains work that way - and until software or hardware automatically allocates threads at run time, it will be an issue for a while yet.

  4. #24
    LordEntrails's Avatar
    Join Date
    May 2015
    Location
    -7 UTC
    Posts
    17,148
    Blog Entries
    9
    I think this thread proves a few things. One is that the developers know the limitations of the software in regards to processing bottlenecks. Two, that they intend to improve upon such limitations as reasonable business decisions dictate. And three, that further developer involvement on this topic simple takes time away from them actually developing improvements to the software.

    Problems? See; How to Report Issues, Bugs & Problems
    On Licensing & Distributing Community Content
    Community Contributions: Gemstones, 5E Quick Ref Decal, Adventure Module Creation, Dungeon Trinkets, Balance Disturbed, Dungeon Room Descriptions
    Note, I am not a SmiteWorks employee or representative, I'm just a user like you.

  5. #25
    Quote Originally Posted by LordEntrails View Post
    I think this thread proves a few things. One is that the developers know the limitations of the software in regards to processing bottlenecks. Two, that they intend to improve upon such limitations as reasonable business decisions dictate. And three, that further developer involvement on this topic simple takes time away from them actually developing improvements to the software.
    Agreed.

  6. #26
    So everyone is cool with showing "not responding" instead of updating a simple progress bar? This does not even need multi-threading to be improved. The same "not responding" (or at least blue circle pointer) thing happens when very large images are opened (plus memory usage skyrockets), or when larger modules are loaded. FGU keeps freezing far too often.

    You really need to think out of your own veterans' box sometimes. I brought 8 new players to FG and all of them had to be handheld to either properly install FG or at least not be fooled into thinking the application froze (and thus try kill the process to restart). These are serious roadblocks for software trying to reach a new audience.

    And yes, people hope for a modern architecture underneath a responsive UI when they buy new software in 2020.
    Last edited by Weissrolf; November 21st, 2020 at 18:42.

  7. #27
    Sulimo's Avatar
    Join Date
    Dec 2014
    Location
    Pacific Time Zone
    Posts
    879
    I think part of the problem is that not everyone sees 'not responding' or the spinning wheel when using FGU.

    I know I do not see that. Maybe a couple of times early in the Beta, but not for a long time. My players do not see that either.

    Perhaps check what you are loading (extensions?) and see if one (or more) of them has not yet been optimized for FGU. I know that was a problem with some of them, and most of the extension devs were waiting until full release to update their extensions.

    I believe I recall a discussion about images and memory usage somewhere on the forums, but I do not have the link handy.

  8. #28

    Join Date
    Mar 2006
    Location
    Arkansas
    Posts
    7,381
    Personally I don't like not responding. For the record, reasonable and meaningful progress bars are hard if you don't know how long the process is going to take or the number of files to be loaded, ect - which is likely here since you are waiting for your clients to download across the Internet. I would settle for a spinner circle.

    The easiest way to get rid of the lag would be to stop support for extensions and scripting, which would ruin the ability to have community add ons. I don't think people like the "Not responding", I think they like their add-ons more than they dislike the non responding - which is usually just once a game at the start or if the GM shares large assets.

  9. #29
    Quote Originally Posted by Griogre View Post
    The easiest way to get rid of the lag would be to stop support for extensions and scripting
    There are certainly some extensions that might do a lot of "loading" of data for processing whatever they do but I can tell you that that's not the "easiest" way to fix the problem because... they are not the problem. What takes the longest is loading all the data modules. i.e. books, content/etc. I suspect that reason is because of LUA objects for said data... thats a guess based on what I've heard over the years from JPG. While some extensions might also process some of that same data the bulk of them dont and simply removing them does not actually fix the problem.
    ---
    Fantasy Grounds AD&D Reference Bundle, AD&D Adventure Bundle 1, AD&D Adventure Bundle 2
    Documentation for AD&D 2E ruleset.
    Custom Maps (I2, S4, T1-4, Barrowmaze,Lost City of Barakus)
    Note: Please do not message me directly on this site, post in the forums or ping me in FG's discord.

  10. #30

    Join Date
    Mar 2006
    Location
    Arkansas
    Posts
    7,381
    The ability to use LUA at all or any scripting instead of just hard coding the data modules as dlls it is a root cause of the bottleneck in my opinion. When I said extensions I didn't just mean the add on extensions I meant the XML ruleset templates and scripts as well. To FG there isn't any real difference between a ruleset, an extension, a library module, or a campaign module - they are just XML data files.

    Using XML at all to hold data is a performance hit, you have to read it from file, make sure its well formed and then load it into memory. FG's XML parser and /or the ruleset templates also do some processing by filling in missing XML data with defaults.

    Traditionally you take that performance hit to gain the flexibility of allowing 3rd parties to safely modify the behavior of your base engine code. I think this is a worthwhile trade for this type of application.

    I think if you were to compile the rulesets down to binary you would get a performance gain though I'm doubtful if it would beat just converting *every* FG art asset to 256 colors - it would be fun to profile.

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