Dead to Rights: Retribution [BLES00824]
Started by wffl

12 posts in this topic

5 posts 0 threads Joined: Feb 2021
03-27-2021, 05:37 AM -
(03-24-2021, 03:16 AM)Ani Wrote: You uploaded an empty log, if the game crashes you need to manually compress the uncompressed log
Do I compress the same log (RPCS3.log.gzwhile the emulator is still running, or is there a function build in the emulator?

Should I have just compressed the log RPCS3.log.gz after playing the game?

Or am I just uploading the wrong log?

If so, what should be the log I'm supposed to upload?

Thank you.

EDIT: I went ahead and compressed the RPCS3.log file into a 7z, just like the guidelines state, I hope this is the right log.

I also managed to not only get the crash after just a minute or so, but the emulator actually crashed completely after it.

.7z   RPCS3.7z (Size: 153.85 KB / Downloads: 0)
This post was last modified: 03-27-2021, 04:57 PM by Wolfinston85.

7 posts 1 threads Joined: Apr 2021
04-22-2021, 06:00 PM -
.7z   RPCS3.7z (Size: 98.59 KB / Downloads: 1)

Game would be otherwise playable at good speeds, but crashing with dead FIFO. I tried(both on and off and mostly each individual or in small groups):
- xaudio2 & opengl(with and without buffering, I kept always downmix to stereo), no audio
- accurate GETLLAR and other "accurate" options in debug tab
- "GPU texture scaling" as well as "force CPU blit emulation"
- disabling vulkan memory allocator and FIFO reordering
- accurate PPU 128 reservations(enabled or off)
- I tried relaxed zcull sync as well as driver wake-up delay(50-4000us)
- all timer options
- PPU accurate vector NANs as well as "accurate RSX reservation access"
- both opengl and vulkan, with and without write color buffers and strict rendering(all combinations)(I use force 4:3 and 480 res.)
- framelimit auto and 30
- tried no. of shader compilers 1 and 2
- TSX off and forced
- accurate xfloat and SPU loop detection
- kept always SPU block size at "safe"
- SPU dec. fast interpreter, ASMJIT and LLVM
- PPU fast int. and LLVM
- SPU prefered threads 1 and 2

So I tried above options both on and off and in various combination. I always cleared at least SPU and shader cache in between runs. Probably biggest improvement was when I set PPU to fast interpreter. Then it always(if I recall) passed first cutscene but still hanged in early gameplay. ASMJIT also helped a bit. Driver wake-up delay seem to have no effect despite TTY log in the screenshot telling it should. Opengl or no audio instead xaudio2 made intro much smoother I think. Saw in log that audio crashed, issue could be if audio is handled with SPU's and game is sensitive. Because game would be playable at full speed on my 4c CPU, it help expose fragility of current implementation despite potentially running well on CPUs with more cores. I hope all this help.
4690k @4.2ghz ,16gb ram, gtx1060 6gb, win7

7 posts 1 threads Joined: Apr 2021
05-04-2021, 12:53 PM -
I just want to confirm that game was never really stable enough, including above claimed version "v0.0.8-9537-9d1bb60a".
I tested:

All of them crashed with mentioned FIFO desync and as described before. This time I tested quickly just with:
strict rendering mode,
accurate GETLLAR,
write color buffers,
driver wake-up delay: 200us,
prefered SPU and shader compiler threads: 1
and ASMJIT to gain some potential stability margin.

Game *may* be stable on strong CPU's with many cores, but fragility is exposed on my system even though game would otherwise be playable.
This post was last modified: 05-04-2021, 12:55 PM by romano.
4690k @4.2ghz ,16gb ram, gtx1060 6gb, win7

Forum Jump:

Users browsing this thread: 1 Guest(s)