Reply 180 of 183, by Qbix
- Rank
- DOSBox Author
Thanks!
Water flows down the stream
How to ask questions the smart way!
Thanks!
Water flows down the stream
How to ask questions the smart way!
Kisai, if you could get a somehow cleaner patch working, I'd be very grateful 😀
Dominus wrote on 2020-11-16, 09:02:Kisai, if you could get a somehow cleaner patch working, I'd be very grateful 😀
Attached (you may want to clean it up a bit more, as this is from my working source)
I've noticed that the SDL2.0.13+ Mercurial is broken and have reverted the binary attached to 2.0.12
In 2.0.10 and 2.0.12, it does not spontaneously break the events. The problem appears to be directly in SDL2 as I did all sorts of things to the event polling to try and fix it and nothing fixes it, the event's just stop after 2.0.12 for some amount of time and will then restart unless a debugger is attached in which case the debugger won't trip it, which makes it hard to figure out what SDL2 is stalling on.
I've included all the source code from my working source. If you've previously used the SDL2 patch in this thread, you should already have the src\sdl_cdrom\* files. If you've previously used the munt patch, the file will already exist, but it touches dosbox.cpp (self-contained). If you've previously used the fluidsynth patch, the files should already exist, it touches dosbox.cpp, but is also self-contained. The patch files are against individual files changed in r4392 and do not generate these other files.
I'm sorry in advance that it's a bit of a mess. I usually just checkout the SVN version, apply munt, fluidsynth and SDL2 and don't really add much after that other than nukedopl. Because almost a year passed in between the last time I did this, the SVN version changed significantly, so that I had to manually follow the SDL2 patch earlier in this thread to make sure it patched what I expected it to patch.
Whee! Thanks that gives me a starting point. As I've now cleaned up my macOS build scripts I can take this on again