# 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 (2026-08-17-i mérés): | Asset | Hány szoftvernél | Ki használja ma | |---|---|---| | `html` | **11** | senki — a publikus oldal lejátssza, de nincs könyvtár | | `win_x64` | **9** | senki | | `linux_x64` | **9** | senki | | `linux_arm64` | 1 | a batocera-store (arch-illesztéssel) | | `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 — *kész* *(2026-08-16-án megoldva; az alábbi indoklás megmaradt, mert a 3. és 4. pont erre épül.)* **Akkori állapot: a build-mátrixunkban nem volt 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:** 1. `linux_arm64` (és ha kell, `linux_armhf`) felvétele a `KINDS`-be és a platformok `ci_platforms` mátrixába. 2. 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. 3. A motor **architektúra-felismerése** (`uname -m` → `x86_64` / `aarch64` / `armv7l`), és csak az illeszkedő asset telepítése. ## 0b. `linux_*` → Batocera *ports* — *kész* *(2026-08-17-én megvalósítva a motorban.)* A ROM-rendszerek mellett van egy második telepítési mód: `install: "port"` esetén a zip kicsomagolódik, és egy `.sh` indító kerül a Ports rendszerbe. A payload a `ports/.data//` alá megy — a pont rejti el az ES elől —, az indító pedig egy normál almappába, amit az ES ugyanúgy pásztáz, mint bármely más rendszerét. Számokban, a mai assetekkel: | Gép | Lefedettség (mérve 2026-08-17) | |---|---| | x86_64 Batocera | **13/15** | | ARM Batocera | **9/15** — és nő, ahogy a repók újrafutnak az ARM pipeline-nal | A kimaradó kettő a `phaserdemo` és a `trickster-tiles`: mindkettő csak `html`-t ad, natív binárisuk nincs, tehát ezekhez böngésző kell — natív store soha nem fogja őket kiszolgálni. 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. **Kész (2026-08-17).** Terv és mérések: `RETROARCH_STORE.md`. Három repó: `engines/warpstore` (a kiemelt közös mag), `stores/warp-engine-retroarch-store` (motor), `stores/ttg-retroarch-store` (a mi store-unk). A Batocera-motor ugyanabban a körben átült a közös magra. **Hátra van:** valódi gépen kipróbálni, hogy a VICE-mag magától indítja-e a `.prg`-t, és hogy az Android `adb push` útvonalai állnak-e. Ott mérve: mind a két mag (`vice_x64`, `tic80`) elérhető minden célon, Androidon is; a playlist-könyvtár nem feltétlenül a RetroArch alapkönyvtárában van, tehát a `retroarch.cfg` kötelező olvasmány; a borító csak PNG lehet, amin az `impostor` GIF-je ma elhasal; leírást a `.lpl` nem tud. A motor egyetlen valódi új képessége az út-átírás (`stage_root` / `target_prefix`), ami az Androidot és a 2. pont asztali store-ját egyszerre szolgálja. ### 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 közös rész 2026-08-17-én kiemelve:** `engines/warpstore`, egyetlen fájl, amit mindkét motor a telepítéskor letölt. Benne a katalógus és gyorsítótára, a kiadásválasztás, a `state.json`, a borító-letöltés, az atomikus írás és a törlés-őr — plusz az architektúra-illesztés, ami a második adapter miatt `resolve_for_host`-tá bővült: nem csak az `arch`, hanem az `os` is kulcs lehet, mert egy libretro mag fájlneve OS-enként más. Egy új store innentől valóban egy adapter plusz egy config. ## A javasolt sorrend 1. ~~**`linux_arm64` a build-mátrixba**~~ — **kész** (2026-08-16). Az `ebitengine` és a `bevy` gyártja; a `godot`-hoz a játék repójában kell ARM export preset, a LÖVE-hoz nincs upstream ARM AppImage, a TIC-80 `export` parancsának meg nincs ARM célja. A `bevydemo` 1.0.0 már `linux_arm64`-et is ad. 2. ~~**Architektúra-illesztés a motorba**~~ — **kész** (2026-08-17). A `kind` és az `ext` lehet architektúra-leképezés `*` tartalékkal; a felismert arch látszik a `list` és a `config` kimenetében. `aarch64`-en végigpróbálva: az ARM csomagot tölti le, és a benne lévő bináris valóban AArch64. 3. ~~**`linux_*` → Batocera ports**~~ — **kész** (2026-08-17). `install: "port"`; `aarch64`-en végigpróbálva: telepítés, idempotens újraszinkron, eltávolítás a 106 MB-os payloaddal, és a névtér-védés is (idegen `.data` útra mutató bejegyzést elutasít). **Hátra van:** bekapcsolni a `ttg-batocera-store` configjában, és valódi gépen kipróbálni, hogy a natív játékok tényleg elindulnak-e. 4. ~~**RetroArch playlistek**~~ — **kész** (2026-08-17), a közös mag kiemelésével együtt. Lásd `RETROARCH_STORE.md`. **Hátra van:** a VICE `.prg`-autostart és az Android-út valódi gépen. 5. **ES-családú store-ok** (1.) — a motor itt már majdnem kész, és a `warpstore` óta az adapter tényleg csak a gazdaplatform írása. ## 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.