Repository navigation
Pokopia: in-game camera photos are corrupted or differ from preview #14
Description
Affected build
Frameropia v0.0.1 (Windows), as reported by a tester.
Expected
The saved in-game photograph visually matches the camera preview.
Actual
The photo may contain severe graphical artifacts and may not correspond to the preview. The tester has reproduced corruption after taking several photos (including on the third capture). This is not confirmed to be caused by Discord screen sharing; screen sharing was active in an earlier observation.
Reproduction
- Boot Pokémon Pokopia on v0.0.1.
- Enter the in-game photo mode and take multiple photos.
- Compare the preview with the final photos.
Investigation
Check render-target copy/readback synchronization, texture cache invalidation, deferred GPU copies, and shader/pipeline availability. These are hypotheses, not confirmed root causes. Retest without overlays and compare first vs repeated captures.
Tracked in testing checklist. No fix is verified yet.
Cross-fork comparison (2026-11-07, user report)
A tester tried the Windows x86_64 artifact 13464533386 from Orchid workflow run 42132872737, which includes the merged Orchid PR #66 buffer readback range-intersection correction alongside other code changes.
- Saved in-game photos still sometimes corrupt, but clean photos appeared more frequently than in the previously tested build (qualitative observation; no counted sample or controlled A/B yet).
- Severe new regression: 3D assets/geometry intermittently flicker, disappearing and reappearing.
- Do not attribute either effect specifically to PR MKW 1.8.0 has broken graphics on Vulkan (Intel Arc G3E) Djihads80/Eglantine#66 without isolating that patch, because the downloaded Orchid build includes other changes and differs from Frameropia in more than one way.
- Do not merge the whole Orchid build. Isolate only the buffer readback correction on a separate test branch, run regression tests, then compare repeated photo captures and geometry rendering under identical settings and scenes. Keep existing Frameropia release as baseline.
The measured number of clean vs corrupt photos and exact GPU/driver/settings were not provided. No confirmed photo fix exists.
Activity
Framerr commentedon Nov 7, 2026
Isolated readback patch result (2026-11-08)
User tested Frameropia experimental PR #16, which changes only the buffer-cache
DownloadMemoryreadback range intersection adopted from Orchid PR Djihads80#66. All saved Pokémon Pokopia photos were corrupted in this test, versus intermittent corruption in the prior working baseline. This is a confirmed regression in the tested configuration, not a photo fix. Do not merge PR #16; leave thenx2/mainbaseline and releases untouched. Earlier observations from the multi-change Orchid build must not be treated as evidence that this isolated patch helps photos. No root cause established.Framerr commentedon Nov 7, 2026
External build 24 confirmed by reporter (2026-11-08)
Reporter tested notsapinho/Eglantine build 24: no photo corruption observed and reported stable 60 FPS during their play session. This is whole-build validation, not proof that one individual commit fixes all cases.
Isolated Frameropia draft PR #17 ports only notsapinho's MaxwellDMA readback flush, without PR #16's rejected generic buffer readback change. Branch
experiment/pokopia-dma-photo-flush, commit92ef6650; unbuilt and unmerged. Do not publish or merge until separately tested.Framerr commentedon Nov 8, 2026
Frameropia Windows test A accepted and merged (2026-11-08)
Reporter tested PR #17 Windows artifact: 50 Pokopia photos captured, 48 correct / 2 corrupted (96% correct). Reporter approved the substantial improvement. The DMA readback patch from notsapinho/Eglantine 7dde4f15 was squash-merged into
nx2as 777181dd. Issue remains open: two failures remain; the reporter suspects a shader compilation correlation, which is currently unverified. No new version/release was created. The rejected generic readback PR #16 remains unmerged.Framerr commentedon Nov 8, 2026
Additional targeted reporter test (2026-11-08)
On Frameropia Test A (the DMA readback flush patch merged via #17), reporter took 9 photographs during a shader-compilation scenario. Only the first photo was corrupt; the next 8 were correct (8/9 good).
This suggests a possible first-capture / initialization / synchronization pattern, but a sample of one session is insufficient to establish cause; shader compilation is not proven causal. Recommended next controlled comparison: restart the emulator for 5–10 independent sessions, take 3 photos each (record exactly which photo corrupts) in the same area, then compare with a warm session. Keep #14 open and avoid speculative global buffer fixes or publishing a new release until the first-photo pattern is reproduced.
Framerr commentedon Nov 8, 2026
Additional reporter test: stable area (2026-11-08)
With Frameropia Test A / merged DMA image-to-buffer readback flush (#17), reporter took 8 photos in a stable, already-loaded area: 8 correct, 0 corrupt, with no other observations.
Recorded test results to date:
This is consistent with a loading/first-capture timing hypothesis, but does not prove that shader compilation or initialization causes the remaining corruption. The samples are small and not controlled across multiple fresh-start sessions. Keep issue open, retain the approved flush fix, and prioritize a repeated cold-start test (three photos per session across five independent emulator restarts) before proposing another readback patch. No new release/build or code edits are requested.
Framerr commentedon Nov 8, 2026
Rapid successive photos: vertically wrapped image (reporter test, 2026-11-08)
On Frameropia Test A / merged DMA readback flush (#17), reporter captured 18 photos rapidly; 17 correct, 1 anomalous (photo #3). Crucial new symptom: the third photograph's pixels looked otherwise correct but the entire image was vertically shifted downward, with content pushed off the bottom reappearing at the top (vertical wraparound / circular row displacement). Unlike earlier reports of bands/garbage, this may point to incorrect image starting offset, row pitch/stride, image-to-buffer transfer origin, or reuse/synchronization of accelerated DMA destination buffers. These are hypotheses, not verified root causes.
Cumulative reporter counts after the accepted fix:
Total: 81/85 correct (95.3%); 4 anomalous.
Suggested targeted investigation: instrument the 1920x1080 photo DMA path to record source/destination addresses, pitch, dimensions, copy index, GPU completion/sync ordering; compare first/third successive shots and try to reproduce with a repeatable rapid capture sequence. Retain existing DMA flush; do not reintroduce rejected PR #16 or merge risky deferred-upload PR #19. No new fix or build is verified by this evidence.
Framerr commentedon Nov 8, 2026
Reporter test: photos after emulator restart (2026-11-08)
With the merged DMA flush fix (#17), reporter captured 10 photographs after restart, with 9 correct and 1 corrupt; only the first photo was corrupted. The number of independent restarts covered by these 10 photographs is unspecified; do not claim repeated cold-start reproduction across multiple sessions.
Combined reported tests with the fix:
Aggregate: 90/95 correct (94.7%), 5 anomalous.
Repeated observations that the first photo is affected make first-use initialization, copy/readback ordering or buffer state worth investigating, but there is not yet a controlled multiple-restart pattern or proven shader causality. Investigate the first accelerated DMA image-to-buffer copy and image destination buffer pitch/offset, while keeping the effective DMA flush patch; avoid old PR #16 and rejected #18/#19. No new release or speculative patch has been made.
Framerr commentedon Nov 8, 2026
Controlled cold-start photo test: first-capture pattern (2026-11-08)
Reporter restarted Frameropia for three independent sessions and took 3 Pokopia photos per session on the build containing accepted DMA flush fix (#17):
4/9 corrupt overall. First photo corrupt in 3/3 starts; second 1/3; third 0/3. This strengthens the hypothesis of a first-use or warm-up synchronization/resource-state issue, but three restarts are not sufficient to identify a root cause or prove causality. Investigate the initial accelerated MaxwellDMA image-to-buffer transfers, BufferCache initialization/readback ordering and photo destination reuse/pitch. Preserve the DMA flushing fix; do not reintroduce rejected PR #16 or speculative global synchronization changes.
Prior accumulated trials: 90/95 photos correct. Adding this separate 3-start trial gives 95/104 correct, 9 corrupt overall. Note the per-session cold-start results are more informative than this pooled percentage. No code or release changes made.
Framerr commentedon Nov 8, 2026
New isolated first-capture diagnostic (2026-11-08)
Created draft PR #20, based on
nx2with accepted DMA flush still intact. A narrow A/B test bypasses acceleratedImageToBufferfor just the first two 1920×1080 RGBA8-shaped DMA transfers per emulator process and routes them through the existing CPU fallback. Logs the first twelve matching transfers to verify the image path actually matches. ToggleFRAMEROPIA_FIRST_PHOTO_DMA_CPU=0restores the normal accelerated path. Hypothesis only; not a verified fix.Artifact-only Windows test run queued. The PR remains unmerged, no new release. Suggested test: 5 separate emulator starts, take three photos each; confirm first-photo error rate and check the
Pokopia photo-shaped DMA copylogs. If no matching log appears, do not treat a failure as disproving the hypothesis; revise the geometry trigger based on actual observed copy dimensions.Framerr commentedon Nov 8, 2026
First-photo fallback experiment fails (2026-11-08)
Reporter tested experimental PR #20, which attempts a CPU fallback for the first two 1920×1080 photo-shaped accelerated DMA transfers. All saved photos were corrupt, a severe regression versus the accepted DMA readback flush in
nx2(#17). This experiment is rejected; must not merge. This result does not prove that CPU readback is intrinsically wrong; the test's assumptions, geometry match and sequencing have not been established from logs. Next investigation should prioritize instrumenting the actual first-capture transfer and checking GPU/CPU coherence, pitch and offsets without speculative global path replacements. Keep #14 open.Framerr commentedon Nov 8, 2026
Fork scan — 2026-11-08: promising photo-coherency candidates
Reviewed notsapinho/Eglantine main/dev (latest released build 24, 780a1d0), upstream Djihads80/Eglantine, MythosOfs/Orchid, sylvieistaken/selevet-eglantine, and zortos293/Lichii. Findings are source review, not new user-verified Frameropia fixes:
nx2already containsEGLANTINE_SYNC_FIXandNoteComputeWritesinvk_rasterizer.cpp; avoid redundant porting.Recommendation: preserve approved #17/Frameropia v0.0.3 baseline. First review and possibly instrument Orchid's pending CPU-write/GPU-download overlap behavior, then create a separate, disabled-by-default diagnostic branch only if equivalent code exists in Frameropia. Compare first three photos across at least five fresh starts, plus graphical stability; do not merge on compile-only success. No new fix or release was created in this scan.
Framerr commentedon Nov 8, 2026
v0.0.3-based preliminary photo diagnostics (2026-11-08)
Created draft PR #25 as isolated Test G Windows artifact build. This is diagnostic only and preserves the validated v0.0.3 DMA flush/photo behavior. When
FRAMEROPIA_PHOTO_DMA_TRACE=1is set before launching Frameropia, it logs source and destination GPU addresses, source origin, row count, row length, pitches, block height and acceleration result for the first 96 large block-linear→pitch DMA transfers. The trigger deliberately does not assume 7680×1080 (an unverified assumption behind rejected #20). Compare the first failed photo with later good photos and attach log. Do not merge unless telemetry is useful; no release changes. Test E (#23) and F (#24) are performance-only and should also be checked for photo regressions.