Unity too slow

[knucklehead]

Something up is async loading and it's been a thing for like 15 years in almost every corner of the coding universe.

What you have isn't a novel problem that hasn't been faced everywhere there's I/O or latency bottlenecks. Quite certain C# and Unity have this problem solved already, at a very fundamental level.

[celestian]

Something up is async loading and it's been a thing for like 15 years in almost every corner of the coding universe.

What you have isn't a novel problem that hasn't been faced everywhere there's I/O or latency bottlenecks. Quite certain C# and Unity have this problem solved already, at a very fundamental level.

I wouldn't be surprised one bit if the latency/performance issues all revolve around Lua.

[Trenloe]

I was hoping that the 64 bit would fix the slowness, but now I know it was a matter of perspective, and it was never slow before.

64-bit has nothing to do with speed. It allows access to more memory. You can open more "Stuff", bigger images, etc. with a 64-bit system, but the processor still has to cope with that - even with an optimised application (we're not there yet) if you open lots of "stuff" then things will get slower.

[arcanjl]

Installed amd. A little different maybe? Hoping so. Just letting you know.

[Weissrolf]

There are multiple Unity Player threads running. Is there no way to make the LUA interpreter multi-threaded as well then (multiple interpreters being spread among those multiple player threads)? Single-threaded applications/media formats need to stop existing.

[damned]

I wouldn't be surprised one bit if the latency/performance issues all revolve around Lua.

And the number of modules loaded having all their images pulled into assets

[Moon Wizard]

It's not that simple. Multi-threaded programming is a complex subject.

Even if we were to somehow get a multi-threaded Lua engine running (which I'm not sure exists or whether it's even possible); that complexity would be passed on throughout the entire API and all ruleset/extension development. Currently, the code running for rulesets/extensions assumes it can access any other Lua object in the tabletop; which means that they all have to exist in the same Lua engine instance.

We're focusing on getting the graphics and networking running in a multi-threaded way to offload from the main thread running the Lua engine and tabletop.

Regards,
JPG

[arcanjl]

That sounds great!

I just played 8 hours with 7 players. We all loved the new features but the delays, the freezing, the stuttering, was just too much. We all agreed that as good as it is right now, it is not playable. So back to classic, and moving all my stuff back over.

It’s so hard. After 2 years we are so close.

[Weissrolf]

The simple answer would then be: Don't use LUA, it's old news.
A somewhat less simple answer would be: Try to get LUA to do multithreading via external libraries such as https://github.com/effil/effil

LUA is also holding back World of Warcraft addons for a long time already. You can throw all the money in the world at your computer, singlethreaded operation will keep you waiting nonetheless.

[Trenloe]

The simple answer would then be: Don't use LUA, it's old news.

Old news if FG was a brand new application. But it’s not. If you don’t use LUA then you throw out all rulesets, extensions, etc. that have been developed over the last 10+ year.