Wrapper/shim library to drive another ddrio in a dedicated
IO thread. Depending on the other ddrio backend used, this
can significantly improve performance while staying
compatible to the existing ddrio API interface
This turned out to be a good solution to solve performance
problems when running MAME with ddrio-p3io that is
(currently) implemented with synchronous IO calls that are
very costly: ~12 ms for a write over the ACIO protocol, ~4 ms
for a read using an IOCTL. As this already adds up to nearly
a full frame (60 fps) regarding latency, there isn't a lot
of time left to do other stuff in a synchronous update loop.
MAME's performance was unstable and dropped all the time below
100%. The result was a choppy gameplay experience.
Combining ddrio-async with ddrio-p3io, the combined backend
is able to drive inputs/outputs at a rate of ~250hz = ~4
updates per frame. This results in an average input latency
of ~4 ms which is as good as it can get with the p3io
hardware's performance limitations that I measured (see
the 4 ms for the IOCTL mentioned above).
This is more than good enough as as update frequency of
the 573 hardware is slightly less than that (I got told
something ~180 hz?).
tl;dr: Gameplay on MAME is great, smooth frame rate, IO feels
amazing and responsive.
By hooking CreateProcessA, we can adjust the commandline to
disable any rotation, which displays the error box at the correct
place on screen (no additional x/y adjustment is needed)
The NVRAM redirection was silently failing because the prop
delete/recreate pair didn't work. This just recreates the entire
config from scratch instead, which guarantees success every time.
By making the NVRAM type "fs", we also make it easier to debug
any issues that people may have.
Initial version that supports the most important
features to operate a DDR SD cabinet with all
inputs and outputs working.
Note that the individual sensor cycling modes are
currently broken. The driver will always set the
sensor read mode to all for now.
With the overhaul of commands, some helpers needed tweaks while
new ones were added to abstract p3io command details with a
common interface, e.g. dealing with the command length field.
Using a real DDR P3IO (Dragon PCB), the overall P3IO command
structures improved significantly. Added further notes about
unknown/unclear commands that were not derivable from the
DDR 18 game binary either.
Note that this module is also used by jubeat to some extend.
The initial design apparently assumed a greater overlap in
commands. This now seems less likely as many commands appear
to be DDR specific.
Refactoring/splitting this is a major effort that is not being
addressed here.
Output the full buffer and the buffer up to the
currently set position. Makes debugging a lot
easier if you know the position set is ok to
only look at the output up to there.
Otherwise, having the full view is also important
to check if data got truncated or checking for
odd looking "garbage" data.
Internally, this was already used but it lacked a clean
public interface to set different log levels from the outside.
Useful for various command line tooling to implement verbosity
levels, e.g. -v, -vv, -vvv
This adds edge cases to the existing logic that checks the
vertex UV values to fix stretched BG videos on 11 to 17
already.
However, 9 and 10 also show this issue on modern GPU
hardware though it does not appear on all BG videos but
only on videos from 1st to 3rd style songs.
This commit addresses that issue by adding the missing
checks to the existing logic. Additional refactoring of
configuration naming etc. to match the extended
functionality is included.
Replace the old module, re-use the configuration for now to
avoid introducing breaking changes in the configuration API.
This can be further cleaned up, once the monolithic
iidxhook-util/d3d9 module is further broken up.
This replaces the scaling feature of iidxhook-util/d3d9 as the
game engine changed significantly that the old one is incompatible.
Create a new module because the logic to implement a scaling
feature is very different now. This also avoids further cluttering
the already badly overloaded old module.
The new module is light weight and "plugable" on a hooking
level. Further modules will follow to de-clutter the
iidxhook-util/d3d9 module
Reads state of ddrio and updates vigem pads. Similar in vein to
viggem-sdvxio and vigem-iidxio
Useful for playing xinput related games with official hardware.
Second part to fixing the 10th style SQ-INIT error. This has
cross-impact on the kind of security data the game expects.
Therefore, we need to expose the IO board type and make it
configurable like the security data for the different game
versions.
More details explained in a dev journal entry to following
in one of the next commits.
This is one part of fixing the 10th style SQ-INIT boot error.
For some reason, 10th style calls the "second dongle slot"
which, according to the code, is expected to return the same data
as the first (black) dongle slot. Original ezusb/C02/D01 IO boards
do not have a second dongle round plug slot nor ever came with
a splitter cable. I checked original manuals of the C02 conversion
kit, E11 and ECO software upgrade kits. No white dongle nor
additional hardware for any other dongle than a black dongle.
