This uses a lot more memory, but should make it smoother when playing heavily keysounded files. Many simulators do actually load all keysounds into memory before the game starts.
When there are too many (high-quality) keysounds, threaded buffering will cause all these files to be opened at the same time. These problems can occur:
- too many open files (and then crashes)
- out of thread slots (and then crashes)
Fixing this by never doing threaded buffering on keysounds (mark to be precached).
This should make it possible to build StepMania 5 on Mac OS X.
The catch is that it will only work with Snow Leopard and up, but I think this is better than nothing.
We can support PowerPC / 10.4-10.5 again when someone can make the old Xcode 3 project work.
- [NoteField] fix build warnings, and change the maximum number of displayed notes
after the receptor to 64.
- [Player] fix build warnings.
- [NotesLoaderSSC, NotesWriterSSC] The MSD file reader seems to treat # that comes
directly after : as new tag, and as many PMS and BMS files has keysounds which filename
starts with #, so it looks like this: #KEYSOUNDS:#bgm.wav,01.wav,02.wav,..
The MSD parser will see it as 2 different tags. So I added a backslash in front of the
# sign if it's at the start when saving and remove it when loading.
- [RageSoundReader_WAV] ADPCM now works very well and doesn't return error when
end of file is reached anymore.
- [Steps] Use BMS loader when loading the note data.
#WAV entry points to a file with invalid name, or points to
a nonexistant file, for example
#WAVAA NoSuchFile.wav
#00101:AA
In which case, the note will be assigned the first valid
keysound, instead of not being assigned keysound at all.
This is a very silly bug with a simple fix, but didn't
manage to fix it before SM5P4 comes out. Sorry for that.
it to 32. [we may need to fine-tune this number later, but now missed notes
no longer disappear on slow / stopped parts using speed/scroll segments]
Please note that this code might not work well with negative speeds/scrolls.
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.
a bit more about autokeysounds: when I add this RageSoundReader_Extend,
I'm not sure whether the "autokeysounds are delayed" bug will come back
or not. Someone on Windows please test it.
quite a simple fix, but the song now no longer stops scrolling
when there are no more auto keysounds to play, which is what I've
been trying to fix for a long time.
It's now possible to play BMS which the BGM track is a bit too short
that in previous versions, the notes stop scrolling because there's
nothing more to play and it's impossible to finish the level.
It's also now possible to play BMS file which does not have any
autokeysounds at all, and also it's now possible to edit BMS files
(but the editor is very un-intuitive, but at least you can now add
timing changes to songs loaded from BMS files, such as speed segments
and scroll segments [they will be saved as .ssc file by the way]).
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.
this prevents the crash caused by the asserion "No keysounds were loaded for the song %s!".
the song will load just fine in this case, but the notes will not scroll.
this only takes place when m_pSharedSound is NULL, which doesn't break when there's
background music but no autokeysounds.
on a related note,
the "notes don't scroll" problem also existed [before this commit] when there's no more
autokeysounds to play, in this case, the song stopped and the notes stopped scrolling.
and there's no way to get to the end of the song. can't figure out how to deal with this yet.
- handles BPM changes correctly
- songs should load faster
- auto-adjusts time signature changes (not sure how well will it perform.)
- add some code to differentiate between beat_single5 and popn_five, fixes bug 430
- also, bug 500 seems to be fixed after the rewrite, after some other attempts fail
what's not supported yet:
- #LNOBJ long note parsing
- #LNTYPE 2 long note parsing [http://nvyu.net/rdm/ex.php]
instead of the dummy one, because the keysounds are in the song.
Also recreate the intermediate data structure that is required by LoadFromBMSFile.
This fixes the wrong sound issue, but the code still looks messy.
As the BMS loader sorts the definitions by measure and channel, they are not sorted by time, so there are cases that this can happen:
#00103:7F
#00203:007F0000
#00208:01
#BPM01 63.5
In this case, the segment in the second line is parsed before the third line, and because of the BPM is the same as the segment before it (the first line), no BPM changes will be added, the segment in the third line will then set the BPM of the rest of the song, which is wrong. To fix this the BPM needs to be sorted.
if only "png" is used, then on some systems with other png versions (me), the linker
will link with to the wrong path (/usr/local/lib/libpng14.14.dylib in my case).
if you don't like the version number (I don't know so I put 1.5.1sm0.1) please change it
to something else, just keep it unique.
