plushkava
Published
Crashed with a buffer overrun reported by the Visual C++ Runtime Library, attributed to CheckApplication.exe.
Initially could not launch. Increased RLIMIT_NOFILE to 1048576 to accommodate Proton's ESYNC feature and now it runs nicely.
Upon launch, a window is displayed, after which the game immediately exits, rendering it unplayable.
+set r_fullscreen 1 +set com_skipintrovideos 1
Not that I would play with a gamepad, but I could not get the game to recognise a DualShock 4.
Performance on this machine was a bit disappointing, especially since the BFG edition backports a few enhancements from the id Tech 5 engine.
Linux users are better served by the dhewm3 source port, which is compatible with the assets from the original Doom 3 game (not the BFG edition).
Locked at 58 fps
Inspection with DXVK_HUD=fps reveals that the frame rate is locked at 58 fps.
It appears to be a fault with the game, rather than Proton. Either way, I cannot recommend a shmup that exhibits constant micro stutter.
Locked at 58fps
Inspection with mangohud reveals that the frame rate is locked at 58 fps.
It appears to be a fault with the game, rather than Proton. Either way, I cannot recommend a shmup that exhibits constant micro stutter. Replacing an earlier report because I accidentally wrote that DXVK was used to check the frame rate (the game uses OpenGL).
Locked at 58 fps
Inspection with mangohud reveals that the frame rate is locked at 58 fps.
It appears to be a fault with the game, rather than Proton. Either way, I cannot recommend a shmup that exhibits constant micro stutter.
Runs flawlessly but always shows an annoying warning upon launching.
Upon starting, a dialog box appears with the warning: "Debug version has been selected for DirectX run time. Application may not run on intended performance." After dismissing, it proceeds to run flawlessly. The dialog box can be eliminated by using dgVoodoo as a Direct3D 9 wrapper. Ultimately, I chose not to because it reduces performance on my machine. Still, those with more powerful rigs might consider it.
Going to the resolution settings and cycling through the next two available options resulted in extreme CPU burn, rendering the entire desktop (Gnome) unresponsive. I had to reboot in order to resolve the issue. Aside from that, the game runs too slowly to be playable.
As reported by other users, full screen mode doesn't work and it may be necessary to enable the D-pad only option to prevent upward drift. Works fine otherwise.
Steam appears to install .NET Framework 3.5, after which the game does not launch. I was then able to launch the game with WINE 4.0-rc3 but not Proton.
WINEDLLOVERRIDES=d3d9=n,b %command%
I used dgVoodoo as a Direct3D 9 wrapper, for the purpose of achieving perfect integer scaling in a full screen mode. To do so, I copied the D3D9.dll to the game's directory then ran the game once to generate a dgVoodoo.conf file. Next, I edited this file, merging in the following changes.
[General]
ScalingMode = centered_ar
[DirectX]
AppControlledScreenMode = false
DisableAltEnterToToggleScreenMode = false
ForceVerticalSync = true
For Proton to use the wrapper, it is necessary to set custom launch options, as noted. Finally, I launched the game and used its configuration tool to set the following options:
- Screen Mode = Window
- Window Size = x4 (1696x960)
Once the game is running, pressing Alt+Enter will signal dgVoodoo to switch to a full screen mode, with perfect integer scaling being achieved at 1080p.
The game is not couch-friendly because it always displays a configuration dialog box upon being launched.
Launches in a cropped overlay despite being in full-screen mode. Have to press Up, Up, Z to reach the options, at which point switching to windowed mode then back to full-screen mode resolves the issue until the game is next launched.
Did not maintain 60fps on Low graphics settings. Could be due to my weak GPU but rating as Silver because the FPS gauge reported 60, despite the obvious frame rate mismatch.
On this system, trying to enter fullscreen mode results in the game pegging a single CPU core and needing to be killed. Runs fine in windowed mode.
Couldn't launch with Proton - potentially an issue with the Flatpak version of Steam only. Launches and runs fine with WINE 4.0rc3 after installing lib32-openal.
Doesn't quite maintain 60fps on this hardware but runs perfectly otherwise. I recommend disabling the horrible graphical filter and the 16:9 display support in the game configuration tool (the latter results in a non 1:1 pixel aspect ratio).
Runs flawlessly. I recommend disabling the graphical filter and the 16:9 display support in the game's Controller Layout Tool.
Could find no way to make the game run in full screen mode. The only screen settings available are 1x and 1.5x scaling (in a window). The game itself runs too slowly to be playable.
Runs too slowly to be playable.
Game runs at 30fps, half the expected frame rate.
Another reporter claimed that switching to fullscreen mode fixes the 30 fps issue. I have not found this to be the case.
WINEDLLOVERRIDES=d3d8=n,b MESA_VK_WSI_PRESENT_MODE=mailbox %command%
With Steam Input disabled, a DualShock 4 worked but without its D-pad being mapped. Only the analogue stick could be used to move the player character.
The game runs at 30fps (half the expected frame rate).
For whatever reason, the game expects to be able to push frames at 120fps, with the perceptual frame rate being half of that. Here is how I got it to work. Firstly, I installed dgVoodoo to the game's folder. Note that no configuration whatsoever of dgVoodoo is necessary. In fact, only the provided D3D8.dll file needs to be dropped in. The result will be that Direct3D 8 draw calls are translated to Direct3D 11, thus allowing for DXVK to function. Secondly, I defined launch options in Steam to make Vulkan operate in "mailbox" mode. Effectively, this enables an adaptive vsync mode, whereby the game is allowed to push frames at whatever rate it needs to, while eliminating screen tearing.
vblank_mode=1 %command%
Strangely, not only does the game's full screen option drastically reduce performance, but it doesn't work correctly (the Plasma taskbar remained visible). Turning off the option addressed both issues.
In addition to disabling the full screen in-game option for an effective full screen mode (really), I found it necessary to coerce vsync at the level of the amdgpu driver to eliminate tearing. The game is also very slow to start up but runs well once its menu has appeared.
As others have correctly reported, the mfc42 DLL is required, along with a DLL override, so as to use the bundled DirectDraw wrapper.
WINEDLLOVERRIDES=ddraw.dll=n,b %command%
Upgraded the bundled dgVoodoo and set "ScalingMode = centered_ar" and "Resolution = max_isf" in dgVoodoo.conf for perfect integer scaling of 640x480 to 1280x960 at 1080p.
It would be trivial for Valve to make this work out of the box and they ought to.
Press F4 to go into full screen mode. Rating as Gold instead of Platinum because the frame rate was smoother in windowed mode.
Player selection screen appeared in 640x480 overlay in top-left corner, after which it became completely unresponsive and started to burn CPU cycles. I was only able to escape by rebooting with the three-finger salute (in Gnome).
OpenGL mode demonstrates various texturing issues. Direct3D mode does not work. High input lag. Not really in a playable state.
Had to disable D3D11 to prevent an access violation from occurring. The frame rate is atrocious on this hardware, making the game effectively unplayable.
Poorly optimised. Requires stronger hardware than is typically expected for the genre.
Couldn't maintain 60 fps at 1080p and minor screen tearing was apparent, even in the "Fastest" rendering mode.
Screen tearing
Upon first launching the game, I encountered severe screen tearing. Unlike many Japanese shmups, there is no standalone configuration tool, nor is there any in-game option to enable or disable v-sync. I eliminated the screen tearing by creating a dxvk.conf file in the game's directory, containing the following two lines.
d3d9.presentInterval = 1
d3d9.numBackBuffers = 2
I have noticed that Valve already applies this same configuration for at least one other shmup, namely DoDonPachi Resurrection (and with good reason).
Crashes upon start with "Win32 function failed: HRESULT: 0x80004005 Call: at line 223 in file \Graphics_DisplayM.cpp".
Works well.
Occasional microstutter, especially during animations outside of the main game loop. Barely noticeable in practice.
Upon launch, a window is displayed, after which the game immediately exits, rendering it unplayable.
Runs flawlessly.
Needed Steam Input to be enable for my DualShock 4 to be recognised. The game is not quite couch/deck friendly because it always starts in a Windows mode and the options, though appreciated, require a mouse to interact with.
