-/* 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).
RETRO_LANGUAGE_ARABIC = 16,
RETRO_LANGUAGE_GREEK = 17,
RETRO_LANGUAGE_TURKISH = 18,
+ RETRO_LANGUAGE_SLOVAK = 19,
RETRO_LANGUAGE_LAST,
/* Ensure sizeof(enum) == sizeof(int) */
#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'
* This may be still be done regardless of the core options
* interface version.
*
- * If version is 1 however, core options may instead be set by
+ * If version is >= 1 however, core options may instead be set by
* passing an array of retro_core_option_definition structs to
* RETRO_ENVIRONMENT_SET_CORE_OPTIONS, or a 2D array of
* retro_core_option_definition structs to RETRO_ENVIRONMENT_SET_CORE_OPTIONS_INTL.
* GET_VARIABLE.
* This allows the frontend to present these variables to
* a user dynamically.
- * This should only be called if RETRO_ENVIRONMENT_GET_ENHANCED_CORE_OPTIONS
- * returns an API version of 1.
+ * This should only be called if RETRO_ENVIRONMENT_GET_CORE_OPTIONS_VERSION
+ * returns an API version of >= 1.
* This should be called instead of RETRO_ENVIRONMENT_SET_VARIABLES.
* This should be called the first time as early as
* possible (ideally in retro_set_environment).
* i.e. it should be feasible to cycle through options
* without a keyboard.
*
- * First entry should be treated as a default.
- *
* Example entry:
* {
* "foo_option",
* GET_VARIABLE.
* This allows the frontend to present these variables to
* a user dynamically.
- * This should only be called if RETRO_ENVIRONMENT_GET_ENHANCED_CORE_OPTIONS
- * returns an API version of 1.
+ * This should only be called if RETRO_ENVIRONMENT_GET_CORE_OPTIONS_VERSION
+ * returns an API version of >= 1.
* This should be called instead of RETRO_ENVIRONMENT_SET_VARIABLES.
* This should be called the first time as early as
* possible (ideally in retro_set_environment).
* default when calling SET_VARIABLES/SET_CORE_OPTIONS.
*/
+#define RETRO_ENVIRONMENT_GET_PREFERRED_HW_RENDER 56
+ /* unsigned * --
+ *
+ * Allows an implementation to ask frontend preferred hardware
+ * context to use. Core should use this information to deal
+ * with what specific context to request with SET_HW_RENDER.
+ *
+ * 'data' points to an unsigned variable
+ */
+
+#define RETRO_ENVIRONMENT_GET_DISK_CONTROL_INTERFACE_VERSION 57
+ /* unsigned * --
+ * Unsigned value is the API version number of the disk control
+ * interface supported by the frontend. If callback return false,
+ * API version is assumed to be 0.
+ *
+ * In legacy code, the disk control interface is defined by passing
+ * a struct of type retro_disk_control_callback to
+ * RETRO_ENVIRONMENT_SET_DISK_CONTROL_INTERFACE.
+ * This may be still be done regardless of the disk control
+ * interface version.
+ *
+ * If version is >= 1 however, the disk control interface may
+ * instead be defined by passing a struct of type
+ * retro_disk_control_ext_callback to
+ * RETRO_ENVIRONMENT_SET_DISK_CONTROL_EXT_INTERFACE.
+ * This allows the core to provide additional information about
+ * disk images to the frontend and/or enables extra
+ * disk control functionality by the frontend.
+ */
+
+#define RETRO_ENVIRONMENT_SET_DISK_CONTROL_EXT_INTERFACE 58
+ /* const struct retro_disk_control_ext_callback * --
+ * Sets an interface which frontend can use to eject and insert
+ * disk images, and also obtain information about individual
+ * disk image files registered by the core.
+ * This is used for games which consist of multiple images and
+ * must be manually swapped out by the user (e.g. PSX, floppy disk
+ * 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).
+ */
+
/* VFS functionality */
/* File paths:
{
RETRO_SENSOR_ACCELEROMETER_ENABLE = 0,
RETRO_SENSOR_ACCELEROMETER_DISABLE,
+ RETRO_SENSOR_GYROSCOPE_ENABLE,
+ RETRO_SENSOR_GYROSCOPE_DISABLE,
+ RETRO_SENSOR_ILLUMINANCE_ENABLE,
+ RETRO_SENSOR_ILLUMINANCE_DISABLE,
RETRO_SENSOR_DUMMY = INT_MAX
};
#define RETRO_SENSOR_ACCELEROMETER_X 0
#define RETRO_SENSOR_ACCELEROMETER_Y 1
#define RETRO_SENSOR_ACCELEROMETER_Z 2
+#define RETRO_SENSOR_GYROSCOPE_X 3
+#define RETRO_SENSOR_GYROSCOPE_Y 4
+#define RETRO_SENSOR_GYROSCOPE_Z 5
+#define RETRO_SENSOR_ILLUMINANCE 6
typedef bool (RETRO_CALLCONV *retro_set_sensor_state_t)(unsigned port,
enum retro_sensor_action action, unsigned rate);
retro_keyboard_event_t callback;
};
-/* Callbacks for RETRO_ENVIRONMENT_SET_DISK_CONTROL_INTERFACE.
+/* Callbacks for RETRO_ENVIRONMENT_SET_DISK_CONTROL_INTERFACE &
+ * RETRO_ENVIRONMENT_SET_DISK_CONTROL_EXT_INTERFACE.
* Should be set for implementations which can swap out multiple disk
* images in runtime.
*
* with replace_image_index. */
typedef bool (RETRO_CALLCONV *retro_add_image_index_t)(void);
+/* Sets initial image to insert in drive when calling
+ * core_load_game().
+ * Since we cannot pass the initial index when loading
+ * content (this would require a major API change), this
+ * is set by the frontend *before* calling the core's
+ * retro_load_game()/retro_load_game_special() implementation.
+ * A core should therefore cache the index/path values and handle
+ * them inside retro_load_game()/retro_load_game_special().
+ * - If 'index' is invalid (index >= get_num_images()), the
+ * core should ignore the set value and instead use 0
+ * - 'path' is used purely for error checking - i.e. when
+ * content is loaded, the core should verify that the
+ * disk specified by 'index' has the specified file path.
+ * This is to guard against auto selecting the wrong image
+ * if (for example) the user should modify an existing M3U
+ * playlist. We have to let the core handle this because
+ * set_initial_image() must be called before loading content,
+ * i.e. the frontend cannot access image paths in advance
+ * and thus cannot perform the error check itself.
+ * If set path and content path do not match, the core should
+ * ignore the set 'index' value and instead use 0
+ * Returns 'false' if index or 'path' are invalid, or core
+ * does not support this functionality
+ */
+typedef bool (RETRO_CALLCONV *retro_set_initial_image_t)(unsigned index, const char *path);
+
+/* Fetches the path of the specified disk image file.
+ * Returns 'false' if index is invalid (index >= get_num_images())
+ * or path is otherwise unavailable.
+ */
+typedef bool (RETRO_CALLCONV *retro_get_image_path_t)(unsigned index, char *path, size_t len);
+
+/* Fetches a core-provided 'label' for the specified disk
+ * image file. In the simplest case this may be a file name
+ * (without extension), but for cores with more complex
+ * content requirements information may be provided to
+ * facilitate user disk swapping - for example, a core
+ * running floppy-disk-based content may uniquely label
+ * save disks, data disks, level disks, etc. with names
+ * corresponding to in-game disk change prompts (so the
+ * frontend can provide better user guidance than a 'dumb'
+ * disk index value).
+ * Returns 'false' if index is invalid (index >= get_num_images())
+ * or label is otherwise unavailable.
+ */
+typedef bool (RETRO_CALLCONV *retro_get_image_label_t)(unsigned index, char *label, size_t len);
+
struct retro_disk_control_callback
{
retro_set_eject_state_t set_eject_state;
retro_add_image_index_t add_image_index;
};
+struct retro_disk_control_ext_callback
+{
+ retro_set_eject_state_t set_eject_state;
+ retro_get_eject_state_t get_eject_state;
+
+ retro_get_image_index_t get_image_index;
+ retro_set_image_index_t set_image_index;
+ retro_get_num_images_t get_num_images;
+
+ retro_replace_image_index_t replace_image_index;
+ retro_add_image_index_t add_image_index;
+
+ /* NOTE: Frontend will only attempt to record/restore
+ * last used disk index if both set_initial_image()
+ * and get_image_path() are implemented */
+ retro_set_initial_image_t set_initial_image; /* Optional - may be NULL */
+
+ retro_get_image_path_t get_image_path; /* Optional - may be NULL */
+ retro_get_image_label_t get_image_label; /* Optional - may be NULL */
+};
+
enum retro_pixel_format
{
/* 0RGB1555, native endian.
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. */
};
/* Maximum number of values permitted for a core option
- * NOTE: This may be increased on a core-by-core basis
- * if required (doing so has no effect on the frontend) */
+ * > Note: We have to set a maximum value due the limitations
+ * of the C language - i.e. it is not possible to create an
+ * array of structs each containing a variable sized array,
+ * so the retro_core_option_definition values array must
+ * have a fixed size. The size limit of 128 is a balancing
+ * act - it needs to be large enough to support all 'sane'
+ * core options, but setting it too large may impact low memory
+ * platforms. In practise, if a core option has more than
+ * 128 values then the implementation is likely flawed.
+ * To quote the above API reference:
+ * "The number of possible options should be very limited
+ * i.e. it should be feasible to cycle through options
+ * without a keyboard."
+ */
#define RETRO_NUM_CORE_OPTION_VALUES_MAX 128
struct retro_core_option_value
notaz.gp2x.de / pcsx_rearmed.git / blobdiff