Files
Sylpheed/crates/sylpheed-formats/examples/main_menu_element_extents.rs
MechaCat02 e6266b1966
All checks were successful
CI / Native — linux (pull_request) Successful in 41m56s
CI / WASM — Web (pull_request) Successful in 31m56s
CI / Formatting (pull_request) Successful in 1m15s
fix(lint): clear the clippy gate across examples and tests
80 findings, not the 14 the first run showed -- clippy stops at the first
failing compilation unit, so `--keep-going` is what makes the list complete.

60 were machine-applicable (`cargo clippy --fix`). The rest by hand:

* five descending `sort_by` -> `sort_by_key(Reverse(..))`
* `chunks_exact(4)` on both sides of four zips, so the compared items stay
  `[u8; 4]` rather than one array against one slice
* three `type` aliases for the census maps and the captured-quad tuple
* `&PathBuf` -> `&Path` in two disc tests
* two range loops; one of them keeps `#[allow(needless_range_loop)]` with the
  reason -- the index is into a map's value, which changes each iteration
* the module doc list in `invert_capture` re-indented to markdown's rules
* `blit`'s eight arguments get `#[allow(too_many_arguments)]`, not a struct

One dead `let off = b.len();` in a `ratc` test is dropped rather than renamed.
The sibling test at :162 is the one that asserts an offset; if this one was
meant to as well, that is a test change and not a lint fix.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-12 16:42:41 +02:00

64 lines
2.4 KiB
Rust
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
//! What elements sit under the port's hot residual tiles on the main menu?
//!
//! `sylpheed-port` mapped the menu's edge residual at 64 px tiles and handed over
//! coordinates without names — the element inventory is this side's. Hot tiles
//! cluster at x 384704, y 64256, hottest at (512,128).
//!
//! ⚠️ Their tiles are in the frame they compare in; this prints DESIGN space, and
//! the two differ by the capture offset (capture_y ≈ 64.8 + 0.992·design_y). Both
//! readings are printed so the mapping is not assumed.
//!
//! cargo run -p sylpheed-formats --example main_menu_element_extents
use std::path::PathBuf;
use sylpheed_formats::{pak::PakArchive, ui_layout};
fn main() {
let root = PathBuf::from(std::env::var("SYLPHEED_DISC").expect("SYLPHEED_DISC"));
let ar = PakArchive::open(root.join("dat/GP_TITLE.pak")).expect("GP_TITLE");
let by = ar.read(&ar.entries()[5]).expect("entry 5");
let b = ui_layout::parse_build(&by).expect("build");
println!(
"{:<26} {:>6} {:>6} {:>7} {:>7} sprite",
"element", "x", "y", "pivot_x", "pivot_y"
);
let mut rows: Vec<(i32, i32, String, String)> = b
.elements
.iter()
.map(|e| {
let k = e.rest();
(
k.map(|k| k.x).unwrap_or(0),
k.map(|k| k.y).unwrap_or(0),
e.name.clone(),
e.sprite.clone().unwrap_or_default(),
)
})
.collect();
rows.sort_by_key(|r| (r.1, r.0));
for (x, y, n, s) in &rows {
// flag anything whose rest position lands in the hot band, read both ways
let cap_y = 64.82 + 0.9919 * (*y as f64);
let hot_design = (384..=704).contains(x) && (64..=256).contains(y);
let hot_capture = (384..=704).contains(x) && (64.0..=256.0).contains(&cap_y);
let mark = match (hot_design, hot_capture) {
(true, true) => " <- HOT both readings",
(true, false) => " <- hot in DESIGN space",
(false, true) => " <- hot in CAPTURE space",
_ => "",
};
println!(
"{n:<26} {x:>6} {y:>6} {:>7} {:>7} {s}{mark}",
b.elements
.iter()
.find(|e| &e.name == n)
.map(|e| e.pivot_x)
.unwrap_or(0),
b.elements
.iter()
.find(|e| &e.name == n)
.map(|e| e.pivot_y)
.unwrap_or(0)
);
}
}