After commit 51ca73cb, using a non-blocking socket (e.g. poll(..., timeout=0)) will still result in a blocking socket.
It appears the above commit inverted the behavior.
This merge request fixes the blocking flag: blocking will be set to false when the flag is 0x800.
* Fixed an issue where games would boot loop because of an incorrect HID state.
* Turns out the SamplingNumber of the atomic input storage doesn't match the SamplingNumber of the input state held by the atomic storage, instead it is exactly double the value in the input state.
* Added new Condition struct to the HID Shared memory and populate it with dummy data to fix the no-controller crash (already merged).
* The audio renderer has been mostly updated to rev15, allowing rev15 games to launch.
* Biquad filters now use floats.
* Several structures have been renamed to match the SDK names, making it easier to compare functionality. A few names are still missing and will be changed at a later date.
* The new commands from rev15 have been added to the CommandType enum, but they are still missing from the code itself.
* Due to changes in the SDK layout, the time estimation functions are either missing or very well hidden (or Ghidra search functionality is useless). We can't fully implement the new commands until the timing data has been located.
* A few minor tweaks to the code have been made to more accurately match the SDK.
Adds an additional application list sorting method for the TitleID. A
bit of a niche choice for sorting but I think the TID is a relevant
enough piece of metadata that it should be there. (And I personally
would be using it)
- Using existing TitleId constant in ApplicationSort, implying this was
meant to be in the sorting options at some point?
- Reuses the "DlcManagerTableHeadingTitleIdLabel" locale for fulfilling
the need already, might be better to make a unique one for this in the
long run but this codebase is new to me so I wanted to make the changes
as unobtrusive as possible
- Using app.Id for the comparer seems to work fine, not sure if using
something else like IdString would be better?
Single L/R Joycons default to unbound for the SL/SR inputs - so by default you can't progress past 'press L + R to continue' type screens.
But
* ConfigGamepadInputId.SingleLeftTrigger0(L)
* ConfigGamepadInputId.SingleRightTrigger0(L)
* ConfigGamepadInputId.SingleLeftTrigger1(R)
* ConfigGamepadInputId.SingleRightTrigger1(R)
already exist (and I verified these are the inputs triggered by the SL/SR buttons), so my change would default to these instead.
A few more internal changes to the RangeList systems.
* No longer using a QuickAccess dictionary.
* The performance of the dictionary wasn't much faster than just doing binary searches.
* Using just binary searches allows us to take advantage of span and array returns as they're are faster than linked lists when iterating or copying the overlaps.
Small code optimizations.
Fixes a few leftover crashes.
* Slightly refactors RangeLists from the last Memory Changes MR, which fixes issue 61.
* Convert as many const size array iterators to span iterators as possible. When iterating over a const size array, every iteration created a Span, now only the first iteration does in most places.
* Now using object pooling for a few object types that were rapidly deleted and recreated.
* Converted a few flag checks to binary operations to save memory allocations.
* Refactors the RangeList and derivative classes used for handling lists of regions
* The Binary searches are now more performant, relying on edge searches instead of just returning the first matching hit and manually iterating until the edge is found
* Most look-ups now return a RangeItem, which acts as a linked list node now, instead where possible, moving away from Array copies. This should help with some specific lag spikes.
* Made IntrusiveRedBlackTreeNodes act like linked list nodes too to improve the lookup time of minimums, maximums and successors.
* Changed a few cases of HasFlag() into binary operations to save on memory allocations.
In general, [these changes] should increase frame time stability and lag spikes, but at the cost of some overhead to memory look-ups, the result being a very slightly better average fps from my testing (~1-2%).
