Client afk in background - Effects started to fun faster

[Shahin 213]

Video down below for better understanding. It is normal recording, nothing sped up.

https://metin2.download/picture/mej38W48LDbTIahX6mUHP0Pen20Pu9jq/.gif

 

Hello guys: If i leave the game in background even for 30 minutes, all the effects going on in the background are paused and resumed when window is on focus.

It is like caching and then running everything afterwards. every effect untill the time i came back that was happening in the surrounded area, are playing all in the same time.

Lets say if i have the game in background, the round circle around my character had to fully complete 100 cicles in the last one minute.

When i get the Window back up, all those 100 cicles are starting on a high speed until it resumes to the actual time, and then it slows down to normal.

 

I Know this is a known issue but i never had it on my own.

 

How can i fix it?

 

Thank you!

 

 

Edited August 28, 2022 by Metin2 Dev
Core X - External 2 Internal

[Juice 482]

Have a look at this topic: Click

[Shahin 213]

I'm testing it now. I'll come back with a feedback

 

[masodikbela 1326]

The content in that topic can be visualized in a single gif:


The problem with the "speedy effects" after maximizing a minimized client lies here:

As you can see the elapsed time is measured since... well... the last time the effect got updated. You might say that hey, thats ok... well it would be, but if you take a look at the messy game loop inside PythonApplication.cpp you will notice that the call for effect updates is only present in the RenderGame function, which is a render function as its name implies it, and its only called when the game is rendering. And since the game doesn't render anything if its minimized, the time for the effects basically stops, and when the game starts rendering again, it will resume it from that point when it got minimized.

You might rightfully say that okay, but that doesn't explain the reason why is it "speedy" for a long time, since the time difference should be huge for only one call, then it should return to normal because the m_fLastTime got updated at the end of the function. And at this point I'm officially out of definitive answers.

 

The real reason might be one of the following:

• On the first "big" time difference after maximizing the client destabilizes the effect instance, messing up the emission/decorator update on a weird way, making the following n updates unstable as well.
• The custom timer class is more than weird, it has a "real time" mode and a "custom time" mode, but as I see only the "custom time" mode is used, which works like advancing the timer every time the main loop is called. Since the advancing is always called (its in the update part, not the render part) I somewhat doubt that this is the real reason. Using a different timer (potentially std::chrono) here in the effect update would quickly evaluate this case.

In short, fixing it could be done by:

• Using a maximum value for the elapsed time (like it cant be larger than 1/60). This would solve the "speedy" issue, but would cause another bug, making some effects stay longer alive (if you minimize the client).
• Calling effect update even when the client is minimized. This would make the client use somewhat more resource when its minimized, but would still use way more less resource compared to the "fix" in that topic.
• Digging a bit more deeper, finding more accurate solutions. (The effects are stateless, or at least it really seems so, so it should mean that the effect should work with any given "elapsed time" at any point, but like I said this might be violated somewhere. The effects are not stateless, since the particle positions are based on the last position + elapsedTime * acceleration.)

Edited August 18, 2022 by Metin2 Dev
Core X - External 2 Internal

[Shahin 213]

So the easiest solution which is also not conflicting with the other time functions on update would be the :

On 3/6/2021 at 2:34 AM, masodikbela said:

• Calling effect update even when the client is minimized. This would make the client use somewhat more resource when its minimized, but would still use way more less resource compared to the "fix" in that topic.

?

I am still benchmarking the "fix" received by @CHKRZ, but i think on a lower spec pc would run players crazy with the usage. I have 50% Gpu utilization with only one client minimized, 80% with tree clients minimized, on a i7 6700k integraded GPU "HD 630" (which is a high graded integrated PC Gpu, so the difference is huge when we talk about laptop i3/i5 integrated gpu users). 

I am taking integrated GPUs as a measurement because 70% of players are using a laptop, and most of them have only integrated GPUs.

 

The base idea is to Optimize, not to use more performance to fix a minor problem. (i'm still talking about the above fix)

 

So, what would be your suggestion as the best solution, and if you can walk me through it.

[masodikbela 1326]

3 hours ago, Shahin said:

So the easiest solution which is also not conflicting with the other time functions on update would be the :

On 3/6/2021 at 1:34 AM, masodikbela said:

• Calling effect update even when the client is minimized. This would make the client use somewhat more resource when its minimized, but would still use way more less resource compared to the "fix" in that topic.

?

Yes, the low-effort but working solution is this indeed.

 

3 hours ago, Shahin said:

I am still benchmarking the "fix" received by @CHKRZ, but i think on a lower spec pc would run players crazy with the usage. I have 50% Gpu utilization with only one client minimized, 80% with tree clients minimized, on a i7 6700k integraded GPU "HD 630" (which is a high graded integrated PC Gpu, so the difference is huge when we talk about laptop i3/i5 integrated gpu users). 

I am taking integrated GPUs as a measurement because 70% of players are using a laptop, and most of them have only integrated GPUs.

 

The base idea is to Optimize, not to use more performance to fix a minor problem. (i'm still talking about the above fix)

The difference between my suggestion and the "fix" from the other topic is that the latter just masks the problem making the client call render even if the client is minimized, so it uses all the functions it normally does, wasting the resources on something that nobody can see. The former one just calls the effect update which is a cpu-only task, and while normally its one of the performance bottlenecks, still doesn't use much resources on its own (without the other render calls).

 

3 hours ago, Shahin said:

So, what would be your suggestion as the best solution, and if you can walk me through it.

Well not sure what else can I add here, the lowest effort but working solution is the one you asked about. I won't write the code for you and basically I told everything you need for that. Its literally pasting one single line which updates the effects to the place where the game should render, but skips it only because the client is minimized.

So here are your clues, its now time to split up and investigate.

Edited August 25, 2022 by Metin2 Dev
Core X - External 2 Internal

[Shahin 213]

Thank you so much! I appreciate it!

Thanks for the effort put in to explain how things work

Edited March 7, 2021 by Shahin