#We need a performance update asap

55 messages · Page 1 of 1 (latest)

cinder anchor
#

I was doing a mini research and i found that the game only use one thread of the processor.
The modding and sub-building community keeps the game alive so with a performance update we can work with better and more complex mods and subs. Its just a shame to discard a campaign because of the performance. Thanks in advance for reading

#

I think that the performance should be the priority in this game but i don't want to sound pretentious

fallen locust
#

making the game actually multi threaded will require almost full rewriting of code, which, for obvious reasons, is a very ambitious task at this point of the game's life

cinder anchor
fallen locust
#

pretty much
the game's code is not good to say the least, mostly because barotrauma was never intended to become as big and as well known as it is now, so the devs let some things slip through when they probably shouldn't have, which leads to bad code, technical debt yatta yatta. Watch doshdoshington's video on the topic if you want
but basically we're probably not getting huge improvements in terms of optimisation, mostly some minor stuff. But I'm pretty sure that just making a new game would realistically be easier than fixing the mess barotrauma is now, and I think one of the devs said they had ideas about that, just not in the close future

supple fjord
#

First code has to be redone

#

Threading can cause more lag

#

Also it can kill all modding support

upbeat tiger
#

I'd have to say, I don't think it'd kill modding support. It it depends on what is being tossed to a new thread, it could cause performance issues if not done right.

But as mentioned it'd require a large amount of the game code/engine to be re-written.

Like if some more complex requests could be thrown to a thread (like path finding and AI task prioritization. However these could also still be handled single-threaded and if they need more "thought processing" they can just be handed off to the next frame to pick up.

Threading is for sure not always the be all, and isn't always the reason why things are laggy, since once a thread is created now a system of "what data is ok to change and what needs to be locked down, or a copy sent to the other thread, and how to tell the 1st thread that whatever processed is ready to use"

#

It might be worth it for them to mess around with threading, but I don't think at this point it'd be worthwhile to gut the game to add it (yet) as I'm not sure on the teams experience with threading, and as I mentioned if it's not done right it'll just lead to what !Archmagos Trollman said it'd cause more performance issues in that case.

We already have options for statueseffects and a few other things to run in intervals, which as modding goes, can help performance since we're staggering per-update events across frames

cinder anchor
#

thanks guys for the feedback, now i comprehend the situation a little more

#

i love the idea of a barotrauma "remake" in the future, fixing the problems we have with this version. I really love this game but the current state of it makes me sad

upbeat tiger
#

I feel like they'd probably incorporate these things into a new game/project that is similar enough, and quite possibly they'd just have Barotrauma: Delta P (aka a sequel) which would port a lot of stuff from this game but into the new engine. (since a lot of the content would be transferrable) and mods would most-likely just need a few adjustments to work with it.

I know Kenshi 2 is being made with Unreal Engine, but they're also trying to incorporate their old modding SDK (FCS, Forgotten Construction Set) into it so most mods from Kenshi 1 will maybe work, or work with some tweaks (and helps content related modding be easier than coding/blueprinting that might throw many off)

thin fox
#

Honestly, they should stop putting out new content, and before they release the dlc, they should give us either a rewrite, or a barotrauma mk 2, I would rather go without the seasonal updates for a year or 2, have the only new content be mods, and then have my friends actually be able to play with me

#

Cause I always host, after the fall performance fix I rarely lag, but my crew still has to put up with it constantly, we all have good internet and good hardware, and we live in the same region

cinder anchor
warm briar
#

A minecraft server is fully multithreaded

#

Barotrauma is not

supple fjord
#

Minecraft is not threaded

warm briar
#

The server is

supple fjord
warm briar
supple fjord
#

As the servers run most of the same code as the clients

warm briar
supple fjord
#

As 9 times out of 10, they are a hack fix

#

Bearly works with the game without issues

warm briar
supple fjord
#

It just rewrites some parts of the code that lags without changing its logic

#

Making it threaded changes the logic

proper drum
#

Interestingly enough, I'm currently rewriting my own game engine and the threaded resource loading is one of my goals

proper drum
supple fjord
#

Logic being on their own thread could be nice

final kiln
#

I was thinking, ya’ll know how subs are all made of textures on different layers? What if we could bake all the objects in a layer into one object? Would that help with performance?

upbeat tiger
#

it could, or be able to mark shells, and decals into a "layer group" because you might have to have a deco item be just above anothers layer, for an example, so it displays correctly. but for the shell something like a rust stain or other doodad would need to be "baked onto it"

so it'd be a feature most likely used by sub-makers. naturally some objects would still remain as is (containers, fabricators, junctionboxes, etc) but to have the sub as just a handful of baked layers with the containing items, might help with performance, but I'm not sure on the gains, since most of them are technically just sprites, and the cost of rendering a 2d sprite isn't as costly as it used to be, but cutting down entites is already free gains

#

also this bake would most likely require either a tempdata setup, so when 1st joining the client would "bake" the layers locally for that session (or sub, and tuck it away) as having workshop subs having massive sprites bundled in pre-baked wouldn't make much sense

supple fjord
#

Like when you save a sub there is a copy with the layers baked into one

#

And stuff you place is not baked into one

upbeat tiger
#

I'd guess it'd be better for subs to just index what goes to what layer and what those layers depth is.
and clients just generate it once, and if it doesn't get loaded after few weeks the baked images are removed.

I'm taking into account for variable sub sizes. A giant sub might have like a 2kx1k texture baked * number of layers. actually thinking of this now, It might have the reverse if a sub makes too many layers... not only disk space (even if compressed) but VRAM? 🤔

#

maybe i'm overthinking it and underthinking at the same time

#

on the hand of the sub creator baking it, and it's embedded into the sub file. uploads would be larger. but then the final result is known. and less burden on the client to generate, considering the range of PC specs

halcyon onyx
#

Like a different thread for the visuals or something

supple fjord
#

No

#

And graphics do not count

winged basin
#

A good chunk of the AI could easily be put on secondary threads, as Hugo hinted at. World generation technically could be as well, but that wouldn't have in-game performance benefits.

The biggest benefit would probably be separating the math for shadow casting into a separate thread.

#

Multithreading is nowhere near as difficult as people make it out to be. The only hard part of it is learning how to multithread and what can feasibly be moved to a separate thread.

Otherwise, as someone who has done multithreading many times, sometimes on projects that were not originally multithreaded, it never requires full refactors of large portions of the codebase. Usually you are just offloading the math part of a function. Everything else stays the same unless you are writing monolithic interdependent functions, which means you should re-evaluate your team's standards.