There was a bunch of code for handling guitar-specific input such as hammer-ons/pull-offs and strumming. Given that guitar was removed, and as far as I understand, will not be added back into SM5, it makes sense to remove code that had no other use.
determine the number of notes to display from any beat to any beat in
O(log n) [n = number of non-empty rows].
it might be used to determine the first displayed beat or last displayed
beat based on number of notes on screen (instead of fixed beats),
if this can be implemented properly, then notes will no longer disappear
or appear during a long slow scrolls/speeds [as long as the number of
notes to display is in our limit].
Scroll segments seem to cause the lag when there's a lot of segment
in the steps, say, 165. On my Mac, it drops the frame-rate down by about
30 FPS in the end.
This is because the way the the game tries to determine the exact position
of the note, it has to go through all the scroll segments from the
beginning until it finds the currently active scroll segment and keep
track of the beat to display instead.
And each frame, the game needs to determine the position for each note,
and also when figuring out the first beat and last beat to display. This
makes the game slow even with just 165 scroll segments.
The approach is that at every game update, we create an optimized data
structure that can calculate the displayed beat from real song beat
in O(log n) time. So in this approach we iterate through EVERY scroll
segments each frame instead of iterating through the scroll segments
for each note for each frame. This eliminates the lag on this side.
The data structure is recomputed each update because I assume that the
timing segments can change at any time, but not during draws.
A similar problem is: when using Cmods, GetElapsedTimeFromBeat()
is also called very often (say, for each note and also in FindFirst/Last
DisplayedBeat), we may as well have to make these queries faster for songs
that has hundreds of BPM changes or stops or delays to prevent the game
from lagging.
which returns the dispalyed position and timing (based on the timing display
switch in the editor), so less copy n paste in ArrowEffects and NoteField.
We introduced a new class, called "SongPosition", that replaces some instance variables in the GameState class. (GameState::m_Position).
Then, you also have it in PlayerState class which keeps track of the position based on their steps. (PlayerState::m_Position).
Fixing the build errors:
- GAMESTATE->m_fSomething should now be:
- GAMESTATE->m_Position.m_fSomething
- pPlayerState->m_Position.m_fSomething (or m_pPlayerState for some instance!)
Martin Natano