- replays now start each frame with the number of key events (8 bit
unsigned int, then key events) and the number of input events (16 bit
unsigned int, then the input events)
- this makes it possible to parse replay files without any core
loaded, and makes replays more portable if cores change their polling
strategies
- external tools can now parse replay files
- old (vsn 0) replays will still play back, but new (vsn 1) replays
will not play on old RA
- replay files grow faster now, with each input poll now taking 8
bytes instead of 2
If there are several variants of a controller, but their button
layout is exactly the same, allow alternative identifiers, e.g.:
input_device_alt1
input_vendor_id_alt3
input_product_id_alt9
* Massive reduction in heap space allocation, going from settings struct
264kb to 119Kb
* Use NAME_MAX_LENGTH for base paths/names, etc
* Use DIR_MAX_LENGTH for directory sizes
- add reserved device check against device display name as well
- selected device name matching in menu with or without vid:pid
- cosmetical change in test input file
For each player, 2 new options are added:
- a reservation type (no reservation, preferred, reserved)
- a reserved device name
When handling port - player assignments, reserved devices
will be assigned to the respective player port. If reservation
type is "reserved", no other device can take that port
automatically.
Reservation config option and matching function lifted from:
PatrickStankard https://github.com/libretro/RetroArch/pull/16269
Test joypad driver was extended for more tests.
Co-authored-by: Patrick Stankard <me@patrickstankard.com>
A rationale is given in the comments, but even a class 6 or class 10 SD card can handle reads and writes on the order of MB/s, which means a 4KB chunk size is just wasting time in syscalls. This could maybe be fixed with a buffering reader but I don't feel comfortable tweaking libretro-common's VFS to handle that. Instead, I thought it would be good to both remove an ifdef and increase the chunk size to 128KB. For cores with small states this will should make state saving virtually instantaneous, and for cores with large states it should be a 32x speedup.
Eric Warmenhoven