Closed rz5 closed 1 year ago
Is it working in the SW renderer of the 1.2 release?
As far as I know,that game never worked in any hardware mode and in software mode it works but it's extremely slow and you can get a little more speed from VU Stealing(you get more speed for a short time) but it's like the game notest this and..."ohh you are using hacks to get more speed ehh,lets slow the speed even more until you disable them and then I'll restore it again to the normal slow speed" :D
Ok. It was to be sure it wasn't related to the SW fixes done recently, which aren't backported yet into the HW renderer.
Is it working in the SW renderer of the 1.2 release?
just tested it out and software mode does work fine on the 1.2.1 build.
just tested it out and software mode does work fine on the 1.2.1 build.
By "work" you mean it works but slow or? Depending on the place and what you are doing,you can get from 60 to I think 5(not sure but for example when you using the vu stealing and try to switch forms,the speed goes down by a lot)
Speed is awful as usual :p , the black screen issue is resolved though.
edit: I'll try searching when hardware mode broke on this games. Binary search for the win :p
The description is misleading: Description
D3D9, D3D11 and OGL renderers are not able to draw anything on the screen. Instead it's all black. Only the software renderer is able to draw something.
D3D9, D3D11 and OGL renderers are not able to draw anything on the screen <--Hardware renderers?
Only the software renderer is able to draw something. <--Draw something means normal, bugless display?
Managed to find the commit which broke hardware rendering at the following game, the hardware mode of revisions older than r5072 works perfectly. :)
Obviously Gab did very small commit so it is easy to find the root cause. Snif.
So 2 things to test 1/ First enable this hidden option:
preload_frame_with_gs_data = 1
2/ If it doesn't work,
a/ remove the options
b/ edit GSTextureCache.cpp
c/ remove the line 435 m_renderer->m_dev->ClearRenderTarget(dst->m_texture, 0); // new frame buffers after reset should be cleared, don't display memory garbage
1/ First enable this hidden option: preload_frame_with_gs_data = 1
That did the trick, all the hardware renderers works fine when preload_frame_with_gs_data
is set to 1.
It is magic, isn't it :+1:
Ok. I vaguely remember another game that suffer a similar issue (armored something) @ssakash you gain the job to add a new hack checkbox for this option :p
I'll add it , what should it be named on the dialog ? I was eventually planning to add mipmap at GSDX dialog for software mode so I'll add this along with it. :)
Dunno, "Preload Data Frame". This hack uploads some data when rendering a new frame (think as kind of overlay feature). Previous behavior just clear the frame to 0 (hence the dark force behavior;) ). Code comment
// Load GS data into frame. Game can directly uploads a background or the full image in
// "CTRC" buffer. It will also avoid various black screen issue in gs dump.
//
// Code is more or less an equivalent of the SW renderer
//
// Option is hidden and not enabled by default to avoid any regression
// new frame buffers after reset should be cleared, don't display memory garbage
That sounds like an attempt to solve the garbage on the Kingdom Hearts videos (which still doesn't work unless you cycle renderer)
@ssakash
That did the trick, all the hardware renderers works fine when preload_frame_with_gs_data is set to 1.
Did you used some old pcsx2\gsdx version with that option or the latest.I tried the latest and added that option in the GSdx.ini but I still get black screen in the HW modes
@refractionpcsx2
That sounds like an attempt to solve the garbage on the Kingdom Hearts videos (which still doesn't work unless you cycle renderer)
This also make me think about Tales of the Abyss...on certain areas if you use above native(even if you use the hack that removes the ghosting effect),you'll get grid wide grid like lines and the temporary fix is to switch between hw=>sw=>hw
One example is Engeve And when you switch hw=>sw=>hw,it stays like this
Did you used some old pcsx2\gsdx version with that option or the latest.I tried the latest and added that option in the GSdx.ini but I still get black screen in the HW modes
@vsub
I replayed it through GS Dump and that worked well with preload_frame_with_gs_data = 1
, could you check whether the issue is present using the Preload Data Frame
option in the following build : https://www.dropbox.com/s/o4xb7n2z1fo6a1s/GSdx32-SSE2.dll?dl=0
(I'll check it directly on the game when I get time)
If you mean to try this GSdx version with the game,then no,it's still black screen with both options enabled(mipmap and preload)on every hw renderer. If I switch to SW,the game will appear and if I switch to HW,it will freeze the frame
weird, it seems to be fixed only when replaying the dumps.
// new frame buffers after reset should be cleared, don't display memory garbage
That sounds like an attempt to solve the garbage on the Kingdom Hearts videos (which still doesn't work unless you cycle renderer)
No, the purpose was to ease the replaying of dump. First frame was always black on the HW renderer. Potentially the issue of KH is related to RT (not frame). Sometimes there aren't cleared (actually we need to load correct data). There are extra code enabled in debug code (GSTextureCache.cpp:326). There are potential others issues. It could be just another texture cache issue.
@bositman Updated the issue description, apologies for the confusion. Learned about these details in http://forums.pcsx2.net/Thread-GSdx-GUI-Clutter-in-the-renderer-dropdown-menu
I thought that by saying e.g. D3D9 renderer, the reader would unambiguously infer "the hardware renderer" and that there was only one SW renderer. I was wrong.
@vsub @ssakash I can confirm that "Preload Data Frame" doesn't fix the bug. What I get is garbage being flickered on screen.
https://github.com/PCSX2/pcsx2/issues/373
Is also fixed by Preload Data Frame option.
This bug is still blacktive with current git.
Is this still an issue ?
Seems,that way,I can only see something in Primal in SW mode
This game is very problematic on PCSX2, the GSDX Hardware render refuse to display anything, only the software render work.
Also, the speed is abysmal I never seen a game that struggle like Primal (12 FPS on a core I7 4770K and a GTX Titan).
It seems that the game actually worked once in HW mode When I try the GSdx from 0.9.8,it works(slow as in sw mode but it works)and not when I try 1.0.0
The buildbot don't have anything below 1.5.0 so I can't try finding since when it stop working
This guy says he was able to solve the problem in Linux by doing what the video description says. I tried but it did not work for me.
@gregory38 here are the dumps you requested for Primal. Prafull sent these recently.
Even longer dump
Thanks.
Reading the issue, it seems the preload option manage to fix the issue ? (Likely with limitations)
No, with preload frame data the game will display only 2 frame.
I decided to dig into this game a little more in addition to my performance fix and was able to identify what causes framebuffer loss. Game uses alpha channel of color buffers for storing PSMT8H textures. There is double buffer system in action both for these textures and for the rest of VRAM unoccupied by framebuffers and used for the other types of textures. In case with PSMT8H textures first buffer is located in Z-buffer, and second in color buffer. The second one is switchable, so when game renders something into color buffer, then alpha channel from another one is used for textures. And plugin for some reason clears entire buffer because of that. I made hack to show, that if textures aren't uploaded into alpha channel of color buffer, then deletion doesn't occur.
//for US version of the game
patch=1,EE,003C67E8,word,00051842
patch=1,EE,003C67F0,word,AC450014
patch=1,EE,003C67F4,word,AC430008
patch=1,EE,003C67FC,word,AC430010
This patch halves size of both PSMT8H buffers and relocates second buffer from color buffer into Z-buffer, now HW rendering works flawlessly. I think it shouldn't be too hard to fix this bug in the plugin. I couldn't test entire game with this patch, so I can't recommend playing to the end with it, but people desperate enough can try it.
Final notes and I'm done with this game.
There is one place in the game in the first world where texture on doors doesn't render right, it should be solid but instead covered with holes. Also few times through the entire game and only in some specific places there is SPS with black triangles stretching from the center to the borders of the screen. Switching rounding mode for VU can slightly decrease their intensity but will never get rid of them. And they can cover entire screen.
Another issue is with the rope, when you use it, there will be SPS. Switching clamping to Extra totally fixes it.
And last issue. In the end of the game, right at the moment when credits should show up, game may or may not freeze. This exact freeze may or may not happen after showing FMV where Jen visits Lewis in the hospital. Freeze happens at address 0x003EAEB4, where game endlessly tries to read IPU control register but doesn't get what it needs. This freeze is totally random but pretty common, I'd say the chance is 50% based on my testing. For experiment you can nop the branch at that address and game will continue further.
Also I decided to replay final world with the fix for HW renderer provided earlier and game didn't had issues with it at all, seems like PSMT8H textures never fully fill up those buffers, so maybe it's really safe to use it. Though, this bug really should be fixed properly on GSdx side.
That's it.
This needs testing with recent 1.7 dev builds, there are 2 things to notice there.
The gameDB have VU rounding applied which is wrong, this will cause glitches with the trees.
I don't seem to be able to produce the glitches mentioned more upper with sync XGKICK but that needs testing by someone who knows the game better.
I'm testing this demo disc again with PCSX2-32bit-AVX2-sha[7ea335e], all options set to their presumable highest accuracy settings.
I am getting the same results as in the OP, OGL and D3D11 renderers only show black frames but the pause menu does get successfully drawn. Software renderer can render scene correctly but there are some problems with exploding vertices.
Manually setting 'VU XGkick Sync' does not help. Changing the VU rounding modes to default does not help either.
I have the same issue in PS magazine 30 Primal.
_PCSX2 versions used:_ pcsx2-v1.3.1-1256-gbbd74e5 (latest dev build) _Emulation settings:_ "Safest" preset, MTVU hack not used. _Plugins used:_ GSdx AVX2, cddvdGigaherz _Plugin settings:_ CRC Hack Level "None"
Hardware Specifications
_CPU:_ Intel(R) Core(TM) i5-4690K CPU @ 3.50GHz _GPU:_ NVIDIA GeForce GTX 970 (Driver: NVIDIA 358.50)
Description
D3D9, D3D11 and OGL HARDWARE renderers are not able to draw anything on the screen. Instead it's all black. Only the software renderer is able to draw
somethingthe expected scene. OpenCL renderer remains untested.Screenshots
Software renderer output
GS dump
http://forums.pcsx2.net/attachment.php?aid=57681