v0.0.161

rePIU v0.0.161

이전 릴리스 v0.0.160 이후의 변경입니다. 이번 릴리스는 실행 방법을 바꿉니다. 인자 없이
실행하면 런처가 열려 롬셋을 고르고, 게임이 끝나면 다시 목록으로 돌아옵니다.

런처

• repiu.exe를 인자 없이 실행하면 롬셋 목록이 열립니다. 고른 롬셋을 실행하고, 게임이 끝나면
  런처로 복귀하므로 다른 타이틀을 이어서 고를 수 있습니다. 종료는 Quit입니다.
• 내장 카탈로그의 롬셋이 전부 나옵니다. 실행할 수 없는 것도 감추지 않고 흐리게 표시하며
  사유를 그대로 씁니다 — roms\<id>.zip 없음, ZIP에 필수 PIU10 엔트리 없음, roms\<id>\
  없음, CHD 없음, CHD가 둘 이상. 어떤 디스크가 왜 안 되는지 목록에서 바로 보입니다.
• 판정은 마운트와 같은 규칙을 쓰되 추출은 하지 않습니다. 22개 디스크를 전부 무결성
  검사하면 기다릴 수 없고, 실제 판단은 실행 시점의 마운트가 이미 합니다.
• 방향키로 이동, Enter로 실행, Esc로 종료합니다. 실행 불가 항목은 방향키가 건너뜁니다.
  창이 뜨면 마지막에 실행한 롬셋에 커서가 놓입니다.
• vsync와 사운드 게인을 런처에서 바꿔 cfg\repiu.ini에 저장합니다. 같은 의미의 환경
  변수가 설정돼 있으면 환경 변수가 이깁니다 — 측정 스크립트와 진단 절차의 우선권이
  유지됩니다.

기존 실행 방법은 그대로입니다

• repiu.exe <롬셋>과 repiu.exe <PIU.EXE 경로>는 한 줄도 바뀌지 않았고, 게임이 끝나면
  프로세스도 완전히 종료됩니다. 복귀 루프는 인자 없는 단독 실행에만 있습니다.
• 인자 없이 실행하는 자동화를 위해 REPIU_LAUNCHER=0을 주면 런처를 건너뛰고 기존
  기본값(pumpit1)으로 갑니다.
• 창이나 GL 컨텍스트를 만들 수 없는 환경에서는 런처를 포기하고 기존 기본값으로 계속
  진행합니다.

왜 네이티브 GUI가 아닌가

Dear ImGui(MIT)로 호스트가 이미 만드는 SDL3 창에 직접 그립니다. 리눅스에서 쓸 만한
크로스플랫폼 네이티브 툴킷은 Qt(LGPLv3/상용), GTK(LGPL), wxWidgets·FLTK(LGPL 파생)로 전부
프로젝트의 카피레프트 금지 정책과 충돌하고, 피하려면 Win32와 X11/Wayland를 각각 구현해야
합니다. 여기에 캐비닛에는 키보드·마우스가 없어 결국 게임 창 안에서 조작할 수 있어야
한다는 점과, 같은 레이어가 나중에 인게임 OSD가 된다는 점이 같은 방향을 가리켰습니다.

구조는 플랫폼 공용을 먼저 둡니다. 롬셋 가용성 판정과 설정 저장은 std::filesystem과 기존
INI 파서만 쓰므로 probe로 검증되고, 화면은 SDL3와 OpenGL만 씁니다.

검증

• Win32 x86 Debug/Release repiu, repiu_aot_probe 빌드 성공.
• repiu_aot_probe --launcher: 5항목 통과 — 가용성 6개 상태, 카탈로그 커버리지, 설정 왕복과
  잘못된 값 처리, 환경 변수 우선순위 전 조합, 자식 명령줄 인용(공백 포함 경로).
• 회귀: repiu.exe pumpit8이 런처를 거치지 않고 exit 0으로 완전 종료하며 런처 관련 로그가
  0건입니다.
• 사용자가 목록 표시, 선택 실행, 게임 종료 후 런처 복귀, 키보드 조작을 확인했습니다.

알려진 제한

• 창 크기와 전체화면은 아직 없습니다. 현재 창 생성이 게스트의 논리 해상도를 따르고 이를
  덮어쓸 소비자가 없어, Glide backend의 창 생성 경로를 함께 손대야 합니다.
• 캐비닛 발판으로 런처를 조작하는 것은 아직 안 됩니다. 발판 입력은 게스트 실행 중 PIUIO
  포트로 들어오는 것이라 경로가 다릅니다. 지금은 키보드·마우스·게임패드로 조작합니다.
• 실행 backend나 direct-return table 같은 진단 토글은 런처에 노출하지 않았습니다. 환경
  변수로만 다룹니다.

---

rePIU v0.0.161

Changes since v0.0.160. This release changes how rePIU is started: with no arguments it opens a
launcher, and a finished game returns to the list.

The launcher

Running repiu.exe with no arguments lists every ROM set in the built-in catalog and starts the one
selected; when that game ends the launcher comes back, so another title can be chosen without
restarting rePIU, and Quit ends the session. ROM sets that cannot run are not hidden: they are
dimmed and carry their reason — a missing roms\<id>.zip, a zip without the required PIU10 entries,
a missing roms\<id>\, no CHD, or more than one CHD — so it is obvious why a disc is unavailable.
Availability uses the same rules as the mount but extracts nothing, because verifying twenty-two
discs would outlast anyone's patience and the real judgement already happens at launch.

Arrows move, Enter starts, Escape quits, and unavailable rows are skipped by navigation. The cursor
opens on the ROM set played last. Vertical sync and sound gain are edited there and stored in
cfg\repiu.ini; an environment variable of the same meaning always wins, so measurement scripts and
diagnostic procedures keep their precedence.

Existing invocations are unchanged

repiu.exe <rom set> and repiu.exe <path to PIU.EXE> behave exactly as before and end the
process when the game ends — the return loop exists only for an argument-free standalone run.
REPIU_LAUNCHER=0 skips the launcher for automation that runs the binary bare, and a host that
cannot create a window or GL context falls back to the previous default target rather than failing
to start.

Why not a native GUI

The launcher is drawn with Dear ImGui (MIT) inside the SDL3 window the host already creates. Every
cross-platform native toolkit that would serve Linux — Qt, GTK, wxWidgets, FLTK — is LGPL-family and
conflicts with the project's ban on copyleft dependencies, and avoiding them would mean building the
same screen separately against Win32 and X11/Wayland. Two further reasons agree: cabinets have no
keyboard or mouse, so the UI must eventually be operable inside the game window, and the same layer
becomes the in-game OSD later. Availability and settings depend only on std::filesystem and the
existing INI parser, so they are probe-verified, and the screen touches only SDL3 and OpenGL.

Verification

Debug and Release builds of repiu and repiu_aot_probe succeeded. repiu_aot_probe --launcher
passed five checks: the six availability states, catalog coverage, settings round trip with
malformed values, environment precedence in every combination, and child command-line quoting with a
path containing spaces. For regression, repiu.exe pumpit8 exits cleanly with no launcher
involvement. A user confirmed listing, launching, returning to the launcher, and keyboard operation.

Known limitations

Window size and fullscreen are not available yet, because window creation follows the guest's
logical resolution and no consumer exists for an override. Driving the launcher from the cabinet
panels is not possible yet either: panel input arrives over PIUIO ports while the guest runs, which
is a different path, so keyboard, mouse, and gamepad are the current means. Diagnostic toggles such
as the execution backend or the direct-return table are deliberately not exposed and remain
environment variables.