Glossary

This page defines important terms that are used throughout libretro.py’s documentation.

callback

callback function

A function that’s passed to a core or frontend at runtime, rather than at link-time like most C functions.

Note

Some libretro frontends link their cores statically due to platform limits. libretro.py isn’t one of them – all cores must be loaded at runtime!

content

The data that’s loaded into a core, usually a ROM containing a game.

core

An application wrapped in a library that exports the libretro API. Usually an emulator, but sometimes a game engine or media player. Libretro cores are distributed as dynamically-loaded libraries on most platforms, including all those supported by libretro.py.

driver

backend

An object that implements a subset of the libretro API in terms of the protocols defined in libretro.drivers.

Tip

libretro.py borrows this idea from RetroArch, which uses this term similarly; most of its subsystems have multiple implementations that can be swapped out at runtime without the core noticing.

For example, the Windows build of RetroArch can use WASAPI or DirectAudio for sound output; both backends implement the same internal interface.

environment call

envcall

A callback function exposed to a core that queries, modifies, or provides an interface to the frontend’s runtime environment.

All envcalls are invoked through the callback passed to Core.set_environment() (or equivalently, retro_environment_t).

frontend

An application that loads and runs libretro cores. RetroArch is the most well-known libretro frontend, but many others exist.

libretro

A common interface between the frontend and the core; exposing a game or emulator with this interface allows it to benefit from a frontend’s supported features without the author having to implement it themselves. Similar APIs such as BizHawk and Jolly Good exist, but these fall outside the scope of libretro.py.

libretro.h

The specific C header that defines the libretro interface. Almost all types in libretro.api are based on this header.

See also

libretro.h on GitHub

port

A “slot” that accepts input from an abstract device like the RetroPad. These usually correspond to an emulated platform’s controller ports, but not necessarily.

protocol

Python term for an interface. It’s convenient to define one as a Protocol subclass, but not usually required.

RetroArch

RetroArch is the canonical example (“reference implementation”) of a libretro frontend. Though it’s the most popular, others exist – including libretro.py!

RetroPad

gamepad

joypad

joystick

The abstraction over a gamepad used by libretro. Modeled after a SNES controller with analog triggers and joysticks. All cores that use gamepads specify their input in terms of RetroPad buttons.

ROM

ROM image

disk image

dump

ISO

A digital backup of a game’s read-only memory, including all of its code and data. Most cores accept one or more of these as content. Sometimes called an ISO or a dump, especially for disk-based media.

Note

Although there are technical nuances in how these terms are used, the distinctions aren’t relevant to libretro.py unless otherwise noted.

subsystem

A secondary platform that augments a core’s primary emulated hardware.

virtual environment

venv

A project-scoped installation of Python and various packages. Useful for developing a project with multiple versions of Python at once. Think of it like Python’s equivalent of node_modules.

Hint

Not related to environment calls.