The ARM asset kind is in the build matrix and the engine now picks the asset that matches the machine, so the plan's first two steps are behind us. The measurement is refreshed too: linux_arm64 exists for one title, and the win/linux x64 counts moved as pipelines re-ran. Next is the one that turns the coverage number: installing non-cartridge assets as Batocera ports rather than ROMs. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
128 lines
8.0 KiB
Markdown
128 lines
8.0 KiB
Markdown
# 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. 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
|
|
|
|
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** (0b) — a következő lépés. A motor már tudja, milyen assetet válasszon; most az kell, hogy a nem-cartridge asseteket **portként** telepítse, ne ROM-ként.
|
|
4. **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.
|