Bug: Loop points not supported in ogg files.

[zaphod77]

This is supposed to work in sdl_mixer but i cannot get it to work at all.

The Ace another ex stage tunes loop to a point that's not the start of the file. i have wav versions with smpl chunks containing the loop points (converted from the xma files with xmaencode.exe, towave.exe ignores the loop points.), and ogg files, which are set to loop and have the extra data after the loop point removed to save space. they still jump back to the start during the loop instead of the loopstart marker. i can send the ogg files for testing if asked.

[zaphod77]

Okay i've figured out more. loop points do work, but only for Music, and only if they are error free. i've fixed the latter, but doubt you are willing to put back the "load these as music" haxx0rs.

This is getting fixed with the sdl mixer rewrite.

[nightmareci]

Okay i've figured out more. loop points do work, but only for Music, and only if they are error free. i've fixed the latter, but doubt you are willing to put back the "load these as music" haxx0rs.

This is getting fixed with the sdl mixer rewrite.

Yeah, I think we can get a "not garbage hack" solution once SDL3_mixer gets stable and we've migrated to SDL3, then close this issue. For now, on SDL2, this issue stays open.

But there is a more difficult option to close the issue while still on SDL2: Making our own audio system, building it directly with SDL2 low level audio APIs, no longer using SDL2_mixer. But I don't want to do that myself, so if anyone else wants to try, and it's not trash, I'd be up for taking the PR for that. It's feasible to do, since we have quite trivial audio system needs, not even needing the full functionality of SDL2_mixer. Basically, we just need mixing multiple audio streams together and adjustable volume, no need for any fancy effects. And, if someone built a new audio system, it could be ported to SDL3, so we could also migrate to SDL3 before SDL3_mixer is stable, perhaps never even using SDL3_mixer.

[zaphod77]

the only solution is putting back that horrible hack from before. I tried to make a simpler version of the hack that would be easy to revert when sdl_mixer got fixed, but just got frustrated due to more code weirdness that is fine with the current system. i might try ONE more time and see if i could get past the showstopper i ran into before.

[zaphod77]

Okay, so i wrote a new hack that's not as crazy as the old hack. here's how it works.

1. only loads the credits musics as wav, because those don't loop anyway. the other bgm loads do not happen at start anymore. i load those two as "wave", because there's no way in the source to mark a music as non looping yet.
2. inside YGS2kPlayWave , if no wave was actually loaded for that number, AND the number is 50 or greater, stop the music, load the correct BGM (using the correct extension), set it's volume to the bgmvolume, and start the music again. this is quick because loadmusic is streaming.
3. in YGS2kReplayWave, also resume the music. this is only ever called with -1, when game is unpaused.
4. in YGS2kStopWave, call YGS2kStopMusic() if it's a non credits bgm
5. in YGS2kPauseWave, also call YGS2kPauseMusic(). again, this i sonly ever called with -1 and when game is paused.
6. in YGS2kSetVolumeWave, call YGS2kSetVolumeMusic instead if it's a non credits BGM. This allows fading to keep working for bgms that are actually loaded as the music.
7. in YGS2kIsPlayWave, return YGS2kIsPlayMusic if it's actually a music number passed. this lets the program know a music is still playing, and stops some screens from retriggering constantly.
8. once a fade completes, actually stop the music so next time the game checks to see if a music is playing, it gets the right answer.
9. only start a fade at game over if a music is actually playing at the time. not checking for this was causing the name entry BGM to fade in mission mode, and this was driving me up the wall.
10. add a few more clears of fade level just in case, done while trying to track down what i fixed with #9. Not sur eif any of them are actually needed, but they don't hurt.

I have tested extensively, and this allows the program to load faster and ue less memory, and music seems to still work properly. and now the bgms actually loop to their loop points.

If this is acceptable coding, i will submit a pull request.

[nightmareci]

I'm not taking any special-cased hackery in the YGS2k side, so I'm not accepting such a solution; if there's any hard-coded number stuff on the YGS2k side, sorry, it's not getting in. We had that before, but I've stripped all that out, I don't want it happening again. The YGS2k APIs should be like SDL itself, as generic as possible without any Heboris-specific hard coding (but there's one unavoidable exception, the Raspberry Pi GPIO input support; that has some level of hard coding to line up with the Heboris game inputs). There doesn't seem to be any way to do it with SDL2_mixer I'd consider acceptable, only SDL3_mixer or another audio system, so this issue will remain open. The way I want it to work is the audio system should support all features for all sound numbers, not some special-cased behavior that only works on specific sound numbers.

But there's the possibility of completely reworking how audio works for the loop-point music; that means the music isn't used as "sound", but as "music", not some hacked-up fiction of the game side thinking it's a sound, but the YGS2k/SDL2 side using the SDL2_mixer music APIs, where looping can't be supported for all sound numbers. I might just work on that redesign myself, but I'd rather just wait for SDL3_mixer to be ready, so the original YGS2k audio functionality can be fully replicated.

But, since I want to dump the YGS2k layer in favor of directly using SDL in the game code, this issue could end up getting closed due to that redesign, since we'd no longer be restricted by the YGS2k APIs.

[zaphod77]

The restrictions are in SDL_Mixer's side, not YGS2k. One streamed audio can be loaded at once, and only the streamed audio supports loop points. Therefore all bgm must be loaded as the music to get to the loop points with sdl_mixer until the rewrite that lets stuff loaded to memory read the loop points.

The only actual restriction in the ygs2k code is that you can't store or change the loop mode for the music, which is why i had to load the two that don't loop with LoadWave. The SDL Music api instead has you specify if the music is supposed to loop or not when starting the song, and YGS2kPlayMusic doesn't take a parameter.

I'm not mad at all that this isn't considered acceptable. I just got sick of personally waiting for SDL_Mixer to fix this. And i implemented these hacks in a fashion that's extra easy to remove, so i could go "oh hey, sdl_mixer reads the loop points when using Mix_LoadWAV_RW now, i can undo this very easily."