u/SomeoneWithMyName

I just figured out how to make a user-friendly interface for the MOO 1.3 patch. The idea is to take the modified menu from 1oom 1.11.9 and use it as the front-end for the patch, while saving the settings in the patch config, and copy the patched version of the game to a separate file and run it directly from the patch to eliminate the chances to damage the original files. So, we will get a full-fledged Master of Orion 1993 loader with all the fixes implemented so far from 1oom, which will look very similar to 1oom.
Edit: This way we won't need to reinvent the wheel and rewrite orion.exe from scratch, which is still too much for me. The development of 1oom 2.0 is a priority for me right now, so I'll work on the patch after, in parallel with the improved fork of 1oom 2.0.

Against the background of analyzing the subtleties of the engine, I solved the puzzle about what the enriched interface of Master of Orion should look like. I don't want to reveal the details, but the possibilities are endless, and the gameplay and atmosphere will be fully preserved, while fully covering the need for huge maps in macro control.

This is taking into account the fact that the code is still utter garbage.

Here is a short list of new features, the implementation of which is radically simplified by the latest improvements:
- Console rendering is actually fully implemented with transparent layers
- Rendering the popup help with a separate layer
- Higher-resolution fonts on top of low-resolution images to display more information
- The implementation of windows, hiding part of the interface, a more modern interface as a whole
All this can be added to amateur forks or the original engine, depending on the usefulness of the idea.
Edit: I am most proud of the fact that such engine improvements were achieved mainly by restoring the original interface logic from Master of Orion 1993.

Careful, unhurried planning and large-scale cleaning of hallucinations in the code of the 1oom 1.0 interface yielded their first significant fruit. I was able to easily implement a transparent hardware cursor and overlay it on a scalable map. The map itself is already being drawn correctly in my drafts, but I want to conduct another round of refactoring to work with the coordinates more comfortably. The cursor is already in the testing branch on sourcecraft, implemented in the SDL2 version.

Update:
The full prototype of a clean buffer implementation has matured and the engine has been pre-cleaned. Now the hardware will be responsible for updating the mouse position after changing the zoom and controlling the maximum zoom, which will eliminate the need for additional control code and eliminate the potential for crashes in this fragment of the engine. The rest of the implementation is almost entirely concentrated in the interface code, which gives me some freedom of action.

The main differences in 1oom 1.0 from MOO 1.3 are described below:

1. Many calls to rendering functions in 1oom 1.0 are inflated by parameters that do not exist in the original, which in the original existed as the global context of the screen. This change in 1oom 1.0 made it impossible to change the rendering context. I have already fixed this issue.
2. In 1oom 1.0, there are 2 main functions for accessing the screen buffer (get_front and get_back). In the original, access was carried out through a global pointer to the current segment of video memory, which was switched by the functions select_front, select_back, flip. This change also makes it difficult to work with context, which I plan to fix in the near future.

Correcting these two points will make it convenient to work with any number of rendering layers using the original engine. I'm not really in a hurry with this, because I have a personal life, but I don't plan to delay it either. These changes are a priority for me, because I still want to complete the scaling, which is practically only in these 2 problems.
Fixing these issues will also allow me to fully restore the original mouse rendering, which also underwent significant modifications in 1oom 1.0.

I'm currently working through the remaining bugs related to rolling back the interface to the original, which will make it easy to optionally expand the map to the full screen, hiding the sidebar and not causing glitches. It is planned to add this feature in 2.0 along with optimized scaling. The extensibility of the interface as a result of my work will increase radically, without changing the basic original interface logic from MOO v1.3. I do not plan to add large galaxies to the vanilla version, as their stability requires large deviations from the standard game logic. This option will be available in test releases. In the future, I plan to work on HD rendering of the map with the display of sliders and other information directly on the map.

The results were extremely unexpected and successful for me. During these 3 days, during the analysis of my drafts, I cleaned up so much garbage left by the author of 1oom 1.0 that now the UI code has become much easier to modify. And this is just the beginning. Now I expect to study and restore the original behavior of cursor, as well as implement a simple texture-based hw cursor. In addition, there was a question about the possibility of introducing huge galaxies in MOO 1.3, and it seems to me that this is possible with the help of a patch. In general, the code becomes more readable and friendly for advanced developers.

Update11: To avoid confusion, pay attention to the author of the publication. Different authors can distribute information about different versions of 1oom. The fork from mikesc has nothing to do with my project, except for the common 1oom 0.1 core and some minor fixes. In fact, this is a fork of the Tapani fork with all the problems that follow.
About my project: Fix for SDL2 is ready. It looks like it's possible to port overlays to SDL1 and Allegro4 now.

