* Handle commas and equals in BG/FG change tags
Rewrote parsing of BGCHANGES and FGCHANGES tags to be able to
handle people putting commas and equals in the filenames. For the
value positions which can be filenames, check to see if we can
recognize any filename from the song directory followed by a comma,
equal, or end of string. If we can, use that. If not, just treat it
the same as before, looking for the next comma or equal.
While loading all songs, disable writing the index file for the image
cache, in order to speed up loading and cache generation, similar to
how the song cache index file write is delayed.
Update VDI format to utilize 64-bit pointer types for stack tracing.
Revise mapconv and CrashHandlerChild.
Tested on both 32-bit and 64-bit builds to be working properly.
There is also a weird bit in here that seems like it should be
whether to use system or included libpng, but it actually does
the directx include dir on one side.
* Restore lost Stepmania Team credits
Back in 2009, an overhaul was made to the theme to replace the credits
screen. That new screen had a short list of credits, along with a note to
"remake this list". That never happened, and over time, the original credits
list was lost in the shuffle. People that worked on Stepmania in the past,
who felt their contributions were enough to warrant credit, should still
get credit.
This list was pulled directly from the git history under hash
fb1165e6be
It could probably be cleaned up a bit. (For instance, the theme has been
completely redone. Should we still include the Graphics and Theme sections?
Also, the web section. And the thanks section? Those are pretty much just
shoutouts.)
* Name change. Deal with it >8)
* Change encoding of restored credits to utf-8
The list used "fancy" quotes. I should have saved this at utf-8 to
begin with.
Also: Implement d3d9 screenshots without d3dx9
This only implements the two most likely surface formats. Does anybody
actually use 16-bit rendering anymore? (If yes, I'll do the slower path
through StretchRect to convert)
(backport from master, where it was two commits)
* Another thing lost was DXGetErrorString. Re-implement it.
* Include a partial list of errors.
(backported from master, where it was two commits)
Note: If we ever drop support for windows older than win8, we can
remove this and just call FormatMessage.
RageDisplay_D3D::CreateScreenshot will be returning nullptr until I get
around to re-implementing it without using d3dx, which is another thing that
did not make the move into the Windows SDK.
(backport from master)
From MSDN:
Security Remarks
If this function is called without FORMAT_MESSAGE_IGNORE_INSERTS, the
Arguments parameter must contain enough parameters to satisfy all insertion
sequences in the message string, and they must be of the correct type.
Therefore, do not use untrusted or unknown message strings with inserts
enabled because they can contain more insertion sequences than Arguments
provides, or those that may be of the wrong type. In particular, it is
unsafe to take an arbitrary system error code returned from an API and use
FORMAT_MESSAGE_FROM_SYSTEM without FORMAT_MESSAGE_IGNORE_INSERTS.
(backport from master)
One thing that did not make it into the move to the Windows SDK is the
dxguid.lib library, which defined the IIDs for all of the DirectX interfaces.
This replaces that, defining the ones we use. Currently, we only need to
define the DirectInput IIDs, so that is all that is here.
(backport from master)
Windows x64 functions always assume there is at least 4 QWORDs' length of space
reserved for register parameters (RCX, RDX, R8 and R9) after the caller return
address even though there are less than 4 parameters. MSVC compiler will try to
utilize vacant space there. If we forget to reserve that block, the exception
handler will abort.
Reference: https://docs.microsoft.com/en-us/cpp/build/stack-usage
MS is deprecating inline assembly, and has completely removed it from
the x64 compiler. The solution is to use compiler intrinsics. This will
hopefully make building for x64 easier in the future. (I might even
spend some time attempting to build it for x64).
Tracy Ward