Skip to content

fix(ios): pin voxel render target scale & fix shadows - #48

Merged
DramaticShape merged 3 commits into
DramaticShape:devfrom
castdrian:ios
Aug 3, 2026
Merged

fix(ios): pin voxel render target scale & fix shadows#48
DramaticShape merged 3 commits into
DramaticShape:devfrom
castdrian:ios

Conversation

@castdrian

@castdrian castdrian commented Aug 1, 2026

Copy link
Copy Markdown
Contributor

depends on bryanthaboi/gen1recomp#582
but changing ios to use metal as gpu backend fucked a lot with the shader stuff and changed the way canvases behave

@bryanthaboi

Copy link
Copy Markdown

King of spain!!

@luisgonzaleznf

luisgonzaleznf commented Aug 2, 2026

Copy link
Copy Markdown

Confirming this fixes iOS shadow rendering on hardware.

Device: iPhone 15 Pro Max, iOS 27.0
Engine: gen1recomp v0.1.56 (official iOS .ipa, sideloaded via AltStore)
Mod: DRAMATIC_SHAPE 1.5.1 (release zip)

Before (stock 1.5.1): shadow rendering badly broken — large hard-edged dark regions with straight diagonal boundaries covering a big fraction of the frame, both outdoors and inside buildings, and independent of the day/night pin. Indoors it presented as a lit parallelogram sitting inside near-total darkness.

After (this PR applied to 1.5.1): gone. Overworld and interiors render correctly.

Method: applied this PR's diff to the 1.5.1 release zip (patch -p1 applies cleanly against the release tree), repacked, imported through MODS → Import mod .zip. Not a full source build, so treat it as a functional confirmation rather than a build-system one.

One note that may help others landing here: engine PR bryanthaboi/gen1recomp#582 merged 2026-08-01 14:41 UTC, and the v0.1.56 IPA was published 2026-08-02 01:23 UTC. So current released iOS builds carry the Metal backend change without this mod-side adaptation — that skew window is what makes stock 1.5.1 break on iOS today.

Understood that this gates the sun pass off on iOS rather than making it work under Metal, so iOS loses cast shadows for now. Given the current state is unusable, that reads as a clear net improvement — but happy to test a follow-up that tries to restore them if one appears.

@castdrian castdrian mentioned this pull request Aug 2, 2026
@luisgonzaleznf

Copy link
Copy Markdown

Follow-up from testing this on device — flagging a regression I think this PR introduces, since it is easy to miss.

beginScene now allocates the scene colour canvas through PixelCanvas.new (pinned dpiscale = 1), but newDepth still calls love.graphics.newCanvas(w, h, { format = format, readable = true }) with no dpiscale. On iOS at dpiscale 3 the depth canvas is therefore allocated 3x per side while its colour canvas is 1x, so the pair no longer matches pixel-for-pixel.

The consequence is silent: the setCanvas{ colour, depthstencil = depth } bind fails, and the existing fallback releases held.depth and demotes to the internal buffer for the rest of the session. Since beginWater requires held.depth, that takes water reflections with it — the 3D scene keeps rendering (via the conjured depth = true buffer), so nothing looks obviously broken, but reflections are gone on iOS.

The comment directly above the allocation is also now inaccurate:

-- the depth canvas is sized with its colour, so a window resize
-- reallocates the pair together and they can never disagree
slotHeld = { canvas = c, w = w, h = h, depth = newDepth(w, h) }

They can now disagree — not on dimensions, but on dpiscale.

Pinning newDepth to dpiscale = 1 as well should restore both the invariant and the reflections. Happy to test on device (iPhone 15 Pro Max / iOS 27.0) if useful.

@luisgonzaleznf

Copy link
Copy Markdown

Still not the right approach @castdrian @bryanthaboi! Fixing in #75

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants