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. :)
I moved a MESSAGEMAN:Broadcast() call so that it only broadcasts the setting that has been saved. This seems more sensible to me, but it is possible I'm misinterpreting the original design here.
Feel free to merge or not merge this commit. :)
As noted in my previous commit message, I think ThemePrefs.ForceSave() can safely be deprecated. Since many novice themers look to default when learning, I think it's better to use ThemePrefs.Save() as the system was originally designed.
I moved the ThemePrefs.Save() call out of ScreenTitleMenu decoration to ScreenOptionsService in. This seems safer to me; Pay/Freeplay never hit ScreenTitleMenu which could be another reason ThemePrefs would never get saved.
Additionally, moving the call to ScreenOptionsService in also seems to have fixed a bug where switching themes via the Appearance Options service menu would cause the new theme to inherit all of the previous theme's ini settings. I'm still not entirely sure why.
I've done a fair amount of testing with this.
I've tried deleting the ThemePrefs.ini file outright and booting fresh into both default and Simply Love. In both cases, the ThemePrefs.ini file is written when StepMania exits or when the user hit ScreenOptionsService, whichever comes first.
I've tried switching between various themes, including those that did not use ThemePrefs. I haven't seen any sections being created erroneously and themes that do use ThemePrefs don't seem to inherit the previous theme's settings any longer.
Still, it *very* possible that I've missed some edge case(s) and is probably worth a few people testing before merging.
The ThemePrefs table contains several functions and single standalone variable, NeedsSaving. When a themer calls ThemePrefs.Save() the system will check the status of NeedsSaved to determine whether it really needs to save or not. This is by design to prevent unnecessary writing to disk.
As far as I am able to discern, NeedsSaved would never be anything but false due to scoping within the ThemePrefs table. This commit properly scopes that variable as it used within the functions.
It looks like ThemePrefs.ForceSave() was added as a workaround; it didn't check the status of NeedsSaved and just always saved, "no matter what." Though it seems safe to outright remove ForceSave(), I'm leaving it in for compatibility. Consider it deprecated I suppose.
false is a perfectly valid setting for one of SM's ini files. The code here needs to ensure that both the key (string) and the value (string, numeric, boolean) read from file exist. It would previously halt if the value was set to false. This fixes that by explicitly checking for nil.
It is necessary to clear existing cmake cache and generate a new Xcode
project, following wolfman2000's instructions in ./Build/README.md
Witht that done, you can use the StepMania.xcodeproj generated by cmake
to successfully build a fresh StepMania.app and it properly logs the OS
X version.
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
ProductInfo.h used to contain both Family and Version information. This is no longer the case.
Family (StepMania) is now grabbed out of ProductInfo.h, and
Version (5.0.x) is now grabbed out of ver.h
This commit adds a preference, DebounceCoinInputTime (defaults is 0), which allows coin input to be debounced via a float value separate from other input.
This commit exposes InsertCoin() and InsertCredit() to Lua under GAMESTATE. It adds a check to ensure overall credits don't become negative when deducting and only plays sounds if credits are being added.
Themers are instructed to deduct credits by passing negative values to InsertCoin.
This commit does a few things:
1. includes a new mkrelease script for OS X devs to bundle releases with
2. removes the old Perl scripts that sort of accomplished the same task
3. includes a README documenting how to use the new script
The old scripts were brittle and inefficient.
The new script is written in Ruby because it is what I'm familiar with and because OS X has shipped with Ruby since version 10.5.0.
This commit does a few things:
1. includes a new mkrelease script for OS X devs to bundle releases with
2. removes the old Perl scripts that sort of accomplished the same task
3. includes a README documenting how to use the new script
The old scripts were brittle and inefficient.
The new script is written in Ruby because it is what I'm familiar with and because OS X has shipped with Ruby since version 10.5.0.
This allows themers to make use of SelectMenuInputMessageCommand even
if they have SelectMenuChangesDifficulty set to true in their Metrics.
Neither _fallback nor Default use SelectMenuInputMessageCommand and,
for that matter, no theme I'm aware of does (perhaps because it's
essentially inaccessible as it is).
I use this to detect if a player presses START while holding SELECT on
SSM. This is possible with the existing code system, but that
CodeMessage does not fire until the player lets go of both buttons.
This allows the themer to check for that button combination more imm
ediately.
Dan Guzek