Update10:
https://www.reddit.com/r/masteroforion/comments/1f4viy6/1oom_the_project_has_entered_a_new_stage_of/
I exceeded my expectations about this post, which I left 2 years ago. We can assume that the stage has been passed, since the most important engine problems have been fixed. I did a slightly crooked cursor rendering, but nothing prevents me from doing a normal one tomorrow.

Update9:
Recent changes have clarified the need to streamline the operations of checking the boundaries of the drawing. This way the engine will become even more stable. By the way, I have to try to optimize the loading and generation of huge maps, since these processes take a considerable amount of time. The scale of rendering purification from parameters that did not exist in the original has acquired impressive values.

Update8:
I had a sensational idea. While thinking about how to recycle the zoom at a resolution of 1280 x 960 and higher, I came to the conclusion that at higher resolutions it would be fun to just bring the sliders directly to the map and send the rest of the interface to Kukuevo. We will get a smooth transition to 1oom-UHD.

Update7:
My draft is almost ready. While I was sketching, I slightly improved the structure of some elements of the engine. Tomorrow, another iteration of architectural cleaning will be carried out to make the layering more natural. The mouse doesn't work yet, so I use the system mouse. A test release with a new way of scaling is guaranteed in the coming days. Together with ultra-huge maps. Also: rough rendering of 8-bit textures with a palette in SDL3 is now done in two lines, which is damn nice when your head is full of other problems.

Update6:
The new version of the map zoom will be adaptive. Larger map sizes will no longer impose restrictions on the minimum window size, since the scalable map will be drawn on top of a 320x240 vanilla image via hardware scaling, which will set the minimum window size as before. In addition, this approach will avoid almost all errors related to ui_scale from 1oom 1.0, since ui_scale will only be activated in map mode. After implementing the soft rendering of the map, it will be possible to think about rendering the map based on hardware textures.

Update5:
After analyzing the old changes for uiscale, it became obvious that the main significant ones are the uiobj.c and cursor.c code. Almost everything else is redundant changes. In addition, I managed to simplify the universal interface of the hardware and now it is clear how to link scalable rendering with behavior. Apparently, I managed to simplify the implementation of ui_scale to the limit. The coordinate matching is almost done. There is hope for a modern implementation. If I do, I'll add it to the vanilla.

Update4:
I still managed to test buffering optimization on the huge texture of the old engine (uiscale 24), and to my surprise, the performance gain was no more than 5-10%. I assume this is due to the high cost of converting from the old 8-bit color scheme with a palette to the modern 32-bit one. Note: I don't update GitHub.

Update3:
Since I removed one intermediate copy, the old scaling scheme suddenly becomes very attractive. At least because it is good as a benchmark for rendering performance. I think I'll see if it can be adapted quickly tomorrow. I'm not making any promises.

Update2:
While I was reading the updated specification, I found that it is possible to draw game buffers directly, even in SDL1. Why neither KTMR, nor the guys who broke the Tapani fork and complained most of all about the slowdown due to repeated copying of buffers, thought to use this functionality is now a mystery to me. This optimization is asking for it. I just made sure that the video_render function can be completely removed from the code and replaced with direct double buffering with pointer substitution instead of copying the image. This is especially critical for the old 1.11.8 engine, which once again copied a huge image using the processor instead of passing a link to the buffer. On top of that, it also simplifies the code. Unfortunately, I tried to add this improvement to vanilla and the old engine, but I couldn't figure out why everything was working correctly in vanilla, and the cursor was starting to glitch in the old engine. It seemed to me that this improvement should work in the old engine as well.

Update:
SDL3 improves support for multi-window applications, which theoretically makes it easy to implement a separate console or debugging window, instead of dancing with a tambourine in the main window. It can also simplify scaling the galaxy interface by rendering the map in a separate window. Obviously, delays in introducing improvements on this topic have led the project to fundamentally more elegant solutions.

I studied the capabilities of the new library and came to the conclusion that it allows you to optimize the old code quite well, remove some crutches from SDL2 and implement smooth music fading exactly as it was in the original MOO 1.3. However, the sound code will have to be completely redesigned, since SDL3_mixer radically changed the architecture. At the moment, I even managed to play some sounds, but the general sound system is not working. The video is generally compatible with SDL2, and I managed to fix everything, including the mouse. SDL3_mixer support is unreliable, I recommend disabling it during the build. There is no SDL3_mixer on Debian, so everything should work without sound out of the box.
https://fork1oom.sourcecraft.site/

Also:
I now have the opportunity to create a separate website page for the patch and post detailed patch information on it. I don't know what to write there yet, but the option is easy to implement and I keep it in mind.