This can avoid unnecessary waste of performance at runtime to use static data instead of filling out an array on the stack every time. Some of the CBS functions are called for every menu item created so this improves performance of menu navigation, especially large menus like playlists.
I am, however, open to any constructive feedback.
I fixed a display bug related to thumbnails and titles in this version; the
titles were showing the wrong information thanks to the nested playlists
being treated as a `Quick Menu` at the wrong time; the thumbnails did not
display correctly in all cases thanks to differences between menu drivers.
The functionality is identical to the original patch, but the names of certain
identifiers have changed to better reflect the standard set by upstream code.
The feature has been kept, mostly, small and isolated by simply reusing
existing code in a slightly different way than it is currently used.
A note about the feature request: the often requested feature has obvious
utility for people who create custom playlists; the feature could also be
used to generate flat playlists or nested playlists depending on a flag
in scanning; the optional nested playlists could be generated from
information contained within the databases allowing games for a given
system to be broken up by, for example, country of origin.
A note about the different menu drivers: an update from a few weeks back broke
part of my original private version; that update, related to thumbnail cycling
and the then new random selection feature, changed when thumbnails are displayed
for certain core types; this patch partially reverts that change to prepare for
a future additional feature I've begun working on which would allow people to
use RetroArch as more of a general media player with thumbnail generation using
the, often internal, `ffmpeg` core; the history and favorites menu should at
least offer the opportunity to display thumbnails, in any event, for custom
playlists which can have thumbnails for any media type.
I've included a sample playlist trunk below; the core's path and name are
important and fixed, but the path to the playlist may be set as desired.
{
"version": "1.5",
"default_core_path": "",
"default_core_name": "",
"label_display_mode": 0,
"right_thumbnail_mode": 0,
"left_thumbnail_mode": 0,
"thumbnail_match_mode": 0,
"sort_mode": 0,
"items": [
{
"path": "/home/username/temporary/branch.lpl",
"label": "Branch",
"core_path": "virtual",
"core_name": "playlist",
"crc32": "",
"db_name": "Trunk.lpl"
}
]
}
The feature may be tested by creating an entry within an existing playlist having a "core_path" of "virtual", "core_name" of "playlist", and "path" pointed to any existing playlist.
The feature works by reusing certain mechanisms, notably the generic RPL and COLLECTION processing, that were already in place.
I have though added a FILE_TYPE, MENU_ENUM_LABEL, DISPLAYLIST, and ACTION setup unique to the feature in order to avoid what I considered to be contamination; I wanted to avoid hacks that, while simpler, would have made the feature harder to debug separately from the existing code.
Add "Reset core options" menu to two more places:
- Manage Cores, where it can delete the options for the selected core
- Configuration, where it can delete the options for the loaded core
Current reset function is updated to delete the core options file if
reset is wanted for a specific core, or core was loaded but not yet
started. Meant as a recovery method for possibly fatal core option
changes.
* Less string copies
* Some general cleanups
* Add extra param to runloop_message_queue_push so we can pass size_t
of the message
* Consistent conventions for local variable usage for certain things
kaysedwards