A lot of people have run into the previous ~10MB limit and increasing it
to 100MB doesn't seem to break anything.
I left a limit in place, so that excessively large Stats.xml files on a
USB profile can't be used to make a cab run out of memory. (SM uses a
multiple of the memory that is required for the file on disk.)
A lot of people have run into the previous ~10MB limit and increasing it
to 100MB doesn't seem to break anything.
I left a limit in place, so that excessively large Stats.xml files on a
USB profile can't be used to make a cab run out of memory. (SM uses a
multiple of the memory that is required for the file on disk.)
This is a workaround to make the hyphen key usable in text entry
screens. It allows to add a hyphen to profile names and set a negative
offset in edit mode.
Technically backslash is also a typeable character, but it seems to be
less common names in user names and not necessary for typing negative
offsets.
Fwiw, in outfox P2/back is unbound.
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.
Martin Natano