krcroft wrote:Excellent! I will be happy to progress this patch on a branch. I work in git and use gitlab, but happy to push to github.
I split projects between GitHub and GitLab, depending on several factors - in this case, I think GitHub will attract more interest (and hopefully collaborators - e.g. through easy cross-linking issues to DOSBox-X and duganchen). Also, GitLab CI does not offer Windows builds in the free plan, while GitHub Actions do (and I am quite sure Travis can be set up for Windows builds as well). I develop on Linux and have no way of testing on Windows, so from my POV, Windows-capable CI is needed for this project.
krcroft wrote:Besides the usual push - pull model, does github allow multiple people to work within a repo, such that other developers (like myself) could be given ownership at the branch-level, directly in your repo?
Yes 😀 In the past I only prepared such rules for Gerrit hosting, but just glancing through GitHub documentation indicates that it's possible to set up rules per-branch (or branch group). I will dig in to learn how to properly set this up and ping you when ready.
krcroft wrote:Let me know if I can narrow this down; feel free to PM too if that's working for you.
In this case, I think game distribution is at fault - .cue file was not prepared by me, but by someone uploading the game to Steam (I suspect GOG version might be affected as well). I attached the file, so you could inspect it (it has extension .DAT, I added .txt so forum would allow upload; yes, the formatting is broken) - you will notice that File 02 is marked as Track 02 and Index 02, File 03 - Track 03 - Index 03, etc. This lead cue parser to decide that File 10 is next to File 01 and sanity check (`prev.number + 1 != curr.number` in AddTrack function) indicated an error during imgmount. Replacing Indexes for all Tracks to be Index 01 (following .cue files from other games) prevented this from happening. Perhaps .cue parser could be less strict to work around such issues? DOSBox 0.74-3 simply continues here (but music is not playing - although it's more likely to be SDL_sound issue).
Otherwise, earlier today I hacked together your patch with a slightly modified version of SDL2 from other thread (sans Android support) and got nicely working build of DOSBox r4258+SDL2+working music (tested several games using ogg and mp3) 😀 I will need to clean it up and split into small patches, that could be reviewed and (hopefully), some of them included in SVN.
One more thing, that I discovered just yesterday - Ryan actually started work on SDL2_sound, but it hasn't reached releasable state (and there's no guarantee it will) - new version is covered by zlib license, co can be included with DOSBox code, just like your patch does it.
| ← Ceci n'est pas une pipe
dosbox-staging