64 Bit instead of a memory limit: Why openOMSI can technically go much further than OMSI 2!

The difference already begins with the working memory. The original OMSI 2 is a 32-bit application and therefore has only a limited virtual address space. Under normal conditions, the well-known limit is approximately around 2 GB. The 4GB patch, widely used in the community, expands this scope on 64-bit Windows systems by allowing OMSI to use more address space. However, this does not turn OMSI 2 into a 64-bit application. Even with the patch, the game technically remains a 32-bit program and will eventually run into the limits of this architecture again.

That is exactly why additional RAM only helps to a limited extent in classic OMSI. A PC can have 16, 32 or 64 GB of RAM—but once the OMSI process has exhausted its available address space, it cannot simply continue using the system's remaining RAM as it wishes. Large maps, many AI vehicles, extensive bus models and high-resolution textures can therefore become problematic together. The 4GB patch has significantly eased this problem for many installations, but it does not eliminate the fundamental technical limit.

openOMSI, on the other hand, is being developed as a 64-bit application. The project explicitly names a 64-bit address space and the absence of a 2GB limit as two of its technical goals. In practice, this does not mean that openOMSI should suddenly use an unlimited amount of RAM. The computer's available resources naturally remain decisive. However, the old, rigid 32-bit limit is removed. This creates considerably more scope for extensive maps and detailed vehicles than in the original OMSI 2.

That alone does not guarantee high frame rates, however. More usable RAM does not automatically mean more FPS. The frame rate still depends on how complex a map is, how many vehicles and people are simulated, how complex the scripts are, how many objects have to be rendered, and how efficiently the new engine processes these tasks. The initial advantage of 64-bit is that memory no longer becomes a hard bottleneck as quickly. Performance and stability are therefore two related, but not identical, topics.

openOMSI is therefore changing more than just the memory architecture. The engine is multithreaded and is intended to distribute various tasks across multiple threads. Map sections are streamed, while texture loading can also take place on worker threads. Tasks like these can cause brief interruptions in classic OMSI when new areas or large quantities of data are loaded. The new system creates the technical foundation for separating such work more strongly from the actual gameplay. Since openOMSI is still in an early stage of development, this architecture does not yet mean that every map will run completely free of loading stutters or other performance problems.

openOMSI is also moving away from the old technical foundation in its renderer. It uses wgpu, which allows modern graphics APIs such as Vulkan, DirectX 12 and Metal to be used depending on the platform. This is not only interesting for Windows. openOMSI is being developed simultaneously for macOS, Linux and even Android, while the existing OMSI content is intended to continue serving as the basis. An original OMSI 2 installation remains necessary for this, since openOMSI itself does not include any maps, vehicles or other game content.

Modders also benefit from the removal of further old limitations. openOMSI can load textures with resolutions of up to 16,384 × 16,384 pixels However, this does not mean that every bus should be built with 16K textures in the future. Such resolutions require enormous amounts of graphics memory and only provide a visible advantage when the source material and intended use justify them in the first place. The engine can also reduce the texture resolution if a graphics card does not support certain sizes. Textures should be retained at their full resolution wherever possible at close range, while more distant objects can be reduced more strongly depending on the specified texture memory.

There are also modern PBR materials. Additional normal, roughness, metalness and ambient-occlusion maps can describe materials much more precisely than was possible with classic OMSI materials. This makes it possible to render metal, plastic, paint or rough surfaces in a more technically differentiated way. Here too, compatibility with old content remains an important point: Existing OMSI buses and maps are intended to continue working without conversion, while new additions can use the openOMSI engine's additional capabilities.

In the long term, this combination is likely to be more significant than any individual graphics feature. openOMSI is not trying to replace the entire OMSI world with new content, but to continue using the existing maps, buses, objects, scripts and timetables on a more modern technical foundation. The goal is the broadest possible compatibility with OMSI 2.2.032. However, the current development status is not yet error-free: The project explicitly describes itself as an early version in which features may be missing, malfunctioning or still subject to change.

The major technical change therefore lies less in a single feature than in the simultaneous removal of several old limitations. 64-bit removes the previous address-space limit, multithreading distributes work differently, streaming changes how loading takes place, and a modern renderer opens up new possibilities for graphics and platforms. This does not automatically turn a huge map into a perfect 120-FPS experience. The engine still has to deal with scripts, AI, vehicles and poorly optimized content. But it no longer has to solve these tasks within the same technical limitations on which OMSI 2 has been based for many years.

Link: https://turbo-devv.github.io/openOMSI/

What would be more important to you in openOMSI: fewer memory problems on large maps, higher FPS, or the ability to use significantly more elaborate buses and textures?