Proton
Proton copied to clipboard
ValveSoftware
Phantasy Star Online 2 New Genesis (1056640)
Compatibility Report
- Name of the game with compatibility issues: Phantasy Star Online 2
- Steam AppID of the game: 1056640
System Information
- GPU: RX 470
- Driver/LLVM version: Mesa 20.1.4/10.0.0
- Kernel version: 5.4.55-1-lts
- Link to full system information report as Gist
- Proton version: 5.0-9
I confirm:
- [x] that I haven't found an existing compatibility report for this game.
- [x] that I have checked whether there are updates for my system available.
Symptoms
The game would not launch when you click the Start Game button in the game's own launcher. pso2.exe runs in the background as a zombie process.
Reproduction
- Launch the game from Steam.
- Press the Start Game button in the game's launcher
Log
Google Drive link to steam-1056640.log, It kinda blew up to 53 MB in just a few seconds when opening up the game.
I tried with 5.9-GE5-ST, it shows a window and crashes after a second.
With 5.0.9 the launcher was super unresponsive and after getting the start button to work, the game never opens.
I encounter the same behaviour as @PSebs running 5.0-10 RC. Similar hardware.
I tried with 5.9-GE5-ST, it shows a window and crashes after a second.
With 5.0.9 the launcher was super unresponsive and after getting the start button to work, the game never opens.
Same exact experience here. This game uses nProtect GameGuard, which is a rootkit anticheat. I feel like unless someone makes a patch specifically for this game (or nProtect GG in general) it's very unlikely it will be playable.
well for some reason I got the SEGA intro playing before I got that same error (with the same '5.9-GE5-ST' proton version): steam-1056640.log
for some reason when I tried launching the game the first time I never got any error screen ....just a blank screen (neither SEGA intro either): steam-1056640.log
...oh and, at least for me the launcher worked really, no issues with it's responsiveness
my system spec:
inxi -bxx
System: Host: 91-158-92-139 Kernel: 5.3.18-lp152.36-default x86_64 bits: 64 compiler: gcc v: 7.5.0 Console: tty 1 dm: SDDM
Distro: openSUSE Leap 15.2
Machine: Type: Desktop Mobo: ASUSTeK model: Z170 PRO GAMING v: Rev X.0x serial: 150647662404153 UEFI: American Megatrends
v: 3805 date: 05/16/2018
CPU: Quad Core: Intel Core i5-6600K type: MCP arch: Skylake-S speed: 4400 MHz min/max: 800/4400 MHz
Graphics: Device-1: NVIDIA GM204 [GeForce GTX 970] vendor: eVga.com. driver: nvidia v: 450.57 bus ID: 01:00.0
chip ID: 10de:13c2
Display: server: X.org 1.20.3 compositor: kwin_x11 driver: nvidia tty: 286x41
Message: Advanced graphics data unavailable in console for root.
Network: Device-1: Intel Ethernet I219-V vendor: ASUSTeK driver: e1000e v: 3.2.6-k port: f000 bus ID: 00:1f.6
chip ID: 8086:15b8
Drives: Local Storage: total: 35.95 TiB used: 191.53 GiB (0.5%)
Info: Processes: 285 Uptime: N/A Memory: 15.57 GiB used: 1.98 GiB (12.7%) Init: systemd v: 234 runlevel: 5
target: graphical.target Compilers: gcc: 7.5.0 alt: 7 Shell: bash v: 4.4.23 running in: tty 1 inxi: 3.1.00
Until there is a patch for GameGuard, this will all be a lottery. For example Lineage 2 in isolated cases works with GameGuard.
some progress...I get now this far:
and then it stops on GameGuard...but it does ask to send crash report or something...well once the 2nd time it just crashes/stops and sends you to this link: https://www.gameguard.co.kr/gameguard/faq/eng/FAQ_114.htm
system info:
inxi -b
System: Host: localhost Kernel: 5.12.4-1-default x86_64 bits: 64 Desktop: KDE Plasma 5.21.5
Distro: openSUSE Tumbleweed 20210524
Machine: Type: Convertible System: HP product: HP ENVY x360 Convertible 15-ee0xxx v: Type1ProductConfigId
serial: <superuser required>
Mobo: HP model: 876F v: 13.40 serial: <superuser required> UEFI: Insyde v: F.15 date: 11/12/2020
Battery: ID-1: BAT1 charge: 49.6 Wh (100.0%) condition: 49.6/51.0 Wh (97.2%)
CPU: Info: 8-Core AMD Ryzen 7 4700U with Radeon Graphics [MCP] speed: 1486 MHz min/max: 1400/2000 MHz
Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Renoir driver: amdgpu v: kernel
Display: x11 server: X.org 1.20.11 driver: loaded: amdgpu,ati unloaded: fbdev,modesetting,vesa
resolution: <missing: xdpyinfo>
OpenGL: renderer: AMD RENOIR (DRM 3.40.0 5.12.4-1-default LLVM 12.0.0) v: 4.6 Mesa 21.1.1
Network: Device-1: Realtek RTL8822CE 802.11ac PCIe Wireless Network Adapter driver: rtw_8822ce
Drives: Local Storage: total: 593.96 GiB used: 196.73 GiB (33.1%)
Info: Processes: 298 Uptime: N/A Memory: 15.01 GiB used: 4.08 GiB (27.2%) Shell: Bash inxi: 3.3.03
So with the announcement of the Steam Deck and mention of other anti-cheat platforms being worked with to add support in Proton, is it possible someone at Valve could reach out to nProtect/GameGuard to do the same? This is one game I'd like to have on the device, but short of loading Windows on it, this is likely a no-go unless there is some push to get GameGuard to actually support the platform or Proton.
As an additional note: GameGuard seems to be the only roadblock here. Sega has provided a 'Character Creator/Benchmark' tool which runs the same engine but does not have GameGuard added as it is 100% an offline only tool and it has been reported to work fine via Proton.
It is. GameGuard used to be popular in Lineage 2 and is still in some versions, and everything works fine without it. There have been many tests by me.
Unfortunately (though not unexpectedly), issue still persists as of current Experimental and forks. Since this is one of the few games I keep a Windows install for, I'd really like to see this resolved.
Currently the game is now booting, but has huge performance issues related to IO. Unless the game has terrain render distance set to the minimum it takes too long to load and times out. Even when in game the game has huge stuttering from IO unrelated to shader caching. Base PSO2 is playable for the most part, but NGS is nearly unplayable to the performance.
Indeed, I can confirm that the game now boots, on both GE and Experimental.
PSO2 classic works perfectly, as far as I can tell. Which is a good thing. But like the comment above, NGS seems to have issues. Bad IO seems like a very familiar problem NGS has, even on Windows - from my experience, a first boot will always take a really long time; but on the high capacity rotational drive I'm playing it on (not enough space on solid state to put it in), in Linux, I can't seem to connect - quits on Error 630... usually just as the player character spawns in. Might be a network connectivity error, however I have yet to confirm this on the Windows side.
5MIN EDIT: So I went back and checked. The same machine on the Windows partition can successfully connect and load into NGS spawn just fine. On Linux, I've noticed that it does get as far as loading the event call, and even receives a local convo from some players amidst the duration of loading, but most of this time is spent staring at a frozen display w/ sound while it's fetching data. With KSysGuard, I can tell that it's still connected and receiving/sending some KBs of data back and forth for most of this. But as soon as the screen unfreezes, the connection is immediately killed in Error 630 as it jumps into a disconnected Aelio.
Proof:
Could this be linked to the I/O problems? Perhaps. But I've also no other choice due to lack of space on solid state storage. Said drive is NTFS (the compatdata is symlinked back into a BTRFS user home dir - the same setup I use for all my other games and reports).
F2FS stutters extremely hard, but is borderline "playable" compared to ext4 and xfs which I tried also. It seems like the game is unloading everything from memory the moment it is able to. The game seems to result in a ton of standby cache memory generated extremely quickly on Windows.
I don't think I can agree that it's IO bound. I have the game installed on an NVME ext4 disk. Like everyone else, I have to set the game settings to minimum or else I get timed out. But I'm pretty sure this has to do with longer shader compilation times and not disk.
While the game was loading in, I didn't see read speeds exceeding 22MB/s. My NVME is capable of speeds many factors greater than that.
Contrived example:
dd if=/dev/urandom of=some_file bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB, 1000 MiB) copied, 2.4026 s, 436 MB/s
I also recorded the tracepoint block_rq_issue, which according to the kernel docs and this person's blog should indicate which process is causing heavy disk usage.
This screenshot is from graphics setting 1 - Lowest
sudo perf record -e block:block_rq_issue -ag
# run game, run around teleport places
^C
sudo perf report
According to this report, pso2.exe accounted for <6% of total disk activity.
Prometheus Node Exporter accounted for more disk usage than the game, and that's supposed to be a lightweight metric collecting daemon.
I repeated the same test with graphics setting 6 - Super and got similar results.
I'm fairly certain that the issue in this game is DXVK cache related. I can correlate each stutter with a change. While hardly scientific, it still appears to be a common problem with a lot of proton games.
EG: open terminal
while true; do
sleep 1
md5sum ~/.local/share/Steam/steamapps/shadercache/1056640/DXVK_state_cache/pso2.dxvk-cache
done
Move around, experience stutter, watch md5sum of cache change.
Sitting still or rotating the camera does not cause stutter.
To reinforce this theory I teleported to Camp Keeland, experienced one stutter (which may have been caused by the sudden sand storm). I then cleared the pso2.dxvk-cache file and redid the same test. The stutters were measurably longer.
Phantasy Star Online 2: New Genesis framerate problems
Issue transferred from https://github.com/ValveSoftware/Proton/issues/5781. @CathyRina posted on 2022-04-22T20:12:43:
Compatibility Report
- Name of the game with compatibility issues: Phantasy Star Online 2: New Genesis
- Steam AppID of the game: 1056640
System Information
- GPU: AMD AMD Custom GPU 0405 (vangogh, LLVM 13.0.0, DRM 3.45, 5.13.0-valve10.1-1-neptune-02144-g7fffaf925dfb)
- Driver/LLVM version: 4.6 (Compatibility Profile) Mesa 22.0.0-devel (git-676ccacebc)
- Kernel version: 5.13.0-valve10.1-1-neptune-02144-g7fffaf925dfb
- Link to full system information report as Gist: https://gist.github.com/CathyRina/ec924f5ac8776136bd2c12e194755661
- Proton version: 7.0-2
I confirm:
- [x] that I haven't found an existing compatibility report for this game.
- [x] that I have checked whether there are updates for my system available. steam-1056640.log
Symptoms
Game boots up fine however the framerate dies after selecting a character & loading the main map.
Reproduction
Boot up the game, select a server, select a character
Can confirm seeing these loading/stuttering issues on my 256GB Steam Deck loaded onto main storage, current stable SteamOS build. All default launch/proton options. Just install and launch.
Even lowering all graphics settings that I can on the PSO2 Classic side and trying to switch to an NGS block it still stutters bad when trying to load. Eventually gets in but throws the Error 630 'No response from PSO2 server'. Even the PSO2 classic lobby stutters good, similar to the early days of the PC Launch. But classic does load and run.
Honestly shocked to see the GameGuard concern just solved out of nowhere, though. So close to being functional.
I still believe it is an IO issue given that if DXVK is used on Windows for this game the stutters clean up even on the AMD proprietary drivers under Windows which compile shaders much slower than ACO. Also the game has extremely small sizes per file compared to most games. The game contains over 500,000 files with some of them being as small as a few hundred bytes.
I'm curious if using an Nvidia gpu or the AMDGPU-PRO drivers would have any effect as both vendors with dxvk on Windows do not have the issues that are occurring on Linux with the RADV drivers.
Base PSO2 seems to run at a perfect 60fps unless an asset needs to be loaded. This is worst in Lobby, minor annoyance in quest and basically not a issue in private quaters. This might suggest that the asset streaming isn't optimized because once the assets are loaded it seems to run just fine.
and once an asset unloads the moment it loads again it still has the same stutter even when a shader cache is built up.
I'm curious if using an Nvidia gpu or the AMDGPU-PRO drivers would have any effect as both vendors with dxvk on Windows do not have the issues that are occurring on Linux with the RADV drivers.
FWIW I'm using Nvidia, so. . . I'm definitely noticing somewhat repetitive pauses with repeat assets in the same session in classic, but would still call playable regardless. Again; PSO2 was never a very well opt'd game in the first place, so it isn't much of a shocker that it has some problems that only now crop up.
game doesnt load on the amdgpu-pro driver, don't think that makes a difference.
I played ngs intro with a new character up to the attack, then my game kept disconnected during the loading screen for after the attack occurred with error code 630. -- I checked reddit, found this https://www.reddit.com/r/PSO2NGS/comments/o385fs/ngs_630/, then based on point (2) set my graphics to lowest -- it allowed me to login again.
As a test, I then let the in-game cinematic play for after the attack, set settings back to ultra, logged out, then tried to log in and once again was greeted with error 630. So -- something funky is going on with loading the games assets over the network I assume.
I confirm that now that it appears the Anti-Cheat lets us join, there are heavy stutters that appear to be caused by asset loading. Using DXVK HUD, I could confirm there's no shader compilation happening during the stutters/freeze.
Also, setting the Terrain Draw Distance to 1 and everything else to max has allowed me to avoid any disconnection issue before, but I do experience timeouts today.
Also, someone suggested that DXVK may still be a worthy culprit somehow but the game do runs with PROTON_USE_WINED3D=1and when it did, I still encountered the exact same loading issue that prevented me to get in-game. So while DXVK state cache shenanigans may be a symptom, I don't believe it's the crux of the matter.
This looks like a potential Wine issue with the client. Could be the AC as well, who knows...
Proton Log:
Replying to https://github.com/ValveSoftware/Proton/issues/4122#issuecomment-1107814338
Setting terrain draw distance to 1 did indeed allow me to connect to ngs without getting the 630 error without needing to set everything to low.
It maybe placebo, but I compiled a new kernel linux518-tkg-cfs with the multigen LRU v10 patch and I seemed to have a slightly smoother experience with PSO2NGS compared to the build of linux517-tkg-cfs without the LRU patch I was using before. The amount of time the stutter occurs seems to be a bit shorter most of the time. I'd assume 5.17 with the Multigen LRU v9 patch would fare the same. The kernel patch did not seem to effect loading into the game initially at least for what I noticed.
For what I have looked into and heard from people who are experienced from tinkering with the game on Windows apparantly the file names for the assets are extremely long as they are based off the MD5 of the path as well as the file name and extension. I'm thinking the long file names could be causing performance issues on most file systems. Would this be a possibility?
For what I have looked into and heard from people who are experienced from tinkering with the game on Windows apparently the file names for the assets are extremely long as they are based off the MD5 of the path as well as the file name and extension. I'm thinking the long file names could be causing performance issues on most file systems. Would this be a possibility?
As far as filesystems go, I had installed the game on ZFS backed by SSD, with 16 GB ARC. ZFS ARC I believe has a comprehensive cache subsystem with "innovative" algorithms compared to "simple" LRU and I didn't get the impression I was having it better than anyone else.
During the stutters indeed, I notice what appears higher I/O on loading the "checksum-like named" assets. I believe there core of the issue is there, especially since the game doesn't looks like it's using more than 2 cores, possibly just 1 if we say the second one is for the rendering but I may be wrong.
In PSO2 basic, you can notice the same phenomenon, but since the base game is "instance areas"-based, it happens mostly when the game loads all assets for the area, and almost not at all afterwards while you're playing in the area.
In constrast, NGS appears to be more "open-wordly" and loads assets as gameworld encounters them (very apparent in PSO2 basic lobby as well where there are many assets that couldn't be predicted/pre-loaded) Somehow, between the way Wine translates the file calls or the way Linux handles such calls, or how the game expects the system to answer back, something is wrong...
I'm trying to play PSO2 classic. It stutters on loading assets, but is mostly playable. However, in the lobby, it stutters to the point it's almost unplayable. Sometimes the game freezes on a black screen right after I choose my character and select "Start Game [PSO2]", so I have to kill it and start over. The xorg mouse cursor shows up in the middle of the screen every time I go to a different location/scene, and sometimes when a menu pops up. I'm playing with a gamepad, so I have to reach for the mouse and move it, and then it goes away. Very annoying.
Somebody have a workaround for me ? When I finished the tutorial, and the multiplayer mode was enabled, I was disconnected, and now, when I try to be connected to the server, I have always an error after a long time my game screen was freezing on the loading screen
Result : https://www.zupimages.net/up/22/21/hceh.png
Is there any workaround as well to avoid sometimes latency ?
I use Proton GE 7-14 and I'm on Gentoo Linux
Try reducing your terrain draw distance to the lowest first, if that doesn't work then try reducing graphics settings completely using the presets.
What do you mean by latency, are you referring to the stutters? because the stutters are unavoidable currently.
Reducing terrain draw distance solved my freezing issue. I don't know if it's stutters, but normally the game is very fluide, but sometimes, when the game load something (I guess), I have a small latency.
Reducing terrain draw distance solved my freezing issue. I don't know if it's stutters, but normally the game is very fluide, but sometimes, when the game load something (I guess), I have a small latency.
These be the problems we've been discussing in this thread earlier (regarding New Genesis, which is what's displayed in your screenie), which has yet to be addressed. NGS is essentially unplayable; PSO2 Classic is fine with only marginal loading hitches in the lobby, in comparison.