5 Commits
Author SHA1 Message Date
LibretroAdmin cd479dcbb9 VideoCommon: log, alert and build names in printf terms
Every VideoCommon message goes through the printf log and alert macros,
PRIM_LOG included; a register field or an enum in a message is printed
as its number.

The names built along the way no longer go through fmt:
- a texture's name parts (its size, hashes and format) are formatted
  into buffers on the stack, and the wildcard names concatenated;
- an EFB or XFB copy's name and dump path are made by one helper, from
  an id formatted on the stack;
- dump paths, graphics mod paths and group names are concatenated;
- the projection lookup key is formatted on the stack, on the heap only
  when a name runs past it, as before;
- the format overlay draws TextureFormatName, a constant string.

The no-op LOG_NORM and LOG_VTX macros, commented out since they were
added, are gone. The register formatters in the headers stay until the
assertions move over.
2026-11-11 20:46:56 +01:00
LibretroAdmin d87659dbcb Externals: remove watcher, and live reload of custom textures
watcher ran a thread per watched directory (the texture pack's, the
graphics mods') so that a texture file changed on disk while a game
ran was loaded again; on Windows its backend throws, so its file was
the one built with exceptions. A texture pack or mod is now read as the
game starts, and a change to it is seen at the next start.

With it go Common::FilesystemWatcher, the library's map from file to
asset kept only to answer the watcher, and the asset cache's dirty
asset queue that only the watcher filled.
2026-11-11 09:04:28 +01:00
LibretroAdmin f7d5095739 Core, InputCommon, VideoCommon: remove the remaining locks
Every std::mutex, lock_guard, unique_lock, scoped_lock,
condition_variable, call_once and semaphore left in Source/Core is
replaced by a lock-free design:

- Input: the device list, control bindings, stick calibration and
  default device are published snapshots read under a quiesce; a
  rebind requested while another thread is rebinding is handed to
  that thread instead of waited for.
- WiimoteReal: the pool thread owns the slots and runs commands from
  an MPSC queue; the active Wiimotes are atomic slots.
- EXI/SI/IOS devices: socket and packet traffic goes through SPSC
  rings or MPSC handoffs owned by one thread; USB scanning publishes
  its device list, and libusb transfers drain through a CallGate.
- Memory cards: the flush thread applies change records queued by
  the CPU thread.
- Custom assets: loads are scheduled as a published batch with an
  atomic cursor, results come back over an MPSC stack, and busy
  assets are skipped and retried.
- D3D state and GL program caches use insert-only atomic maps
  (Common/AtomicHashMap.h).
- Logging appends with O_APPEND / FILE_APPEND_DATA; FatFs reports
  busy instead of waiting; per-socket WSAStartup/WSACleanup.

Deleted as unused by the libretro core: the profiler, the FIFO
recorder, the volume verifier, the touch InputOverrider and the
GameCube adapter's libusb path.
2026-11-05 20:11:31 +01:00
Martino Fontana a14c88ba67 Remove unused imports
Yellow squiggly lines begone!
Done automatically on .cpp files through `run-clang-tidy`, with manual corrections to the mistakes.
If an import is directly used, but is technically unnecessary since it's recursively imported by something else, it is *not* removed.
The tool doesn't touch .h files, so I did some of them by hand while fixing errors due to old recursive imports.
Not everything is removed, but the cleanup should be substantial enough.
Because this done on Linux, code that isn't used on it is mostly untouched.
(Hopefully no open PR is depending on these imports...)
2026-01-25 16:12:15 +01:00
iwubcode 2d21a99205 VideoCommon: separate the concept of a 'resource' from an 'asset'. A resource is potentially multiple assets that are chained together but represent one type of data to the rest of the system. An example is a 'material'. A 'material' is a collection of textures, a custom shader, and some metadata that all comes together to form what the concept of the material is. There will be a 'material' resource. For now, start small by introducing the interface and change our texture loading which used assets from the old resource manager, to an actual resource. 2025-11-23 11:04:24 -06:00