Previously the function stopped short on nul bytes ("\0") due to usage
of the SArg() macro, which does not retrieve the length of the lua
string.
before the fix: `BinaryToHex("a\0b")` -> `"61"`
after the fix: `BinaryToHex("a\0b")` -> `"610062"`
Both the slash key and the numpad slash key were displayed as 'Key /',
so it's not obvious to the user which key actually has been bound. Let's
display them as 'Key /' and 'KP /' instead. Same for other KP keys.
Before, if the PacDrive32.dll provided by Ultimarc wasn't found,
stepmania would attempt to write to the Pac-Drive anyway, resulting in a
call on a null pointer.
This adds a quick check against PacDriveConnected during the update, and
checks if the pacdrive functions exist before calling them.
I will say, the version of this that didn't have break statements had
way, way more flashy light patterns than the boring, correctly
functioning version of this.
Also, the preference now defaults to "minimaid"
The currently proposed light ordering presents a problem for those who have bought a LumenAR or have followed the OpenITG standard for wiring lights. With this change, the default ordering stays the same, but users have the option to define "openitg" or "lumenar" as their preferred light ordering in Preferences.ini under the newly defined "PacDriveLightOrdering" preference.
This adds Lua hooks to CryptManager for libtomcrypt's SHA256 hash
function. It follows along with the C++ patterns Glenn wrote a decade
and a half ago for CryptMananger's MD5 and SHA1 hooks.
StepMania's CMakeProject-tomcrypt file has been updated to build with
sha256 symbols. Invoking cmake to build with system tomcrypt works fine
as-is.
Note that these functions return binary formatted strings, but themers
can convert to hexadecimal format using the global Lua function
BinaryToHex().
The hashing functions that CryptManger currently exposes to Lua
return hash strings formatted in binary. Themes using those hash
functions may want to compare hex strings.
RageUtil already had a BinaryToHex utility; this commit exposes it
as a global function, following along with other utility functions
in RageUtil.
Silence the following warning message:
src/NotesWriterSM.cpp:260:11: warning: control reaches end of non-void function [-Wreturn-type]
This warning had meaningful implications for some reason.
When I compiled the current version with stack protector enabled,
GCC optimized out successful return from the function, and encouraged
undefined behavior far less intuitive than an unspecified value.
Whenever saving a steps file on a -DCMAKE_BUILD_TYPE=Release build,
the game printed a message about stack protection violation,
and aborted itself, even though no violation took place.
GCC version:
gcc (Gentoo 10.2.0 p1) 10.2.0
this isn't actually a good solution, really RageVColor shouldn't be
doing this conversion at all and should be refactored/removed.
this gets gameplay running a bit smoother, much closer to holding 60fps
Game runs pretty close to fine, needed to use system libpng and haven't
attempted to use ffmpeg, however.
I'm seeing in the 50fps range in gameplay with no performance tweaks
but having set -mtune=cortex-a72. There's a lot of perf opportunities,
so consistent 60 is certainly within reason without too much pain.
If the supposed return address is a pointer to the beginning of an
executable page, and the page before is an oversized file mapping,
like vvar before vdso, the backtrace would be terminated by SIGBUS.
To avoid this, check not for readable, but for executable instead.
C:\Repos\StepMania\src\Grade.cpp(56): error C2440: 'type cast': cannot convert from 'double' to 'Grade' [C:\Repos\StepMania\Build\src\StepMania.vcxproj]
C:\Repos\StepMania\src\Grade.cpp(56): note: Conversions between enumeration and floating point values are no longer allowed
Martin Natano