Apply a simple heuristic to provide the user with more
specific information regarding which vcredist package
might not have been found on their system.
This is a common problem as different games require
different versions and different versions of windows
and installations might already come with some versions
already pre-installed.
Also improve the readme regarding that and provide links
to all versions that are required by one game or another
today.
Because we are using mingw, we can't just use window's
dbghelp library as the symbols created are in dwarf format.
Fortunately, the dwarfstack library already provides all the
facilities to easily print very descriptive stacktraces,
including function names, file names and line numbers,
when dwarf symbols are available.
This moves the incomplete exception handling portion from
signal to a separate module as well to improve scoping.
Kudos to Shiz for providing the groundwork for this.
Fundamentally re-think how launcher operates and
bootstrapping the games is managed and configured.
This brings it significantly closer to how the original
bootstrap is doing the job: launcher now utilizes the
data (structures) provided by the bootstrap.xml configuration
file. This creates compatibility with vanilla data dumps
and original stock images. Note that bemanitools does not
include any code or means to run DRM'd data, only decrypted.
But, this allows users to keep decrypted dumps as stock as
possible which means:
* No copying around of property files anymore
* Keep the modules/ folder with the binaries
* Have bemanitools binaries separate in the data
* No need to edit/customize the original configuration files
A list of key features of the "new" launcher:
* Boostrap games by following the configuration provided by
stock game's bootstrap.xml files
* Custom launcher.xml configuration file that adds further
launcher configurable features, composability of
bootstrap.xml configuration(s) as well as configuration
overriding/stacking of selected types of configurations,
e.g. eamuse config, avs-config. The latter eliminates
the need for modifying stock config files in the prop/
folder
* Unified logging system: launcher and AVS logging uses
the same logger, all output can now be in a single file
* Original features such as various hook types still
available
Due to the significant architectural changes, this also
breaks with any backwards compatibility to existing
launcher setups. Thus, users need to migrate by re-applying
the new configuration format and migrating their config
parameters accordingly.
Further migration instructions and updated documentation
will be provided upon release.
Co-authored-by: Shiz <hi@shiz.me>
Keep this a separate commit because this also removes
inject's own logging engine and replaces it with the
streamlined core API. The core API provides all the
features of inject's own logging engine which also
performed horribly. The entire logging operation
was locked which included expensive operations
that formatted the log messages and required
memory allocations and copying around data.
The core API's implementation at least only
synchronizes the actual IO operations
(though this can be improved further with an
actual async logging sink, TBD)
The log API stopped scaling already a while ago and needs
considerable refactoring to consider the various use-cases
that emerged since it was first created on alpha versions
of bemanitools.
Boils down to:
- Include headers
- Reduce boiler plate with helpers
- Swap out explicit usages with core API layer
and ensure the right API is configured beforehand
This module contains the "core" (API) of
bemanitools which includes an abstraction
layer for threads and logging at this time.
The threads API is very close to what
util/thread already was with some structural
enhancements which make it easier to understand
and work with the API, I hope. Some additional
helpers (*-ext module) support in doing common
tasks, e.g. setting up the thread API with other
modules.
The log(ging) part receives a major overhaul to
address known limitations and issues with the
util/log module:
- Cleaner API layer
- Separate sinks from actual logging engine
- Sinks are composable
- Improved and cleaner compatibility layer
with AVS logging API
Additional "extensions" (*-ext modules) add
various helper functions for common tasks like
setting up the logging engine with a file and stdout
sink.
The sinks also improved significantly with the file
sink now supporting proper appending and log rotation.
Logging to stdout/stderr supports coloring of log
messages which works across logging engines.
Overall, this refactored foundation is expected to
support future developments and removes known
limitations at the current scale of bemanitools such as:
- Reducing boiler plate code across hooks
- Interop of bemanitools and AVS (and setting the foundation
for addressing currently missing interop, e.g. for
dealing with property structures without AVS)
- Addressing performance issues in the logging engine
due to incorrect interop with AVS
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.
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.
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.
