Menu Loading/Lag

[Draga]

Anyone else having the in game menu take 10 seconds to open up and about 1-2 seconds after each button press for the cursor to move? I'm wondering if this is based on my settings or just a port issue.

[JLBx]

Originally posted by Draga:

Anyone else having the in game menu take 10 seconds to open up and about 1-2 seconds after each button press for the cursor to move? I'm wondering if this is based on my settings or just a port issue.

i am not having that much time i have like 2 sec for menu

[Stargazer]

Originally posted by Wazhai:

I contacted support about the lag because it's particularly bad on Switch and here is the official reply:

"As for the lag occurred in the menu and during screen transitions, it is a behavior waiting for loading and this behavior conforms to the specification. We don't have plans to fix it. Your kind understanding is much appreciated."

This wouldn't be the first time KT misunderstood the problem that was described to them. Back when people complained about (IIRC) the low resolution assets in Atelier Sophie they didn't really get it either, which lead to some misunderstandings for both sides.

This issue definitely is not the expected behaviour, this lag does not occur on the PS3 version of Rorona Plus. And it's not just menu transitions, opening those menus causes the frames to drop severely and frame timings to go crazy, even on a machine that's way above the recommended specifications. It's definitely some kind of technical issue.

[Tiasmoon]

The lag does occur on the Vita version. And not just because Vita either, its a much laggier game then Totori/Meruru (or even Ayesha/E&L)

[Xariot]

Originally posted by Draga:

Anyone else having the in game menu take 10 seconds to open up and about 1-2 seconds after each button press for the cursor to move? I'm wondering if this is based on my settings or just a port issue.

I don't know... It doesn't really happen at all on my game. Menus open in a couple seconds and cursor movement appears instant on button press...

10 seconds for the menus to open is crazy, and laggy cursor response can really be annoying, but it's certainly not happening to me.

I did notice though that my CPU usage jumps from 8% to 13% (meh) and GPU usage jumps from 5% to 40% (what?) when I open a menu. Something certainly seems wrong there.

My first guess was CPU or Storage speed related but strangely it seems like it's GPU related given the huge jump in GPU usage from just opening the menus, but really I have no idea.

This could surely be because of a poorly optimized port that just runs slower on older/weaker computers but really my computer isn't exactly top tier. What are you guys running it on that it that it takes 10 seconds for menus to open and lagged cursor response times?

My Specs:

CPU: i5-8500
GPU: GTX 1060 6GB
RAM: 16 GB 2400MHz
(Game Installed on SSD)

If it happens on other platforms it's probably an issue with their porting but that doesn't mean anything will ever be done about it on PC, especially if upgrading to better hardware overcomes the issue.

I wouldn't hold your breath (or your wallet) for a patch. If you want to get better performance upgrading is likely what you'll end up having to do.

[Ebo]

Just purchased the game earlier today and I'm greatly annoyed by the stuttering/lag problem when it comes to opening menus and such. For me the lag lasts for 2-3 seconds. I have an i9 7900X and a Titan XP with a NVMe SSD.

I installed the game on my MSI laptop. It has a SSD, gen 7 i7, 1050 Ti, and the problem was there too. I also tried 3 different controllers with no success.

Anyone figure out a way to fix the issue? I used google to research the problem and someone mentioned forcing settings to max performance in the nvidia control panel and trying a controller but nothing worked for me.

[百合 姫]

Originally posted by Ebo:

Just purchased the game earlier today and I'm greatly annoyed by the stuttering/lag problem when it comes to opening menus and such. For me the lag lasts for 2-3 seconds. I have an i9 7900X and a Titan XP with a NVMe SSD.

I installed the game on my MSI laptop. It has a SSD, gen 7 i7, 1050 Ti, and the problem was there too. I also tried 3 different controllers with no success.

Anyone figure out a way to fix the issue? I used google to research the problem and someone mentioned forcing settings to max performance in the nvidia control panel and trying a controller but nothing worked for me.

Unfortunately, this is a developer mistake that will not be easy to fix. The reason is because in order to render text, the developer:
1) renders each character to a 512x512 32-bit texture, on the CPU, in system memory
2) composites it to a destination texture, in video memory. This necessitates a transfer from system memory to video memory
3) immediately displays the composited texture on screen.
Because the resource is used in the same frame it is uploaded, it is not possible to hide the latency of the resource upload, and so the GPU must grind to a halt. This is limited by PCIe bandwidth.

