Use the SR framework for binary recompilation and SDL support about max

[klei1984]

SR seems to be an amazing project and if I would have found it half a year ago I probably would have considered to use it one way or another instead of improving le_disasm.
The approach to create LLVM intermediate object files via a custom assembler to theoretically be able to support basically any target that LLVM supports is amazing. My technical skills are far far below that level so for me to understand the tool, or even to help further develop it if MAX would need that, would require a very steep learning curve. For me even le_disasm was a huge leap.

On the other hand based on the manually reimplemented game specific code I seen in SR I see some major differences in the vision of SR and MAX Port. Based on Albion my understanding is that in case of DOS games SR's author stands closer to dosbox and emulation. The reimplemented code mimics interrupts, direct port manipulation and DPMI services on a low level layer basically simulating a DOS environment. The author does all this using SDL's eventing system which is again amazing, I would not be able to do this as I lack the skills and the experience, and as the low level layers are quasi standard among DOS games this approach allows a high level of reusability in the next games that will be supported by the framework. The actual game code is typically not required to be changed either as DOS is being abstracted away. But this also means that the low level emulation does not modernize the architecture much. Of course the same way as SR does low level porting it could do high level porting, but then the process of converting DOS games is not a streamlined process any more. One still needs to get an understanding of the game logic itself which is the major part of the work if you know SDL - I am still learning that too. The audio aspect is an example where I can see that SR takes the high level abstraction approach. The MIDI plugin for Albion is exactly doing that. M.A.X. only uses digital audio though. MIDI music is not available in the game - fortunately as the digital tracks are amazing.

So when it comes to audio in M.A.X. Port I took both the low level (S.O.S. audio driver) and the high level approach (MAX sound manager). The C++ sound manager component is not active now in the port and the version that is found on github is outdated. I am about 80% finished with the reverse engineering of the original C++ class of the sound manager and when that is done the low level interface will be gone completely. But to reimplement the exact functional behavior I need to study SDL_mixer more. Its documentation is very brief. I study integration examples in other projects, e.g. the ones in SR are good new candidates, but it will take weeks if not months still.

My focus is currently put into full introduction to github and its CI/CD aspects. I still need to document the build environment, write a code of conduct and coding guideline and as I do not want to manage build artifacts manually I want to get continuous delivery working with github actions.
On the side I try to set up a thread aware code profiler that does not misinterpret SDL and is capable of visualizing an execution timeline, a so called timeline profiler, so that I could find why the game slows down on mouse hoover and related rendering.

The ported source code of the various games found in SR will give me better insight on how to use SDL and SDL_mixer for low level abstractions, so thanks for bringing the project to my attention. But I do not plan to migrate to the framework itself.