DMA census: classify conveyor and moving-platform frames

Open
  • Is something wrong?
#600 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
15/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
godot, rust
Domain
game-dev, reverse-engineering

Research direction

Start from the DMA census tests in psiv-core's US-image suite, which depend on dma_census.rs from #595; that file is not yet published, so wait for it. Then trace the DMAPlanes_VInt, DMAPlane_A_VInt and DMAPlane_B_VInt calls in the ConveyorRide and RidePlatform implementations for the ten assigned scenes, and run scene_runner::mechanics_tests and the session_vahal platform tests. Done means each assigned census row names its consuming mechanic and loop phase, per-tick movement and frame ownership are asserted for all four belt directions and both platform directions, and a regression control catches an omitted or duplicated DMA frame. The task requires the original US ROM, and it is scoped to a single PR under the parent issue's rules.

Written by the indexing model from the issue text.

Description

claude ready

Child of https://github.com/TusanHomichi/PSIV/issues/599. Finish only this task in one fresh session and one PR. The parent's original authorization boundaries still apply; this child grants no additional authority. Do not read earlier sessions' transcripts.

Child of TusanHomichi/PSIV#599; deliver one PR. Await publication of #595's dma_census.rs and preserve its one-frame DmaPlanes behavior. Own exactly ten scenes: Event_ConveyorBeltDown/Up/Right/Left, Event_VahFortMovingPlatform1/2, and Event_WpnPlntMovingPlatform1/2/3/4. Trace every uncovered DMAPlanes_VInt, DMAPlane_A_VInt or DMAPlane_B_VInt call against verified US bytes and the ConveyorRide/RidePlatform implementations. Record the named mechanic and loop phase that spends each frame, including repeated executions. Add genuinely missing synchronization frames through the owning mechanic without adding a second frame to existing movement ticks. Leave layout-refresh CPU and boundary modeling to #546. Preserve unrelated census rows, movement, collision and update policies. Original #599 authority and protected-input rules apply; no earlier session transcripts, unrelated repairs, release, deployment or asset distribution.

Verification: Run psiv-core's US-image dma_census tests, scene_runner::mechanics_tests, and the relevant session_vahal/runtime platform tests through documented locks. Assert per-tick movement and frame ownership for both platform directions and all four belt directions. Include a regression control detecting an omitted or duplicated DMA frame. Every assigned row names its consuming mechanic or disappears after a verified fix.

If this is too big, publish any progress, split it with proj split FILE (a JSON array of title/body/check tasks), then end the session. Wait for the PR to land before declaring this task done.

Dominant language
Rust
Stars
1
Forks
0
Avg merge
8h 43m
Merged PRs (30d)
288

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from TusanHomichi/PSIV

All issues in TusanHomichi/PSIV

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.