Here is a RenderDoc frame from opening the in-game status menu:
https://drive.google.com/open?id=1f1EgXvfSKc62VQqMa8CliTECoMCqoTdk

If you check the statistics tab, you will find that that frame contains about 2.4GB of data uploaded to the GPU.

The proper way to do this is to upload the font into video memory and have the GPU render text directly to video memory. Why they aren't doing this is beyond me.

[dairy farmer]

Given that waiting for KT to put out a patch is probably as reliable as prayer, I wonder if it'd be possible to hack up a dirty fix?

If it were possible to reduce the resolution and/or the bit depth of the font textures, that could potentially reduce the bandwidth requirement significantly. But I don't know the specifics -- it sounds like the problem might be in the composition step so this might do nothing.

Also, at least as described by Yuri, would people with integrated graphics solutions actually experience much less menu lag? That is, at least assuming there are any on par with the game's minimum reqs. I don't know if modern iGPUs still share system RAM though.


At least in theory, it seems like playing the game at lower settings or resolution should reduce the overall hardware burden and possibly reduce the menu lag, but then of course, it kind of defeats the point of an HD PC port...

Other than that, the only other solution seems to be to just overclock your CPU to reduce the render time and overclock your RAM and PCIe bus speed... all of which is incredible overkill for something like this.


I don't know -- maybe folks could get together and compile a list of video clips comparing the performance of this game to other (properly working) Atelier games and get as many people as possible to Twitter-bomb KT with the video clips. Maybe at least that way you can rule out the "miscommunication" theory.

[百合 姫]

Originally posted by dairy farmer:

meow

The Rorona and Meruru PC "DX" versions all render at a fixed internal resolution of 1920x1080, and all other resolutions are scaled from the render output. It's possible to hack, but breaks the UI in ways that I haven't successfully been able to fix.

The menu stutter time can be approximated to be the sum of (CPU/driver time) + (transfer time) + (GPU rendering time).

The menu stutter takes 970ms at PCIe Gen3 x16 and 1330ms at PCIe Gen2 x16, on a i7-3770K. This suggests that the transfer time portion is 360ms / 720ms[1], the CPU/driver portion is ~600ms, and the GPU rendering portion is negligible (see below).

Measuring these values directly is rather difficult from a reverse engineer's perspective. A crude but effective way to see the interplay between CPU and GPU use is to use GPUView, which gives rough estimates to how long each frame takes to render.

GPU render time was measured (using RenderDoc) to be ~3.7ms for a 1050Ti when set to render at 3840x2160. So the GPU is not doing much, and is instead mostly bottlenecked by the CPU/driver and resource transfer.

There are a few way to try solving the issue:
1. Work within the KT rendering paradigm, but reduce slow parts:
a) CPU/driver time
Not really possible.
b) Resource transfer time
Possible to shrink 512x512x32 texture, but doesn't avoid driver overhead.

2. Forget about Arland's original text rendering method and replace it altogether.
Use a large font texture preloaded into memory, and render from that texture to the screen using two triangles per character.
The problem is, rewriting the entire text rendering part of the engine is... difficult to implement as an extension to how they are currently doing it. The frustrating part is that they did it correctly already in other games: Sophie/Firis/LydieSuelle PC render text correctly.

Incidentally, I don't expect too much improvement on iGPUs, as they are limited by extremely low memory bandwidth and the reduction in cost of resource transfer (if the driver is even smart enough to skip the copy) is likely offset by a significant increase in cost of compositing.

On the other hand, architectures like the PS3/PS4 should do significantly better, and the PS3 versions I have exhibit minimal menu stutter. The RSX can pull in a CPU texture at 15.5GB/sec[2], and does not have to pay the NVIDIA/AMD driver tax to transfer the resource over.

[1] RenderDoc says there are 2400 1MB resources touched. I presume this to be 1200x CPU writes to texture, 1200x GPU reads from texture. This suggests 1200MB of data transferred over the PCIe bus on that frame, which at PCIe Gen3 x16 (12GB/sec) should only be 100ms. This is much less than the inferred time of 360ms, which makes sense as there will be a DX11 driver tax to copy the resource over to GPU memory.
[2] https://en.wikipedia.org/wiki/RSX_Reality_Synthesizer#Speed,_bandwidth_and_latency

[Wazhai]

Curiously, there is no noticeable menu lag in Rorona Plus on RPCS3. I wonder how the emulator achieves this. Also that is some amazing software performance sleuthing, 百合 姫.

[百合 姫]

Originally posted by Wazhai:

Curiously, there is no noticeable menu lag in Rorona Plus on RPCS3. I wonder how the emulator achieves this. Also that is some amazing software performance sleuthing, 百合 姫.

A real PS3 has stutter, but it's 20 frames (~333ms) to get into the menu. It's 40-42 (~700ms) for the alchemy menu.

[Unyaa]

I have a laptop with an Nvidia GPU and a desktop with an AMD GPU. I get the lag on the laptop and not the desktop. In fact, the desktop is incredibly snappy-feeling

[百合 姫]

Originally posted by 百合 姫:

1) renders each character to a 512x512 32-bit texture, on the CPU, in system memory
2) composites it to a destination texture, in video memory. This necessitates a transfer from system memory to video memory
3) immediately displays the composited texture on screen.

https://steamcommunity.com/app/1152300/discussions/0/3345546664208090238/
Possible fix for the stutter issue.

Because some people say it works, I can conclude I was wrong on (2) - the composition actually happens on the CPU side. This makes my life much easier.

The game code does this:
1. Map a 512x512 GPU texture for writing so the CPU can write to it.
2. Write to the GPU texture.
3. Create a new texture on GPU side that the CPU can read, identical in size and format to the first one.
4. Schedule a copy from the written texture to the new texture.
5. Map the new texture for reading by the CPU
6. Read the texture from GPU, compositing on the CPU
7. Destroy the new texture.

The solution I used basically does this:
1. Allocate CPU memory, and return a fake pointer to the game. Ignore the Map call.
2. Game writes to the buffer, which doesn't have to be copied anywhere.
3. Create a baby texture on the GPU side. This could actually be faked, but whatever.
4. Fake the copy from new to old texture. Here I just change the tracking pointer from the destination to the source.
5. Return the fake pointer to the game. Ignore the Map call.
6. Game reads from the fake pointer. Deallocate CPU memory on Unmap.
7. Destroy the new texture.

[Digestneko]

Originally posted by 百合 姫:

Originally posted by 百合 姫:

1) renders each character to a 512x512 32-bit texture, on the CPU, in system memory
2) composites it to a destination texture, in video memory. This necessitates a transfer from system memory to video memory
3) immediately displays the composited texture on screen.

https://steamcommunity.com/app/1152300/discussions/0/3345546664208090238/
Possible fix for the stutter issue.

Because some people say it works, I can conclude I was wrong on (2) - the composition actually happens on the CPU side. This makes my life much easier.

The game code does this:
1. Map a 512x512 GPU texture for writing so the CPU can write to it.
2. Write to the GPU texture.
3. Create a new texture on GPU side that the CPU can read, identical in size and format to the first one.
4. Schedule a copy from the written texture to the new texture.
5. Map the new texture for reading by the CPU
6. Read the texture from GPU, compositing on the CPU
7. Destroy the new texture.

The solution I used basically does this:
1. Allocate CPU memory, and return a fake pointer to the game. Ignore the Map call.
2. Game writes to the buffer, which doesn't have to be copied anywhere.
3. Create a baby texture on the GPU side. This could actually be faked, but whatever.
4. Fake the copy from new to old texture. Here I just change the tracking pointer from the destination to the source.
5. Return the fake pointer to the game. Ignore the Map call.
6. Game reads from the fake pointer. Deallocate CPU memory on Unmap.
7. Destroy the new texture.

This fixed the menu stutter problem for me. Thank you very much.
It was kinda annoying previously having to wait 1-2 seconds every time when opening menus and turning in items for the assignments.

[stonegcs]

Thanks for the fix, it does clear out the annoying menu lag of 1-2 seconds.

Is there a way to reduce the cauldron and hom board delay too?

[百合 姫]

Originally posted by stonegcs:

Thanks for the fix, it does clear out the annoying menu lag of 1-2 seconds.

Is there a way to reduce the cauldron and hom board delay too?

It only fixes GPU stutter. CPU stutter is not affected.