DICE PACKS BUNDLE
Page 4 of 7 First ... 23456 ... Last
  1. #31
    Quote Originally Posted by Griogre View Post
    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.
    There is certainly a performance consumption by such flexibility, however my comment was specifically directed at the method used to manage data with lua. Each data node is a lua object (JPG has mentioned this several times) and I am told that this is the largest issue with resource consumption. For example if you try and create 1000 data nodes of even a most simplistic nature it will more than likely cause the system to choke completely. This is during a live session, after everything has loaded. I had to create a process to import a large data set specifically because of the issue. It's also why I had to re-write the CT for the 2E ruleset (DM side) due to the number of "nodes" within the data structure I went with.

    The load times for xml conversion to information that the ruleset can use I believe is trivial, it's the data that is the key consumer of process time.

    JPG has mentioned a few times he would like to uncouple LUA node/data but it would be a major re-write and break a lot of existing work so is not likely to happen anytime soon (or at all?).

    I would be happy to have anything that would improve performance, as is I am hitting the top end of that at times myself. If multithreading would help, I would love it. I don't have the background deep enough to know if it would however.
    ---
    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.

  2. #32

    Join Date
    Mar 2006
    Location
    Arkansas
    Posts
    7,397
    Well now we have Unity we can hope FGU might eventually move from LUA to C#... My loathing for LUA globals is real.

    I'm not that up on multi-threading either but I have read they are starting to get to decent general purpose algorithms for CPU load balancing which would help.

  3. #33
    I propose a solution to help those people who assume the software has locked up if they can't see a little progress bar or whatever.

    Do what Discord does. Have some random messages pop up:

    Acquiring parchment
    Taming dragons
    Getting Xanathars stamp of approval

    Etc. On the loading screen.

    I have 7 players all of them fairly new to Fantasy Grounds and none of them thought it locked up. But I did say it rakes a while for the table to load. Time to get a drink and snacks for game time.

    But a random. message might help.

  4. #34
    Valyar's Avatar
    Join Date
    Mar 2018
    Location
    Europe
    Posts
    2,117
    What I am mostly interested and really need is SW to improve the loading times... at the moment Unity loads fresh or during /reload twice or three times slower which makes developing new content very very slowly when you need to test pixel-based adjustment or other fine-tuning activities.

    There is no quality of life improvement for developers at all. So any change towards this - I am all game.
    The past is a rudder to guide us, not an anchor to hold us back.

  5. #35
    Reducing the amount of content is always helpful. If you have thousands and thousands of files in your images/tokens/portraits directory; start up times will always be slower as they are indexed at session startup.

    Regards,
    JPG

  6. #36
    - Are non-changing files indexed? or are hashes used to only index files that need new indexing?

    - Is indexing of multiple files done concurrently via multiple CPU cores/threads?

    - How can I disable images from rulesets? I own the Pathfinder 2 Core RPG module, which is full of images I hardly ever use and always spam my image browser dialog. How can I turn these off while still using the ruleset?

  7. #37
    I'd also love a LUA to C# change ... though I don't actually expect to see that happen...nice thing to wish for.

    Start up times with FGU are crazy long. Definitely some room for some optimizes in that area.

  8. #38
    Quote Originally Posted by DM_BK View Post
    I'd also love a LUA to C# change ... though I don't actually expect to see that happen...nice thing to wish for.

    Start up times with FGU are crazy long. Definitely some room for some optimizes in that area.
    C# is windows only as far as I know - so no mac or linux.

  9. #39

    Join Date
    Mar 2006
    Location
    Arkansas
    Posts
    7,397
    Mono is open source and makes C# cross platform (though admittedly without the latest .NET bells and whistles).

    However, the important thing here it that C# is the scripting language used by Unity and Unity is cross platform. So it wouldn't really matter how cross platform stand alone C# is since its Unity that compiles the different platform exes.

  10. #40
    The long startup-times are not directly connected to the multi-threading vs. single-thread discussion, though. From Launcher already running to starting a campaign FGU takes 50% longer for GMs and 100% longer for players compared to FGC.

    FGC is just as single-threaded as FGU in all of this (maybe even more), but still dramatically faster for loading campaigns (same modules, same extensions, same files, same everything).

    So even if multi-threading might help with load-times, something seems to lack optimization with FGU that multi-threading alone might not solve. Still maxing out only 1 out of 16 threads while making me wait for "not responding" feels wrong.

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
  •  
FG Spreadshirt Swag

Log in

Log in