Integrate the previously created frame time graph component
into iidxhook 1 to 8. iidxhook9 uses d3d9ex which still requires
a separate hook implementation for imgui.
Guard the feature with a switch as it might have some performance
impact and it’s something that is only required to be turned on
when needed.
A overlay window showing the a frame time graph with
the current frame time, ~10 seconds of history as well
as reference lines for the current avg. and a configurable
target frame time.
This is considered a debug tool to support in any efforts
that are related to understanding current frame times
of the games. More specifically this can be used to asses
impact of any bemanitools hooking to the game’s main
(render) loop.
For now, we focus on internal overlays for bemanitools
that hook into an existing d3d9 context. The current
abstraction is fairly thin and should be fine as a start.
Implementations are called “components” and hook
up with a single frame_update function to execute
and logic and drawing updates with imgui
Version 1.91.7 of the imgui library with the cimgui wrapper.
imgui allows us to easily create minimal and powerful UI for
use-cases like in-game overlays or separate tooling.
The additional wrappers cimgui_impl_dx9 and cimgui_impl_win32
were added to provide a full C linkage integration for the rest
of the code base.
Tweaks to the makefile were kept to a minimum but enable
compilation of C++ since imgui is C++ based.
Remark: At this point bemanitools itself is still to be kept a pure
C codebase. Due to the lack of proper module/library management
with the current build system in bemanitools 5, proper separation
of concerns and clean integration with external libraries isn’t
possible with reasonable effort.
Summary:
Test Plan:
An open source re-implementation of the “NvDisplayConfigLDJ"
tool with additional enhancements.
This can be used to tweak your nvidia GPU driver settings to
create custom display timings to address IIDX’s requirement
if expecting proper display timings. This can also be used for
any legacy IIDX versions that even expect very specific display
timings, e.g. 59.95 or 60.05 hz.
Furthermore, creating application profiles allows further tweaks
to important GPU settings such as the current performance mode
setting. This is crucial to ensure the GPU is not going into any
kind of power saving states which results in non-smooth
scrolling during gameplay and micro stuttering that cannot
be measured on application level.
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.
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.
