This one was missing and is the actual correct
version used for ddr-13. 2.13.04 was compatible,
thus far, but there isn't any guarantee that they
are actually 100% compatible (only konmai knows...).
* Improve psmap types, taken from a private
eamuse server backend which had more complete
mappings.
* Move psmap terminator to enum
* AVS error type: Supports improving
expressiveness of the API interface
* Add more property node related functions
Add more AVS file system related functions
These were previously missing and are required for
various file system related tasks such as iterating
directory trees, reading and writing files through
the AVS file system for the upcoming launcher
rework.
Note that the AVS API broke with some mode flags
after version 2.13.06.
Use this to share helpers or other extensions to the
original avs API across modules.
Start with including error codes to readable strings
to improve velocity on AVS API error analysis.
This has been a source of common error in the past.
It is known that most, or even all, games run into
various issues when not run with elevated privileges.
Apply a consistent style across all markdown documents.
Use mdformat (https://github.com/executablebooks/mdformat)
to achieve that. Improves maintainability and readability.
Using ddrhook1, this caused DDR X to crash on startup when the
P3io client sends the currently unknown command 2B. Handling it
with the incorrect p3io command struct, any following reading
attempts from the P3IO by the game fail.
Handle the 2B case explicitly with a generic response that worked
previously before the restructuring of the code. Apply the same
to any further unknown commands with improved logging warning
about this.
Buffers are allowed to have the exact size as the max defined
P3IO buffer size. Cutting it short by one byte causes this
to fail incorrectly when using the pure raw buffer structure
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.
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
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
Using the right combination of "flags", this addresses the
SQ-INIT error on 10th style as well as forces 10 to 13 into
using the D01 operation mode. The latter follows the approach that
14+ is also using the best/latest IO type supported (IO2 in that
case). Expecting that gameplay experience benefits from more
optimized/better maintained code paths.
Make 10 operate in D01 IO mode which forces security to using
the D01 dongle from a D01 dedicab setup. The alternative would
be using a C02 dongle from a C02 upgraded cabinet.
More details to follow in another commit with a dev journal
entry.
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.
The paths changed for 18 and again for 19. Refactor and improve
the detection logic to consider this. This also should make
the code more maintainable.
The synchronization block was too coarse and kept the lock
acquired even when the hooked call continued traversing because
it skipped the chart patch trap code. This was apparently fine
on several games but caused very flaky deadlocking on iidx18
during the boot screens and even crashed iidx19 consistently
before showing the boot screen.
Applies to iidx18 and iidx19 when using the recently extended
redirect feature for settings paths, mixing / and \ crashes the
game in some operator sub-menus when trying to save settings.
The fedora image was already quite old but also took ages to
initially install the dependencies. Being more familiar with debian,
initial container building with package installation being rather
quick, and assuming most folks being more familiar debian as well,
I decided to shift to make this easier to maintain.
- Use static assert to verify struct sizes
- Replace "magic numbers" with proper sizeof's
- Allocate largest size buffer for message response to address
compiler warnings which indicates potential out of bounds
reads/writes
This removes the need to copy all the data into the docker container
and outputs from the build process out of the container. In
hindsight, this was a poor design decision as it created docker
images that were very large with data, that you don't have to
keep stored once the build finished, e.g. the build output.
Therefore, mount the local folder, keep the checkouts also local
which is good for debugging and also re-using them to build without
the docker container (no second checkout required).
Build output is also written directly to the build/ output folder
Overall, the docker container is more lightweight and actually
a "build environment" only not tainted with specific versions
of the dependencies to build.
Provide an option for non final lincle revisions and
if the "modern" monitor check is not delivering stable
results on the final lincle revision, e.g. using the
original "pendual lcd" monitor.
icex2