* Ensure all switches have a default when working with enums.
* Match defined new[] calls with delete[] calls.
* Respect variable initialization order.
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.
Previously, the PIUIO_Leds code logged every LightState of every PIUIO_Led light with every call of Set()
This commit adds checks to see if each of the PIUIO_Leds have changed LightState since the last Set() and skips logging the current LightState if there is no change. Each set of lights was already being looped through; the new code here just issues a continue to skip logging where possible.
This helps reduce CPU usage when PIUIO_Leds are in use as the LightsDriver.
This commit allows OS X users to enjoy their current theme's custom splash graphic if it is available at ./Graphics/Common splash.png
I have been wanting to fix this for a fairly long time.
My fix is probably not the cleanest or proper way to do this. StepMania.cpp already looks up the current theme's "Common splash.png" and passes it off to the arch-appropriate LoadingWindow as a RageSurface. This fix repeats the lookup in LoadingWindow_MacOSX.mm, and loads the splash image into a Ragefile which is easily loaded into an NSImage.
Still, my fix does work, and if you actually know how to work with a Ragesurface and can help out here, I'll give you a cookie. :)
On my Fedora 20 system, closedir apparently frees the dirent, and
reading it afterwards returns garbage data. This prevented my dance pad
from being detected.
There was code in place to log the OS X kernel version (14.1.0, for
example) to log, but it stopped working some time ago. "Mac OS X
unknown." has been logged for the last several releases.
This commit swaps out that C++ code for a some Obj-C which logs the OS
X release version (10.10.2, for example) correctly. In order to mix
Obj-C with an otherwise C++ file, I changed the file extension from .cpp
to .mm to make it Objective-C++.
At the suggestion of wolfman2000, I have updated
src/CMakeData-arch.cmake to reflect the changes in this commit; that
will follow in the next commit from me.
As of commit dd0896d3eb, a "StepMania 5" directory is searched for at ~/Desktop and created if one is not found. It doesn't seem that directory is ever used in any way, however, causing confusion and annoyance for OS X users.
See: http://www.stepmania.com/forums/general-questions/show/1893
sync_volume_np was introduced in the 10.8 SDK. This commit ensures that
some related constants are defined before calling the function. If they
are not, we fallback to the older logic.
The Yosemite crash happens when we call CFRunLoopAddObserver. It doesn't seem to like runLoopRef. Replacing the first argument to this call with CFRunLoopGetCurrent() avoids the crash, but the app then hangs because CFRunLoopWakeUp doesn't cause observerRef (NameHALThread) to fire, so the semaphore is not posted. Commenting the semaphore wait line allows the game to boot in Yosemite, and seems to play totally normally. This doesn't really fix our problem (we are trying to name the HAL thread, and a catastrophic error occurs), but it shows us what the problem is.
We are obtaining runLoopRef using an API call that was deprecated years ago. However, the Apple-approved replacement code doesn't produce a runLoopRef that avoids the crash, either. So I'm not sure how we get the correct runLoopRef so we can name the thread.
This is my first time looking at the code base, but I don't see the value of naming the thread. In the interest of keeping Stepmania compatible with the upcoming operating system, I propose we just remove the thread-naming logic.
The mappings in this driver are specific to the piuio kernel driver, but
once lights mapping is possible this could be made into a generic leds
class driver.
Old code would, by coincidence, map 1->16 to 1->16, then 17->32 to
1->32, leaving 1 and 17 on the same button number.
We still map 33->56 to 1->24, creating some overlap. But at least that's
because StepMania will have run out of buttons.
THIS PATCH WILL CHANGE THE CODES OF JOYSTICK BUTTONS 17 AND UP.
Kyzentun Keeslala