StepMania 5.0.7 released

StepMania 5.0.7 has been released, with various changes to speed up loading and a few other features.
You can read the release notes on GitHub for more details, and the downloads are below the release notes.

Happy April Fools from the StepMania team!

This is amazing, thank you!

StepMania 5.0.7 had two minor bugs that have since been fixed:
1. Lifts were not counted correctly, resulting in scores over 100% on charts that use lifts.
2. A warp and a stop and a step all occurring at the same time sometimes makes the step unhittable.
The internal detail is that TimingData was sped up by creating a lookup table so that StepMania doesn't have to process the entire TimingData for the chart up to the current time several times every frame. Instead, the lookup table contains starting points for the processing to start at, so StepMania never has to go through more than 32 timing segments when calculating the current beat or elapsed time during gameplay. If a stop is the 32nd timing segment, and a warp is on the same row, and there's a step on that row, that step will be unhittable.

Since these bugs affect scoring, it's worth warning people about them, but since they're so rarely encountered, another rush release doesn't seem necessary. Report any other issues found so they can be fixed.

The next release will be May 10th. (Shakesoday)

With over 9000 songs and an 5400rpm hard drive to load them from, I must say I love the new loading times!

I have 15.5k songs, and a drive from 2011, so load time before March was ~550 seconds, 2000 seconds if I had to delete the cache. Now it's down to 60-70 seconds, and ~660 if the cache is deleted. So I figure that even if my collection size is an extreme outlier, and most people only see a 30 second difference, the time I spent combing over the loading code and rewriting parts of it has already paid for itself.

So how does per-chart #MUSIC tags work more specifically? Basically I can think of 3 scenarios:

-If I select a chart with per-difficulty music on single player, there's no adverse effect.
-If I select a chart with per-difficulty music with a second player, which music is played? Are they played on top of eachother? Does the higher difficulty take priority?
-If I select a chart with per-difficulty music with a second player are you forced to select the same difficulty together?


-----------------


Just wanted to say as an aside: HOLY SHIT the load times went from ~20 minutes to 2 minutes with 32K songs cached. (I'm riding the line for RAM usage in x32 applications around 1.3GB... 1.7GB crashes entirely). Is there any development hurdles to changing over to x64? (outside the fact that dedicab/upgrade hardware are not x64 compatible?)

Is there any development hurdles to changing over to x64? (outside the fact that dedicab/upgrade hardware are not x64 compatible?)
SM builds as 64-bit in 64-bit environments perfectly fine for most of the last decade, so if the machine is upgraded it'll be fine.

When one player changes the chart they have selected, the other player's current selection is checked for compatibility.
If either player is on a chart with a StyleType of TwoPlayers_SharedSides (routine), it's incompatible.
If the music files for the charts are different, they're incompatible.
After checking those two things, if the players are on incompatible charts, then the player that did not change their chart is forced to the same chart as the other player.

So P1 and P2 are on chart 1 which has music "crap". P1 changes to chart 2, which has music "crap_another". P2 is forced to change because the charts are incompatible.


Loading time is what I spent most of March on. Combing over every bit of code that occurs from the time the logging manager starts until the first screen comes up, and figuring out what could be done faster. This is as good as it's going to get until we write a new font system that makes font textures smaller to shave a few more seconds off.