mr.zeroandClaude Opus 5
e2222b54be
MORE_STORES.md asks which further host platforms could get a store like the Batocera one, and starts from a measurement: the catalog ships html for 11 of 15 titles and desktop binaries for 8, while the Batocera store consumes only cartridge — 7. The gap is not the number of stores but that the existing one leaves half the catalog untouched. Also records that the ARM64 asset kind is the prerequisite for the retro-handheld direction, and closes the internal-org item in REPO_REFACT.md now that all eight builder images live under build/. The Woodpecker note is corrected against what the CLI actually reports: 19 repos registered and active, not the 10 the pipelines table shows. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
7.3 KiB
Milyen további store-okat érdemes csinálni
Készült 2026-08-16-án, a warp-engine-batocera-store szétválasztása után. A kérdés: a batocera-store mintájára milyen más gazdaplatformra tudnánk store-t adni.
A mérés, ami átrendezi a kérdést
A katalógus legfrissebb kiadásaiban (15 szoftver) ennyi asset van:
| Asset | Hány szoftvernél | Ki használja ma |
|---|---|---|
html |
11 | senki — a publikus oldal lejátssza, de nincs könyvtár |
win_x64 |
8 | senki |
linux_x64 |
8 | senki |
cartridge |
7 | a batocera-store |
win_x86 |
4 | senki |
mac_x64 |
3 | senki |
docs / source |
3 / 3 | a publikus oldal |
mac_universal |
2 | senki |
Platformonként:
| Platform | Elérhető assetek |
|---|---|
| c64 | cartridge (4) |
| tic80 | cartridge, html, source, docs, win_x64, linux_x64, mac_x64 (3) |
| ebitengine | html, win_x86, win_x64, linux_x64 (3) |
| godot | html, win_x86, win_x64, linux_x64, mac_universal (1) |
| love | html, win_x64, linux_x64, mac_universal (1) |
| phaser | html (2) |
| bevy | html (1) |
A tanulság: a batocera-store csak a cartridge-et fogyasztja, tehát a katalógus 7/15 részét. A legelterjedtebb asset-fajtánk, a webes build, egyetlen store-ban sem szerepel. Nem az a szűk keresztmetszet, hogy kevés store van — hanem hogy a meglévő a katalógus felét ott hagyja.
0. Előfeltétel mindenhez: ARM Linux buildek
A build-mátrixunkban nincs Linux ARM asset. A ReleaseAsset::KINDS ezt tartalmazza:
cartridge source html docs
win_x86 win_x64 linux_x86 linux_x64
mac_x64 mac_arm64 mac_universal
Van mac_arm64, de linux_arm64 és linux_armhf nincs — a linux_x86 pedig szerepel a listán, csak épp semmi nem gyárt bele.
Ez azért döntő, mert a Batocera nem csak x86_64-en fut: Raspberry Pi-n, Odroidon és a kézikonzolokon ARM-on megy. Egy linux_x64 bináris ezeken feltelepül, de nem indul el — ami rosszabb, mint ha nem is ajánlanánk fel. Ugyanez blokkolja az 1. pont legérdekesebb célpontjait: a muOS, ArkOS és JELOS kézikonzolok szinte mind ARM-osak.
Amiért a mai store hordozható: a cartridge architektúra-független (adat egy emulátornak), ezért mind a 7 cím megy minden Batocera gépen.
Teendő, sorrendben:
linux_arm64(és ha kell,linux_armhf) felvétele aKINDS-be és a platformokci_platformsmátrixába.- Cross-build a pipeline-okban. A legkönnyebb az ebitengine (Go:
GOARCH=arm64), utána a bevy (Rust cross toolchain) és a godot (van ARM export template); a LÖVE a legnehezebb, ott ARM futtatókörnyezet kell. - A motor architektúra-felismerése (
uname -m→x86_64/aarch64/armv7l), és csak az illeszkedő asset telepítése.
0b. Utána: linux_* → Batocera ports
Ha az ARM buildek megvannak, a ROM-rendszerek mellé jöhet egy második telepítési mód: ami nem cartridge, az portként megy fel. A Batocera ports rendszere .sh indítókat vesz, a motor pedig már ma is ír ports bejegyzést.
Számokban, a mai assetekkel:
| Gép | Lefedettség |
|---|---|
| x86_64 Batocera | 12/15 — a 7 cartridge + ebitengine 3, godot 1, love 1 (a 3 tic80 átfedés) |
| ARM Batocera | 7/15 — csak a cartridge, amíg nincs ARM build |
A kimaradó három cím (1 bevy, 2 phaser) csak html-t ad, azokhoz böngésző kell.
Ugyanez a keret adja az interaktív ES-menüt is (ports bejegyzések gamelist-metaadattal).
Új store-ok, sorrendben
1. ES-családú store-ok
RetroPie, Recalbox, ES-DE, és a kézikonzolos disztrók (muOS, ArkOS, JELOS). Ugyanaz a gamelist.xml + ROM-mappa modell, amire a motor már generikus: gyakorlatilag paths.roms_root, rendszernév-leképezés és egy másik telepítő kell. A legtöbb elérés a legkevesebb munkáért. Az ES-DE Windowson és macOS-en is fut, tehát asztali elérést is ad mellékesen.
Fontos megkötés: a kézikonzolok jóformán mind ARM-osak, és a RetroPie is Pi-n fut. Cartridge-dzsel ezek azonnal kiszolgálhatók, natív játékkal viszont csak a 0. pont ARM buildjei után.
2. Asztali store — warp-engine-desktop-store
A per-OS zipeket telepíti egy helyi könyvtárba, és indítót csinál hozzá (.desktop, Start menü bejegyzés, .app). Ma 8 szoftvert szolgálna ki, és a CI-lefedettséggel nő. Ez a legnagyobb valóban új képesség: asztali gépre ma semmilyen utunk nincs.
3. Steam-könyvtár
A shortcuts.vdf-be írva a játékaink megjelennek a Steam könyvtárban borítóval — és ezzel a Steam Decken is. A letöltést a 2. pontról örökli, tehát ráépül, nem mellé megy. Bevált technika, a Heroic és a Lutris is ezt teszi.
4. RetroArch playlistek
.lpl JSON playlist platformonként. A cartridge-eket sokkal nagyobb közönségnek adja, mint a Batocera: Android, asztali gépek, konzolok. Kis formátum, kevés munka.
5. BBS store
A bbs/bbs-server-be, a saját rubbs-unkra épülve. Bármelyik asset-fajtát tudja adni letöltésként, és ez az egyetlen a listán, amit rajtunk kívül senki nem tudna lemásolni — márkaérték, nem csak elérés.
6. Csomagkezelők
Homebrew tap és Scoop bucket: brew install ttg/tap/rabbitroller. Kevés munka, és nem kell hozzá launchert írni; a 2. pont csomagolására épül.
7. Webes könyvtár / PWA
A html assetek megvannak, de ez van a legnagyobb átfedésben a mostani publikus oldallal, ezért a legkisebb határhasznú — annak ellenére, hogy ez a legelterjedtebb assetünk.
Amit nem javaslok
- itch.io — az az ő katalógusuk, nem a miénk; nem store-t adnánk, hanem feltöltenénk.
- Flatpak / Snap — nehéz átvezetés és felülvizsgálat kevés extra elérésért.
- Önálló Android APK — nagy munka; a RetroArch úton (4. pont) az android elérés majdnem ingyen megvan.
A minta
Mind ugyanaz a forma: olvasd a WarpEngine katalógust → írd a gazdaplatform saját könyvtárformátumát. A warp-engine-batocera-store szétválasztásával ezt már megalapoztuk. Ha a közös rész — katalógus-lekérés és gyorsítótár, kiadásválasztás (dev- kihagyás, asset-egyeztetés), state.json, borítókép, prune-védelem saját almappával — egy helyen marad, akkor egy új store valóban csak egy adapter plusz egy config.
Egy dolog viszont nem tartozik az adapterbe, hanem a közös részbe: az architektúra-illesztés. A gazdaplatform megmondja, milyen gépen fut (uname -m, Windows/macOS esetén a megfelelő megfelelője), és a motornak ehhez kell asset-fajtát választania. Ez a 0., 1. és 2. pontnak egyaránt kell, tehát egyszer, jó helyen érdemes megírni.
A javasolt sorrend
linux_arm64a build-mátrixba (0. pont) — enélkül a retró-vonal fele, a kézikonzolok pedig teljesen kimaradnak.- Architektúra-illesztés a motorba — a közös rész, amire utána minden store épít.
linux_*→ Batocera ports (0b) — a meglévő store-t hozza tisztába, 7/15-ről 12/15-re.- ES-családú store-ok (1.) — a motor itt már majdnem kész.
Amit valódi gépen kell ellenőrizni
A 2. és 3. pont azon áll vagy bukik, hogy a per-OS zipjeink önmagukban futtathatók-e: van-e hiányzó függőség Linuxon, és mit szól hozzá a macOS aláírás-ellenőrzése egy nem jegyzett binárishoz. Erről a katalógus nem árulkodik, csak egy próba.