-/* Copyright (C) 2010-2018 The RetroArch team
+/* Copyright (C) 2010-2020 The RetroArch team
*
* ---------------------------------------------------------------------------------------
* The following license statement only applies to this libretro API header (libretro.h).
# endif
# endif
# else
-# if defined(__GNUC__) && __GNUC__ >= 4 && !defined(__CELLOS_LV2__)
+# if defined(__GNUC__) && __GNUC__ >= 4
# define RETRO_API RETRO_CALLCONV __attribute__((__visibility__("default")))
# else
# define RETRO_API RETRO_CALLCONV
RETRO_LANGUAGE_ARABIC = 16,
RETRO_LANGUAGE_GREEK = 17,
RETRO_LANGUAGE_TURKISH = 18,
+ RETRO_LANGUAGE_SLOVAK = 19,
+ RETRO_LANGUAGE_PERSIAN = 20,
+ RETRO_LANGUAGE_HEBREW = 21,
+ RETRO_LANGUAGE_ASTURIAN = 22,
+ RETRO_LANGUAGE_FINNISH = 23,
RETRO_LANGUAGE_LAST,
/* Ensure sizeof(enum) == sizeof(int) */
* state of rumble motors in controllers.
* A strong and weak motor is supported, and they can be
* controlled indepedently.
+ * Should be called from either retro_init() or retro_load_game().
+ * Should not be called from retro_set_environment().
+ * Returns false if rumble functionality is unavailable.
*/
#define RETRO_ENVIRONMENT_GET_INPUT_DEVICE_CAPABILITIES 24
/* uint64_t * --
#define RETRO_ENVIRONMENT_GET_TARGET_REFRESH_RATE (50 | RETRO_ENVIRONMENT_EXPERIMENTAL)
/* float * --
- * Float value that lets us know what target refresh rate
+ * Float value that lets us know what target refresh rate
* is curently in use by the frontend.
*
- * The core can use the returned value to set an ideal
+ * The core can use the returned value to set an ideal
* refresh rate/framerate.
*/
/* bool * --
* Boolean value that indicates whether or not the frontend supports
* input bitmasks being returned by retro_input_state_t. The advantage
- * of this is that retro_input_state_t has to be only called once to
+ * of this is that retro_input_state_t has to be only called once to
* grab all button states instead of multiple times.
*
* If it returns true, you can pass RETRO_DEVICE_ID_JOYPAD_MASK as 'id'
* based systems).
*/
+#define RETRO_ENVIRONMENT_GET_MESSAGE_INTERFACE_VERSION 59
+ /* unsigned * --
+ * Unsigned value is the API version number of the message
+ * interface supported by the frontend. If callback returns
+ * false, API version is assumed to be 0.
+ *
+ * In legacy code, messages may be displayed in an
+ * implementation-specific manner by passing a struct
+ * of type retro_message to RETRO_ENVIRONMENT_SET_MESSAGE.
+ * This may be still be done regardless of the message
+ * interface version.
+ *
+ * If version is >= 1 however, messages may instead be
+ * displayed by passing a struct of type retro_message_ext
+ * to RETRO_ENVIRONMENT_SET_MESSAGE_EXT. This allows the
+ * core to specify message logging level, priority and
+ * destination (OSD, logging interface or both).
+ */
+
+#define RETRO_ENVIRONMENT_SET_MESSAGE_EXT 60
+ /* const struct retro_message_ext * --
+ * Sets a message to be displayed in an implementation-specific
+ * manner for a certain amount of 'frames'. Additionally allows
+ * the core to specify message logging level, priority and
+ * destination (OSD, logging interface or both).
+ * Should not be used for trivial messages, which should simply be
+ * logged via RETRO_ENVIRONMENT_GET_LOG_INTERFACE (or as a
+ * fallback, stderr).
+ */
+
+#define RETRO_ENVIRONMENT_GET_INPUT_MAX_USERS 61
+ /* unsigned * --
+ * Unsigned value is the number of active input devices
+ * provided by the frontend. This may change between
+ * frames, but will remain constant for the duration
+ * of each frame.
+ * If callback returns true, a core need not poll any
+ * input device with an index greater than or equal to
+ * the number of active devices.
+ * If callback returns false, the number of active input
+ * devices is unknown. In this case, all input devices
+ * should be considered active.
+ */
+
+#define RETRO_ENVIRONMENT_SET_AUDIO_BUFFER_STATUS_CALLBACK 62
+ /* const struct retro_audio_buffer_status_callback * --
+ * Lets the core know the occupancy level of the frontend
+ * audio buffer. Can be used by a core to attempt frame
+ * skipping in order to avoid buffer under-runs.
+ * A core may pass NULL to disable buffer status reporting
+ * in the frontend.
+ */
+
+#define RETRO_ENVIRONMENT_SET_MINIMUM_AUDIO_LATENCY 63
+ /* const unsigned * --
+ * Sets minimum frontend audio latency in milliseconds.
+ * Resultant audio latency may be larger than set value,
+ * or smaller if a hardware limit is encountered. A frontend
+ * is expected to honour requests up to 512 ms.
+ *
+ * - If value is less than current frontend
+ * audio latency, callback has no effect
+ * - If value is zero, default frontend audio
+ * latency is set
+ *
+ * May be used by a core to increase audio latency and
+ * therefore decrease the probability of buffer under-runs
+ * (crackling) when performing 'intensive' operations.
+ * A core utilising RETRO_ENVIRONMENT_SET_AUDIO_BUFFER_STATUS_CALLBACK
+ * to implement audio-buffer-based frame skipping may achieve
+ * optimal results by setting the audio latency to a 'high'
+ * (typically 6x or 8x) integer multiple of the expected
+ * frame time.
+ *
+ * WARNING: This can only be called from within retro_run().
+ * Calling this can require a full reinitialization of audio
+ * drivers in the frontend, so it is important to call it very
+ * sparingly, and usually only with the users explicit consent.
+ * An eventual driver reinitialize will happen so that audio
+ * callbacks happening after this call within the same retro_run()
+ * call will target the newly initialized driver.
+ */
+
/* VFS functionality */
/* File paths:
retro_usec_t reference;
};
+/* Notifies a libretro core of the current occupancy
+ * level of the frontend audio buffer.
+ *
+ * - active: 'true' if audio buffer is currently
+ * in use. Will be 'false' if audio is
+ * disabled in the frontend
+ *
+ * - occupancy: Given as a value in the range [0,100],
+ * corresponding to the occupancy percentage
+ * of the audio buffer
+ *
+ * - underrun_likely: 'true' if the frontend expects an
+ * audio buffer underrun during the
+ * next frame (indicates that a core
+ * should attempt frame skipping)
+ *
+ * It will be called right before retro_run() every frame. */
+typedef void (RETRO_CALLCONV *retro_audio_buffer_status_callback_t)(
+ bool active, unsigned occupancy, bool underrun_likely);
+struct retro_audio_buffer_status_callback
+{
+ retro_audio_buffer_status_callback_t callback;
+};
+
/* Pass this to retro_video_refresh_t if rendering to hardware.
* Passing NULL to retro_video_refresh_t is still a frame dupe as normal.
* */
unsigned frames; /* Duration in frames of message. */
};
+enum retro_message_target
+{
+ RETRO_MESSAGE_TARGET_ALL = 0,
+ RETRO_MESSAGE_TARGET_OSD,
+ RETRO_MESSAGE_TARGET_LOG
+};
+
+enum retro_message_type
+{
+ RETRO_MESSAGE_TYPE_NOTIFICATION = 0,
+ RETRO_MESSAGE_TYPE_NOTIFICATION_ALT,
+ RETRO_MESSAGE_TYPE_STATUS,
+ RETRO_MESSAGE_TYPE_PROGRESS
+};
+
+struct retro_message_ext
+{
+ /* Message string to be displayed/logged */
+ const char *msg;
+ /* Duration (in ms) of message when targeting the OSD */
+ unsigned duration;
+ /* Message priority when targeting the OSD
+ * > When multiple concurrent messages are sent to
+ * the frontend and the frontend does not have the
+ * capacity to display them all, messages with the
+ * *highest* priority value should be shown
+ * > There is no upper limit to a message priority
+ * value (within the bounds of the unsigned data type)
+ * > In the reference frontend (RetroArch), the same
+ * priority values are used for frontend-generated
+ * notifications, which are typically assigned values
+ * between 0 and 3 depending upon importance */
+ unsigned priority;
+ /* Message logging level (info, warn, error, etc.) */
+ enum retro_log_level level;
+ /* Message destination: OSD, logging interface or both */
+ enum retro_message_target target;
+ /* Message 'type' when targeting the OSD
+ * > RETRO_MESSAGE_TYPE_NOTIFICATION: Specifies that a
+ * message should be handled in identical fashion to
+ * a standard frontend-generated notification
+ * > RETRO_MESSAGE_TYPE_NOTIFICATION_ALT: Specifies that
+ * message is a notification that requires user attention
+ * or action, but that it should be displayed in a manner
+ * that differs from standard frontend-generated notifications.
+ * This would typically correspond to messages that should be
+ * displayed immediately (independently from any internal
+ * frontend message queue), and/or which should be visually
+ * distinguishable from frontend-generated notifications.
+ * For example, a core may wish to inform the user of
+ * information related to a disk-change event. It is
+ * expected that the frontend itself may provide a
+ * notification in this case; if the core sends a
+ * message of type RETRO_MESSAGE_TYPE_NOTIFICATION, an
+ * uncomfortable 'double-notification' may occur. A message
+ * of RETRO_MESSAGE_TYPE_NOTIFICATION_ALT should therefore
+ * be presented such that visual conflict with regular
+ * notifications does not occur
+ * > RETRO_MESSAGE_TYPE_STATUS: Indicates that message
+ * is not a standard notification. This typically
+ * corresponds to 'status' indicators, such as a core's
+ * internal FPS, which are intended to be displayed
+ * either permanently while a core is running, or in
+ * a manner that does not suggest user attention or action
+ * is required. 'Status' type messages should therefore be
+ * displayed in a different on-screen location and in a manner
+ * easily distinguishable from both standard frontend-generated
+ * notifications and messages of type RETRO_MESSAGE_TYPE_NOTIFICATION_ALT
+ * > RETRO_MESSAGE_TYPE_PROGRESS: Indicates that message reports
+ * the progress of an internal core task. For example, in cases
+ * where a core itself handles the loading of content from a file,
+ * this may correspond to the percentage of the file that has been
+ * read. Alternatively, an audio/video playback core may use a
+ * message of type RETRO_MESSAGE_TYPE_PROGRESS to display the current
+ * playback position as a percentage of the runtime. 'Progress' type
+ * messages should therefore be displayed as a literal progress bar,
+ * where:
+ * - 'retro_message_ext.msg' is the progress bar title/label
+ * - 'retro_message_ext.progress' determines the length of
+ * the progress bar
+ * NOTE: Message type is a *hint*, and may be ignored
+ * by the frontend. If a frontend lacks support for
+ * displaying messages via alternate means than standard
+ * frontend-generated notifications, it will treat *all*
+ * messages as having the type RETRO_MESSAGE_TYPE_NOTIFICATION */
+ enum retro_message_type type;
+ /* Task progress when targeting the OSD and message is
+ * of type RETRO_MESSAGE_TYPE_PROGRESS
+ * > -1: Unmetered/indeterminate
+ * > 0-100: Current progress percentage
+ * NOTE: Since message type is a hint, a frontend may ignore
+ * progress values. Where relevant, a core should therefore
+ * include progress percentage within the message string,
+ * such that the message intent remains clear when displayed
+ * as a standard frontend-generated notification */
+ int8_t progress;
+};
+
/* Describes how the libretro implementation maps a libretro input bind
* to its internal input system through a human readable string.
* This string can be used to better let a user configure input. */
struct retro_system_info
{
/* All pointers are owned by libretro implementation, and pointers must
- * remain valid until retro_deinit() is called. */
+ * remain valid until it is unloaded. */
const char *library_name; /* Descriptive name of library. Should not
* contain any version numbers, etc. */