mirror of
https://github.com/imjasonh/nescript
synced 2026-07-08 17:06:04 +00:00
`const_fold_block`'s per-block dead-code pass was collecting temp usage from only the block it was folding, so a `LoadImm` whose destination is consumed by a *sibling* block (for example via the merge block's branch terminator) was incorrectly treated as dead and dropped. The `and` / `or` short-circuit lowering emits exactly that shape: the false path writes `LoadImm(result, 0)` and joins with the right path at an `and_end` / `or_end` block whose branch terminator reads `result`. After the DCE the false path's store was gone, leaving the zero-page result slot to carry whatever value the *previous* `and` / `or` evaluation had written there — stale data that bled into subsequent conditional branches. I found this while instrumenting `examples/platformer.ne` through a puppeteer-driven jsnes harness, stepping one frame at a time and snapshotting the full zero-page trace of each scenario (title-skip, hold-right, hold-left, jump-spam, coin-drift, enemy-stomp, long-run). In a clean idle run the enemy-1 stomp bounce (`rise_count = 6`, `fall_vy = 0`) fired at emulator frames 83 and 96 with `camera_x` = 61 and 74, i.e. with `e1_sx` = 39 and 26, nowhere near the intended `[72, 96)` pickup window. The trigger turned out to be the slot alias: every time `c2_sx` landed in its pickup window (so the coin-2 `and` stored 1 into ZP(130)) and the player was mid-fall at or past `player_y = 152`, the enemy-1 stomp `and` short-circuited to its false path, left ZP(130) at 1, and the stomp `if` fired on stale data. The fix is to compute function-wide source-operand usage once before folding each function's blocks and OR it into the per-block liveness check, so a LoadImm is only dropped if nobody — neither its own block nor any other block in the function — reads the temp. Added a regression test (`const_fold_preserves_loadimm_used_by_sibling_branch`) that builds the exact CFG shape the `and` lowering emits and verifies the false-path `LoadImm(result, 0)` survives optimization. Impact on the example ROMs: - `examples/platformer.nes`: enemy-1 stomp now fires only when `e1_sx ∈ [72, 96)`, as the source intends. The pixel golden is unchanged (`player_y` converges back to the ground line before frame 180), but the audio hash flips because the spurious `play hit` sfx calls during coin-2 passage are gone. Committing the new `tests/emulator/goldens/platformer.audio.hash`. - `examples/logic_ops.nes`, `examples/bitwise_ops.nes`, `examples/match_demo.nes`, `examples/mmc3_per_state_split.nes`, `examples/two_player.nes`: byte-different but observably unchanged — their pixel + audio goldens still match to the byte. They exercise `and` / `or` in the source and now compile through the corrected DCE. All other example ROMs are byte-identical to pre-fix. `cargo fmt`, `cargo clippy --all-targets`, `cargo test --release` (498 tests), and `tests/emulator/run_examples.mjs` (22/22 goldens) are clean. https://claude.ai/code/session_013Bi4H4YQ5or5HtMB4doUFi |
||
|---|---|---|
| .. | ||
| arrays_and_functions.ne | ||
| arrays_and_functions.nes | ||
| audio_demo.ne | ||
| audio_demo.nes | ||
| bitwise_ops.ne | ||
| bitwise_ops.nes | ||
| bouncing_ball.ne | ||
| bouncing_ball.nes | ||
| coin_cavern.ne | ||
| coin_cavern.nes | ||
| comparisons.ne | ||
| comparisons.nes | ||
| function_chain.ne | ||
| function_chain.nes | ||
| hello_sprite.ne | ||
| hello_sprite.nes | ||
| inline_asm_demo.ne | ||
| inline_asm_demo.nes | ||
| logic_ops.ne | ||
| logic_ops.nes | ||
| loop_break_continue.ne | ||
| loop_break_continue.nes | ||
| match_demo.ne | ||
| match_demo.nes | ||
| mmc1_banked.ne | ||
| mmc1_banked.nes | ||
| mmc3_per_state_split.ne | ||
| mmc3_per_state_split.nes | ||
| palette_and_background.ne | ||
| palette_and_background.nes | ||
| platformer.ne | ||
| platformer.nes | ||
| README.md | ||
| scanline_split.ne | ||
| scanline_split.nes | ||
| sprites_and_palettes.ne | ||
| sprites_and_palettes.nes | ||
| state_machine.ne | ||
| state_machine.nes | ||
| structs_enums_for.ne | ||
| structs_enums_for.nes | ||
| two_player.ne | ||
| two_player.nes | ||
| uxrom_banked.ne | ||
| uxrom_banked.nes | ||
NEScript Examples
Quick Start
# Build the compiler
cargo build --release
# Compile all examples
for f in examples/*.ne; do cargo run -- build "$f"; done
# Or compile one
cargo run -- build examples/hello_sprite.ne
Open any .nes file in an NES emulator (Mesen, FCEUX, etc.)
Examples
| File | Features | Description |
|---|---|---|
hello_sprite.ne |
input, draw | Move a sprite with the d-pad |
bouncing_ball.ne |
if/else, variables | Auto-bouncing sprite with edge detection |
coin_cavern.ne |
states, functions, constants | 3-state game with gravity and coin collection |
arrays_and_functions.ne |
arrays, functions, while | Enemy array with collision detection |
state_machine.ne |
on enter/exit, transitions | Multi-state flow with timers |
sprites_and_palettes.ne |
sprites, scroll, cast | Inline CHR data, PPU scroll writes, type casting |
mmc1_banked.ne |
MMC1, banks, multiply | Banked mapper with software multiply |
palette_and_background.ne |
palette, background, set_palette, load_background | Reset-time initial load plus vblank-safe runtime swaps |
platformer.ne |
every subsystem | End-to-end side-scrolling demo: custom CHR tileset, full 32×30 nametable with per-region attribute palettes, 2×2 metasprite hero with gravity/jump physics, wrap-around horizontal scrolling, enemies, coin pickups, user-declared SFX + music, and a Title → Playing state machine with an autopilot so the headless harness still hits interesting gameplay at frame 180. Regenerate the tile art with cargo run --bin gen_platformer_tiles. |
Emulator Controls
| NES Button | Typical Key |
|---|---|
| D-pad | Arrow keys |
| A | Z |
| B | X |
| Start | Enter |
| Select | Right Shift |
About Sprites
Sprite names in draw Player at: (x, y) are parsed and recorded in the AST.
You can define sprites with inline CHR tile data:
sprite Player {
chr: [0x3C, 0x42, 0x81, 0x81, 0x81, 0x81, 0x42, 0x3C,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00]
}
If no matching sprite declaration exists, the draw uses the built-in default
tile (a smiley face). See sprites_and_palettes.ne for a full example.
Compiler Commands
# Compile to ROM
cargo run -- build game.ne
# Custom output path
cargo run -- build game.ne --output my_game.nes
# Type-check only
cargo run -- check game.ne
# View generated 6502 assembly
cargo run -- build game.ne --asm-dump
# Debug mode
cargo run -- build game.ne --debug