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
These elements are normally automatically updated when a new Lua.xml is
generated using the --ExportLuaInformation command line argument, but
I've manually updated them here. It works for now.
Running --ExportLuaInformation will generate a new Lua.xml file with
everything available to Lua, including some repetitively-named functions
ported from notitg that were manually condensed down within Lua.xml.
We want to keep these condensed parts, so ExportLuaInformation should
probably be fixed/replaced in the future.
These "grouping"s aren't part of the spec in Docs/Luadoc/Lua.xsd, so
they won't appear when Lua.xml is viewed in a web browser, but can still
be used by external API doc applications until ExportLuaInformation is
improved.
Fix, clarify, and expand prose in LuaDocumentation.xml for classes made
available to Lua.
Add elements for DeviceList, InputList, Quad, and SongMeterDisplay to
Lua.xml.
Expand and clarify the prose for many gloabl Lua functions described in
in LuaDocumentation.xml.
Get Lua.xml's GlobalFunctions listing current with 5_1-new. Remove old
global functions (those moved to 5.1's "legacy" theme) from Lua.xml.
MDN's web docs describe the "HTML <pre> elements represents preformatted
text which is to be presented exactly as written in the HTML file."
It's handy for formatting multiline code examples in
LuaDocumentation.xml.
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.
* Replace libpng submodule with source
Taken from 505e70834d35383537b6491e7ae8641f1a4bed1876dbfe361201fc80868d88ca libpng-1.6.37.tar.xz
* Remove submodule-related config from CI
FMS-Cat