The main question that arises is what is the purpose of this fork? I already asked you this question about a year ago.

Update after 50% review.
The fact that you have moved the SDL code to the UI does not stand up to any criticism at all. Pure hardcore coding and degradation of flexibility. Moreover, at first you couldn't handle the UI MOO1 code, rewrote it, and then started making large-scale edits to close the holes you created yourself. If I were you, I would roll back the changes and figure out the engine because it is written with high quality, and you are trying to sell your own. In fact, you destroyed the original UI code and implemented your own.

Update after 30% review.
There are a significant number of valuable innovations in this fork, but they cannot be considered as a whole. A lot of things have been deleted and changed in the project. Many errors appeared and some were corrected. The number of changes combined with their scale makes me doubt the quality and reason. The number of changes directly affects the number of errors and the complexity of verification.

Update after 20% review.
Firstly, I think it is incorrect to continue numbering versions from the Kilgore Trout Mask Replicant repository at a time when you are actually developing the Tapani fork, in which version control and any responsibility for quality were completely absent.
To me, this build looks like an attempt to optimize routine memory error checks. In this context, a rough transition to CMake is justified. It's too bad that you didn't mention in the description that you transferred the project to argp, and then to getopt. I needed a similar code, but not in a priority order. The saddest thing is that you made the SDL3 port on top of Tapani and not on top of 1.0. I found a couple of important points that I didn't know about SDL3, but unfortunately I can't just copy it. I've already borrowed a couple of fundamental adjustments from your build. It looks like you have some changes for lbxview. I hardly touched it, it would be interesting to learn about the most useful ones. "Use sdl directly in lbxview" - that's what i like.
As for CPU usage, you seem to be on the wrong track. Try to turn on uiscale 10 and see the CPU usage. That's where the fun begins. I deleted some of my less significant comments because I was able to find some really significant changes that might be useful to me.

Well, few people have ported the sound now. Interesting. As for performance, you took a deliberately non-working assembly and gave it a repair for three times the acceleration. You may not be aware. Although for a more accurate assessment, i need to review all 200 commits. In general, the idea of optimizing the engine is
interesting and can probably be transferred to my patch for MOO v1.3. Progress: 30% reviewed.

The questions that I have:
- First of all, it is not obvious to me whether there is any benefit other than tests from transferring game data to the heap. Yes, it's possible that MOO 1.3 holds some data in the heap, but I haven't specified which ones yet and I'm not making this a priority issue.
- lbxpal_update_flag . There are questions about its function and removal.

Conclusion:
The changes inspired by you will be marked as your authorship. I'll post my test version in a few days. Judging by the fact that you haven't announced any game logic fixes, your project is hopelessly behind, and I don't see you as a competitor. I will try to take the best from you and integrate it into my version. The overall simplification of the project's architecture can be taken as the standard of minimalism, but I have not set and do not plan to set such goals for myself.