PDA

View Full Version : The road forward - 64 bit, multithreading?



jevel
May 26th, 2017, 10:08
I tried searching a little around the forums, but could not find any info about this.

Our DM has a fetish for for large maps giving us some issues with memory. Also we're seeing some problems with the DM end hanging while players connect after disconnect / crashes which I guess is down to CPU. This should not be an issue if the application was multithreaded I guess?

Do anyone have information about what is planned regarding these things?

-KJ

Wookiee420
May 26th, 2017, 10:57
these are all known issues, and things being worked on. I recommend that you look at the Fantasy Ground Unity thread it will have most, if not all your answers there https://www.fantasygrounds.com/forums/showthread.php?22089-Fantasy-Grounds-Unity-engine

jevel
May 26th, 2017, 11:02
Thanks.

I have a little reading to do there I see :)

-KJ

LordEntrails
May 26th, 2017, 17:28
In short, these are issues relating to the current architecture. A new version, informally referred to as Unity or FGU is in the works, but no timeline yet. SmiteWorks will not give a timeframe until they are confident they can deliver, which will be a few months prior to release. FGU will be able to use all current DLC/modules and will have all current functionality, multi-threading, 64 bit architecture, and new networking. Nothing else is promised, but some exciting things have been demo'd.

pindercarl
May 26th, 2017, 19:03
In short, these are issues relating to the current architecture. A new version, informally referred to as Unity or FGU is in the works, but no timeline yet. SmiteWorks will not give a timeframe until they are confident they can deliver, which will be a few months prior to release. FGU will be able to use all current DLC/modules and will have all current functionality, multi-threading, 64 bit architecture, and new networking. Nothing else is promised, but some exciting things have been demo'd.

Minor correction: Unity does not natively support multi-threading. This does not mean that the core of Unity is not multi-threaded, but projects built on the Unity platform are not multi-threaded. It's slightly more complex than I'm presenting, but that is the short version. However, performance overall should be improved. Especially on more modern hardware. The rest of your statement is accurate. FGU should support current DLC/modules, 64-bit architecture, new networking, and native support for Windows, OSX, and Linux.

Bidmaron
May 26th, 2017, 19:53
Wow. Bad news. I was really optimistic that downloads to client at least could be independently threaded.

pindercarl
May 26th, 2017, 20:08
Wow. Bad news. I was really optimistic that downloads to client at least could be independently threaded.

Like I said, it's more complex than that. Unity does not support multithreading that interacts with the Unity API. It is possible to manage downloads without stalling the main thread, whether those are coroutines or operating in a separate thread. The new networking is very much in progress, so it isn't possible to nail down any specifics yet.

Ken L
May 26th, 2017, 20:19
Unity is multithreaded, interacting with the API is not. Unity is an engine, you tell it do perform a set of actions and it'll determine if it warrants multi-threading. So API that needs to call Unity routines will primarily be the main thread, outside of the unity API you can do what you want, but the API calls aren't thread safe iirc. Child threads can queue up things for the main thread to execute however which is what I believe how it's done.

Bidmaron
May 26th, 2017, 20:22
It must at least support semaphores or some method to check completion status of the threads.

But I will shut up now and let Carl get back to work. It sounds like the downloads won't impact U/I thread and that is really the important thing. Thanks for answering though earlier.