deadinside28/bloodborne_pc

Same Issue in
Ryzen 7 5800H · RX 6600M · 32 GB RAM · Omarchy (Arch Linux)

How do I apply this fix on linux? Where should I use BB_CAMERA_Y=up?

present also in past version albeit in a lesser note

6800XT, R5 5600X, 16gb
CachyOS 7.2.9-1

when i use BB_CAMERA_Y=up with FSR 3.1, the NPC movement and camera have no visible smear/shimmer at all that i can see, here is one enemy lunging and its clear for fsr quality



Without BB_CAMERA_Y=up, only the cobblestones/doors/walls/stairs, essentially the environment smears, weirdly enough the player character and NPC's seem fine to me:

> Can confirm, after updating to 0.3 myself on linux, on a rx580 gpu, i saw horrible shimmering and smearing with FSR 3.1, as shown below:
>
>

Can confirm, after updating to 0.3 myself on linux, on a rx580 gpu, i saw horrible shimmering and smearing with FSR 3.1, as shown below:



I then applied your commit and used BB_CAMERA_Y=up when launching, with that flag, its back to clear like before the update:

Same issue. SteamDeck
Appears with any upscaler (FSR 3 Native AA, TAA)

### Second capture: when object motion drives the vectors, the reprojection is worse than doing nothing

A second 8-frame capture, this time while moving the camera fast (mean |mv| 19-28 px in the region, versus
0.85-2.5 px in the first capture). Tiles are 64x64, the region is the same relative area (right of centre,
lower half), and "worse" counts tiles whose residual with the port's vector exceeds the residual with no
motion at all.

| area | capture | no motion | port vector | best rigid shift | tiles where port is worse | mean \|objects.xy\| |
| --- | --- | --- | --- | --- | --- | --- |
| region | slow (first) | 9.68 | 6.64 (**+31.4 %**) | 4.19 (+56.7 %) | 17.7 % | 0.01 |
| region | **fast (second)** | 4.11 | 6.10 (**-48.2 %**) | 2.70 (+34.3 %) | **100.0 %** | **11.66** |
| rest | slow (first) | 4.79 | 3.91 (+18.3 %) | 2.47 (+48.3 %) | 39.1 % | 0.29 |
| rest | **fast (second)** | 5.15 | 6.42 (**-24.7 %**) | 2.75 (+46.5 %) | **91.4 %** | **3.49** |

So the failure scales with how mu...

### Addendum: the artifact disappears at a lower camera angle (and a caveat on my depth numbers)

The reporter adds that moving the camera to a noticeably lower angle - a more distant, grazing view - makes
both the DLSS shimmer and the TAA smear in that region disappear. That is useful, because it argues against
a texture/aliasing explanation: at a lower angle a pixel covers more texels, so aliasing should get worse,
not better. It fits a motion/reprojection error that depends on the view instead.

Caveat on the depth figures in my previous comment: I quoted the dumped linear depth without knowing its exact
convention - the whole frame spans only about 0.978 to 1.000 - so those numbers should be read relative to
the frame mean (0.9891) rather than as absolute near/far values. The claim that matters is not the depth but
this: in the affected tiles the best rigid shift is exactly zero (residual equal to no motion at all) while
`motion` reports about 1.2 px, and the affected pair is an ou...

### Second finding from the same capture: a screen region where the vectors claim motion that is not there (intermittently)

Different from the sign issue above, and this one matches what the reporter of the shimmer actually sees.
Region: render frame x 960-1472, y 256-768 (output 2560x1440: right of centre, lower half). Capture taken
with object motion ON; `|objects.xy|` in that region is **0.00**, so object vectors play no part there at all.

Per frame pair, tiles in the region whose reprojection with the port's vector is *worse* than no motion:

| pair | tiles | worse | mean \|mv\| where worse | mean depth where worse |
| --- | --- | --- | --- | --- |
| f000->001 | 64 | 0 (0.0 %) | - | - |
| **f001->002** | 64 | **64 (100.0 %)** | **1.17 px** | 0.9914 |
| f002->003 | 64 | 0 (0.0 %) | - | - |
| f003->004 | 64 | 0 (0.0 %) | - | - |
| f004->005 | 64 | 13 (20.3 %) | 2.12 px | 0.9903 |
| f005->006 | 64 | 0 (0.0 %) | - | - |
| f006->007 | 64 | 0 (0.0 %) | - | - |

On the bad pair the tile...

### Clarification on the TAA check

So the thread is not misread: that check only exercises the object vectors when object motion is ON. The
session we tried it in had `object_motion=0` already (the menu shows no "Apply and restart" button, i.e. the
value has not changed since startup), so the composited vectors there are camera-only, and the smear the TAA
path shows in that area is the ordinary "animated content with no usable object vectors" case this issue is
about - not the sign flip.

The measurement in my previous comment comes from a different capture, taken with object motion ON: the dump
only contains `objects_*` files when the ObjectMotion image exists, and that image is only created while the
feature is enabled.

Still open: TAA *with* object motion ON. If the object vectors really are sign-inverted in the composite, the
smear in that area should get worse rather than better.

### Measured with the frame dump: the composited motion vectors invert the object motion (the `objects` image itself is correct)

I used `BB_DUMP_TRIGGER` / `BB_DUMP_DIR` (8 frames, `BB_DUMP_FRAMES=8`) while moving the camera in the
Yharnam sewer, then compared per 64x64 tile:

- the port's motion vectors - warp frame N by `-motion`, residual against frame N+1,
- the best rigid integer shift for that tile, via phase correlation (both sign conventions, keeping the better),
- the `objects` image (the ObjectMotion attachment).

Restricting to tiles whose motion is rigid and well defined (phase-correlation peak >= 10 and the best shift
explaining >= 40% of the tile difference) leaves 434 tiles:

| group | composite `-motion` in the same direction as the true shift | `objects.xy` in the same direction |
| --- | --- | --- |
| low object motion (325 tiles) | **93.5 %** | 57.2 % (objects non-zero in 7 % of those tiles) |
| high object motion (109 tiles) | **1.8 %** | **100 %** |

In the high-o...

Trying the last two options, it seems that my problem is indeed the missing instructions as @atamax pointed out.
Since I'm on Debian building it from source would be a lot of work because some missing dependencies aren't available at the repos. My desktop is my work PC and I would rather keep Debian here for the support of the apps that I need to use, so I'll leave the issue open for now just in case someone else has this problem they can confirm that this solution works.
But hey, great work figuring it out and providing the modified file for us. Thanks!

i found with that exit code that if i tried to run anything over 30fps that the crash happened. after digging into it i realised its because i had the game and update in separate folders. after merging them it runs at 60fps mostly fine and i havent had that exit code since

Specs:
- 12700h
- RTX3060 Mobile
- 32gb DDR4-3200
- Game and BBPort on a gen 3 nvme ssd (not cachyos ssd)
- Save copied from ShadPS4 because I couldnt use the keyboard to input a name in game

For the most part im getting 50-60 fps. it starts and runs much quicker than shadps4. the mods i had in shadps4 have carried over with the save game as well (mainly stake of marika). Though im not sure if they were in the game files or stored in a separate mods folder (there is a separate mods folder in shadps4)

Here it is perfect, I solved the crash problem in the game by putting the game and bbport in the same nvme that I installed cachyos, it was simply perfect, I played more than 50 minutes without crash, thank you for the creator of this top port, I hope to see more titles of the main ones soon like god of war 3 remastered. a hug from Brasil