Primera versió

This commit is contained in:
2024-09-24 18:05:17 +02:00
commit 6d78bfd3f0
8 changed files with 3835 additions and 0 deletions
+24
View File
@@ -0,0 +1,24 @@
## Nocions bàsiques per a fer funcionar un jailgame dins d'emulationstation:
- Si el joc es per a una màquineta Anbernic amb Linux, compilar el joc en una Raspberry Pi per a que siga compatible amb ARM o ARM64. Recordar fer el joc compatible amb mandos i amb opció per a poder eixir del joc, així com ajustar be la resolució a la pantalla corresponent.
- Copiar la carpeta del joc dins del directori de roms que toque. Jo l'he copiat en "ports" pero es pot fer una entrada en `/userdata/system/configs/emulationstation/es_systems_jailgames.cfg` amb la descripció del nou sistema. S'adjunta un exemple al repositori.
- Crear un fitxer `.sh` per a executar el joc. Aquest fitxer es el que es vorà a la llista de roms del nostre sistema (o de "ports" si havem gastat eixe)
- Crear un `gamelist.xml` amb els metadatos que volem vore en el llistat de jocs del sistema. Si volem podem afegir imatges tipo:
> nom_del_joc-image.png
> nom_del_joc-screenshot.png
> nom_del_joc-marquee.png
> nom_del_joc-wheel.png
- Els fitxers `imatge.png` i `screenshot.png` son per a la captura del joc però no se la diferència exacta o quina està utilitzant. Els altres dos, `marquee.png` i `wheel.png`, s'utilitzen per a mostrar el titol del joc.
- Si volem retocar el tema, s'hauran d'afegir els fitxers corresponents així com posar una imatge per al nom del sistema i per al fondo del sistema. A continuació s'explica com fer-ho per al tema `art-book-next`.
- La ruta on colocar els fitxers es `/userdata/theme-customizations/art-book-next/`
- Art de fondo: Crea una carpeta anomenada `artwork` i col·loca allí el fitxer amb el nom del sistema, en el nostre cas `jailgames.png`. Recorda que per a gastar estos logos s'ha d'activar al tema canviant `System Artwork` a `Custom`.
- Logos: Crea una carpeta anomenada `logos` i col·loca allí el fitxer amb el nom del sistema, en el nostre cas `jailgames.png`. Recorda que per a gastar estos logos s'ha d'activar al tema canviant `System Logos` a `Custom`.
+3537
View File
File diff suppressed because it is too large Load Diff
+23
View File
@@ -0,0 +1,23 @@
<?xml version="1.0" encoding="UTF-8"?>
<systemList>
<system>
<fullname>JailGames</fullname>
<name>jailgames</name>
<manufacturer>JailGames</manufacturer>
<release>None</release>
<hardware>jailgame</hardware>
<path>/userdata/roms/jailgames</path>
<extension>.sh .squashfs</extension>
<command>emulatorlauncher %CONTROLLERSCONFIG% -system %SYSTEM% -rom %ROM% -gameinfoxml %GAMEINFOXML% -systemname %SYSTEMNAME%</command>
<platform>jailgames</platform>
<theme>jailgames</theme>
<group>jailgames</group>
<emulators>
<emulator name="sh">
<cores>
<core default="true">sh</core>
</cores>
</emulator>
</emulators>
</system>
</systemList>
+89
View File
@@ -0,0 +1,89 @@
Gamelists
=========
The gamelist.xml file for a system defines metadata for a system's games, such as a name, image (like a screenshot or box art), description, release date, and rating.
ES will check three places for a gamelist.xml in the following order, using the first one it finds:
* `[SYSTEM_PATH]/gamelist.xml`
* `~/.emulationstation/gamelists/[SYSTEM_NAME]/gamelist.xml`
* `/etc/emulationstation/gamelists/[SYSTEM_NAME]/gamelist.xml`
An example gamelist.xml:
```xml
<gameList>
<game>
<path>/home/pi/ROMs/nes/mm2.nes</path>
<name>Mega Man 2</name>
<desc>Mega Man 2 is a classic NES game which follows Mega Man as he murders eight robot masters in cold blood.</desc>
<image>~/.emulationstation/downloaded_images/nes/Mega Man 2-image.png</image>
</game>
</gameList>
```
Everything is enclosed in a `<gameList>` tag. The information for each game or folder is enclosed in a corresponding tag (`<game>` or `<folder>`). Each piece of metadata is encoded as a string.
Reference
=========
(if you suspect this section is out of date, check out `src/MetaData.cpp`)
There are a few types of metadata:
* `string` - just text.
* `image_path` - a path to an image. This path should be either the absolute to the image, a path relative to the system games folder that starts with "./" (e.g. `./mm2_image.png`), or a path relative to the home directory that starts with "~/" (e.g. `~/.emulationstation/downloaded_images/nes/mm2-image.png`). Images will be automatically resized by OpenGL to fit the corresponding `<image>` tag in the current theme. Smaller images will load faster, so try to keep resolution low!
* `video_path` - a path to a video. Similar to `image_path`.
* `float` - a floating-point decimal value (written as a string).
* `integer` - an integer value (written as a string).
* `datetime` - a date and, potentially, a time. These are encoded as an ISO string, in the following format: "%Y%m%dT%H%M%S%F%q". For example, the release date for Chrono Trigger is encoded as "19950311T000000" (no time specified).
Some metadata is also marked as "statistic" - these are kept track of by ES and do not show up in the metadata editor. They are shown in certain views (for example, the detailed view shows both `playcount` and `lastplayed`).
#### `<game>`
* `name` - string, the displayed name for the game.
* `desc` - string, a description of the game. Longer descriptions will automatically scroll, so don't worry about size.
* `image` - image_path, the path to an image to display for the game (like box art or a screenshot).
* `thumbnail` - image_path, the path to a smaller image, displayed in image lists like the grid view. Should be small to ensure quick loading.
* `video` - video_path, the path to a video to display for the game, for themes that support the _video_ viewstyle.
* `rating` - float, the rating for the game, expressed as a floating point number between 0 and 1. Arbitrary values are fine (ES can display half-stars, quarter-stars, etc).
* `releasedate` - datetime, the date the game was released. Displayed as date only, time is ignored.
* `developer` - string, the developer for the game.
* `publisher` - string, the publisher for the game.
* `genre` - string, the (primary) genre for the game.
* `players` - integer, the number of players the game supports.
* `playcount` - statistic, integer, the number of times this game has been played.
* `lastplayed` - statistic, datetime, the last date and time this game was played.
#### `<folder>`
* `name` - string, the displayed name for the folder.
* `desc` - string, the description for the folder.
* `image` - image_path, the path to an image to display for the folder.
* `thumbnail` - image_path, the path to a smaller image to display for the folder.
Things to be Aware Of
=====================
* You can use ES's built-in [scraping](http://en.wikipedia.org/wiki/Web_scraping) tools to avoid creating a gamelist.xml by hand, as described in README.md.
* ES will try to write any image paths as relative to the current system games path or relative to the current home directory if it can. This is done to try and keep installations portable (so you can copy them between computers).
* One thing to be aware of: the EmulationStation text rendering code doesn't currently support Unicode. If I fix this in the future, it will probably use UTF-8. For now, you'll just have to convert names and descriptions to ASCII. Sorry!
* If a value matches the default for a particular piece of metadata, ES will not write it to the gamelist.xml (for example, if `genre` isn't specified, ES won't write an empty genre tag; if `players` is 1, ES won't write a `players` tag).
* A `game` can actually point to a folder/directory if the the folder has a matching extension.
* `folder` metadata will only be used if a game is found inside of that folder.
* ES will keep entries for games and folders that it can't find the files for.
* The switch `--gamelist-only` can be used to skip automatic searching, and only display games defined in the system's gamelist.xml.
* The switch `--ignore-gamelist` can be used to ignore the gamelist and force ES to use the non-detailed view.
* If at least one game in a system has an image specified, ES will use the detailed view for that system (which displays metadata alongside the game list).
* If you want to write your own scraper, the built-in scraping system is actually pretty extendable if you can get past the ugly function declarations and your instinctual fear of C++. Check out `src/scrapers/GamesDBScraper.cpp` for an example (it's less than a hundred lines of actual code). An offline scraper is also possible (though you'll have to subclass `ScraperRequest`). I hope to write a more complete guide on how to do this in the future.
+23
View File
@@ -0,0 +1,23 @@
<?xml version="1.0"?>
<gameList>
<game>
<path>./ccae/ccae.sh</path>
<name>Coffee Crisis Arcade Edition</name>
<desc>Coffee Crisis es un juego arcade que pondrá a prueba tus reflejos. Empezado
durante el verano de 2020 y terminado un año despues, en el verano de 2021.
Intenta conseguir todos los puntos que puedas con una sola vida a traves de
los 10 niveles de juego y ayuda a Bal1 a defender la UPV de la invasión de
la cafeína esférica y saltarina.</desc>
<image>./downloaded_images/coffee_crisis_arcade_edition-image.png</image>
<wheel>./downloaded_images/coffee_crisis_arcade_edition-wheel.png</wheel>
<boxart>./downloaded_images/coffee_crisis_arcade_edition-boxart.png</boxart>
<screenshot>./downloaded_images/coffee_crisis_arcade_edition-screenshot.png</screenshot>
<marquee>./downloaded_images/coffee_crisis_arcade_edition-marquee.png</marquee>
<releasedate>20090414T000000</releasedate>
<developer>JailGames</developer>
<publisher>JailGames</publisher>
<genre>Arcade</genre>
<players>2</players>
<lang>ca</lang>
</game>
</gameList>
+139
View File
@@ -0,0 +1,139 @@
# Customize ES Systems[](https://wiki.batocera.org/emulationstation:customize_systems#customize_es_systems)
EmulationStation displays systems based on a file called `es_systems.cfg`. In other distributions, this is typically the only file. However, in Batocera the `/userdata/system/configs/emulationstation/es_systems_<custom_name>.cfg` can be used as an overlay to the original `/usr/share/emulationstation/es_systems.cfg` file.
> If preferred, the entire file can be overridden by instead using
> `/userdata/system/configs/emulationstation/es_systems.cfg`. Be careful
> if doing this, as the entire notion of maintaining this file as
> Batocera upgrades its internals (namely Python) thus rely on you. This
> is really only suitable if you never intend on updating Batocera
> again.
> Whenever Batocera is upgraded, its version of Python used may also
> change. This means if you are using an `es_systems.cfg` which
> manually defines the `<command>` (for example:
> `<command>/usr/lib/python2.7/site-packages/configgen/emulatorlauncher.py</command>`
> which is calling an older Python version), it will need to be updated
> accordingly.
>
> In general, it is recommended to avoid using a custom `<command>`
> and to just use the default one.
## Modify an existing system with a new system-specific "es_systems_<custom_name>.cfg" file[](https://wiki.batocera.org/emulationstation:customize_systems#modify_an_existing_system_with_a_new_system-specific_es_systems_custom_name_cfg_file)
You can create a file named `es_systems_<custom_name>.cfg` where `<custom_name>` is a name you wish to use for it. This file needs to follow the same conventions as the original `es_systems.cfg`, but does not need to include the entirety of the file. For example:
[es_systems_3do.cfg](https://wiki.batocera.org/_export/code/emulationstation:customize_systems?codeblock=0 "Download Snippet")
<?xml version="1.0"?>
<systemList>
<!-- This line is a comment, not necessary for the system. These will explain things, and can be safely removed. -->
<system>
<!-- The full name of the system, the one that will appear in menus and such. -->
<fullname>3DO Interactive Multiplayer</fullname>
<!-- The short name, the one used for the path to the system's ROMs and other internal uses. -->
<name>3do</name>
<!-- Metadata. The company/companies that made the system, also known as "Brand". Metadata tags like this aren't truly necessary, but can make organization easier. -->
<manufacturer>Panasonic - Sanyo - Goldstar</manufacturer>
<!-- Metadata. Release date. -->
<release>1993</release>
<!-- The type of hardware. Batocera doesn't particularly use this for anything, but it might be useful to specify here for future changes. -->
<hardware>console</hardware>
<!-- Extremely important, the path to look for this system's ROMs in. This should always start with /userdata/roms/. -->
<path>/userdata/roms/3do</path>
<!-- The file extensions of ROMs that should be scanned into ES's gamelist.xml when the user rescans their gamelist. Delimited by whitespaces. You must include the period mark (.) and proper capitalization. -->
<extension>.iso .chd .cue</extension>
<!-- Ordinarily this is the command line used to directly run the program, but Batocera relies on config generators to do so. This simply calls that generator, along with some other information. -->
<command>python /usr/lib/python3.9/site-packages/configgen/emulatorlauncher.py %CONTROLLERSCONFIG% -system %SYSTEM% -rom %ROM%</command>
<!-- The platform to use when scraping for metadata for this system's games. The full list of available platforms are in https://github.com/batocera-linux/batocera-emulationstation/blob/master/es-app/src/PlatformId.cpp -->
<platform>3do</platform>
<!-- The theme to load from the current theme-set, if supported. Usually, this is identical to the shortname. Check your theme's readme for more info. -->
<theme>3do</theme>
<emulators>
<!-- These are the emulators used for the system. This is handled entirely by Batocera, and is not necessary for a custom es systems, but is shown here for reference. -->
<emulator name="libretro">
<cores>
<core default="true">opera</core>
</cores>
</emulator>
</emulators>
</system>
</systemList>
would only affect the 3DO system on your Batocera, with the rest of the systems still referring to `/usr/share/emulationstation/es_systems.cfg` for their system CFG. When both files contain the same `<name>`, `es_systems_<custom_name>.cfg` will take priority.
In case you'd like to have complete control over ES systems CFG, you can still use the two previous methods to completely override it (ie. using overlays or copying the entirety of `es_systems.cfg` to `/userdata/system/configs/emulationstation/es_systems.cfg` without appending a custom system name to its filename).
Batocera is smart enough to _only_ apply the changes you make. Such as, if the only thing you need to change for a system is its ROM path, you can use the following in your `/userdata/system/configs/emulationstation/es_systems_pico8.cfg`:
[es_systems_pico8.cfg](https://wiki.batocera.org/_export/code/emulationstation:customize_systems?codeblock=1 "Download Snippet")
<?xml version="1.0" encoding="UTF-8"?>
<systemList>
<system>
<name>pico8</name>
<path>/userdata/roms/pico8real</path>
</system>
</systemList>
Here, it'll use the folder `/userdata/roms/pico8real/` to look for Pico-8 games instead of the regular one, and use the rest of the configuration from the `/usr/share/emulationstation/es_systems.cfg` file.
## Create a new system[](https://wiki.batocera.org/emulationstation:customize_systems#create_a_new_system)
The method above can also be applied to make a brand new system in place of editing an already existing one. For instance, you might want to create a new “megadrivehacks” system intended for Megadrive/Genesis ROMhacks.
Create a `/userdata/system/configs/emulationstation/es_systems_megadrivehacks.cfg` file that contains the following:
[es_systems_megadrivehacks.cfg](https://wiki.batocera.org/_export/code/emulationstation:customize_systems?codeblock=2 "Download Snippet")
<?xml version="1.0"?>
<systemList>
<system>
<!-- The custom name of this system. -->
<fullname>Megadrive hacks</fullname>
<!-- Keep the name the same for the system you are basing it off it, saving you work later. -->
<name>megadrive</name>
<manufacturer>Sega</manufacturer>
<release>1988</release>
<hardware>console</hardware>
<!-- Specify your new path. -->
<path>/userdata/roms/megadrivehacks</path>
<extension>.bin .gen .md .sg .smd .zip .7z</extension>
<command>python /usr/lib/python3.9/site-packages/configgen/emulatorlauncher.py %CONTROLLERSCONFIG% -system %SYSTEM% -rom %ROM%</command>
<!-- Since this is used only for scraping, it's safe to leave it as default. You'll probably have to be providing your own metadata for ROMhacks anyway. -->
<platform>megadrive</platform>
<!-- Change the theme to use the custom assets instead. -->
<theme>megadrivehacks</theme>
<!-- Leave the emulators the same. -->
<emulators>
<emulator name="libretro">
<cores>
<core>blastem</core>
<core default="true">genesisplusgx</core>
<core>genesisplusgx-wide</core>
<core>picodrive</core>
</cores>
</emulator>
</emulators>
</system>
</systemList>
The `<name>` and `<platform>` paths in this example are kept the same such that they can still use the defaults as specified by Batocera. If you really want to use a unique `<name>`, you'll have to manually specify your default emulator in `batocera.conf`. For instance if you were defining a new system with `<name>cps1</name>` then the following would be added to `batocera.conf`:
cps1.emulator=libretro
cps1.core=fbneo
These default emulators can also be defined in the `/usr/share/batocera/configgen/configgen-defaults.yml` and/or `/usr/share/batocera/configgen/configgen-defaults-arch.yml` system defaults file.
> You must use a unique `<name>` field when adding a new system if you
> wish to keep the old one in addition. However, if using duplicate
> shortnames is a necessity and you still want the new and old system to
> exist simultaneously, you can also put both systems in a single CFG
> file.
> Despite `<core default=“true”>` being specified in the
> `es_systems_megadrivehacks.cfg` file, Batocera doesn't actually use
> this as the default when launching an emulator. It instead looks for
> its own list of defaults for its configgen.
In case you're making a brand new system with brand new emulators/parameters, refer to [the developer documentation](https://wiki.batocera.org/coding_rules#how_to_add_an_emulator "coding_rules") instead.
Binary file not shown.

After

Width:  |  Height:  |  Size: 89 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.4 KiB