- Remove checking for standard functions from the build system
- Prefix all invocations with std::
- Replace suffixed functions with unprefixed versions
- Include <cmath> in all files that use it and remove the global include
e.g. floorf(x) -> std::floor(x)
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.
* 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.
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
* Use XRandR 1.2 to set fullscreen resolution for single output
Squash of roothorick's PR #497
(also includes Kyzentun's CMake changes from PR #716)
* Cherry-pick json c++1x stuff (b9e3d7174e)
* Cherry-pick c++11 support from 5bba5c0038 and 9f8b045309
* rework Linux (X11) fullscreen, improve display-related Graphics Options
Implement option to select between monitors for exclusive fullscreen mode
on X11 (using XRandR 1.2), or use a fullscreen borderless window.
Reimplement resolution/refresh rate/display mode-related option rows
using Lua, update choices dynamically so only known-good groupings of
resolution/refresh rate/aspect ratio can be selected.
Minimally update Windows/MacOS LowLevelWindow implementations to support
changes made for Linux side. Fullscreen Borderless Window/multi monitor
support from X11 not implemented for those in this commit.
* allow forcibly disabling xinerama use on Linux
When libXinerama is available, SM tries to use it to find the proper
monitor indexes to use to set _NET_WM_FULLSCREEN_MONITORS (on borderless
fullscreen). xfwm4 seems to assume that monitors are numbered in increasing
order from left to right (rather than using the Xinerama-assigned numbers),
so _NET_WM_FULLSCREEN_MONITORS misbehaves on Xfce.
This commit bypasses use of libXinerama, and instead forces SM to induce fullscreen
on the desired monitor in the backup, hacky way: remove all window hints, move window
to desired monitor, then add _NET_WM_STATE_FULLSCREEN hint. This works on
mutter and Xfce.
* Remove multiple warnings on redundant define.
This used to be hard-coded due to pthread related items, but now it's dynamically determined.
* fix _fallback menu behavior for unrecognized aspect ratios
* Fix error recreating existing FS texture
* Bump deployment target to 10.7 to use libc++ on XCode 8
* Add explicit casts to please clang
* Update changelog
There is no need for an extra program.
As a bonus, generate a consistent windows vdi file.
There is still an issue with actually *reading* the vdi, but that's for someone else to tackle.
The biggest obstacle right now deals with FFMPEG. I insist on being able to utilize the git clone/submodule (5_1_0) section. I'm just struggling with the commands.
As part of this commit, some linux files are restored in the compilation chain. This is for consistency with the old Makefile approach.
Assistance will be needed at this point to complete MinGW support.
This attempts to organize all needed items and places appropriate defines
in a single location. Redundant comparisons/defines were removed when noticed.
A few caveats, however:
* This may be better targeted towards the 5_1_0 branch instead of master right now.
* Cmake will run a little slower on configuration/generation now. That's due to the sanity checks it runs.
* There are some more checks to be added later, but this should be a solid start.
Thanks to the [libical](https://github.com/libical/libical) project for inspiration.
tl-dr: view the Build directory to see.
This is intended to replace the project files that we presently maintain
so that only a single set is needed instead of multiples.
The following setups were used for testing:
* Windows 8 and Visual Studio 2013 Desktop Express
* Windows 7 and Visual Studio 2012
* Mac OS X Mavericks and Xcode
* Ubuntu and makefiles
* Fedora 21 and makefiles
All three operating systems can generate projects, compile, link, and
run. Windows and Mac OS X users will find their compiled binary in the
same location as before, but Linux users will be surprised: it goes
straight into the root directory, along with a symlinked GtkModules.so
as appropriate. There is no more need for a manual symlinking step.
Known issues:
* At this time, MinGW likely does not work. Extra time will be needed.
* The WITH_JPEG option may go away, and we'll just always require it.
* Some linux libraries can use the system equivalents, but that is not up yet.
For more information, check out the Build directory.
