Latest ScummVM update gives classic adventure gaming a speed boost on AmigaOS4

The new build of ScummVM for AmigaOS 4 is not a flashy feature release. Instead, it is the kind of update that quietly makes everything feel better the moment you launch it. The focus of this version is almost entirely on performance and efficiency — the kind of improvements that remove friction you might not even realize was there until it disappears. The AmigaOS4 port, maintained by Maijestro, continues to evolve with careful platform-specific tuning so that ScummVM behaves more naturally on PowerPC systems and integrates better with the operating system. Rather than adding heavy new functionality, this release concentrates on removing wasted work, tightening the startup sequence, and ensuring that the engine uses the system’s resources in a smarter way.

The most obvious change appears the moment you launch the program. Previous builds of ScummVM on AmigaOS4 could take several seconds before the interface appeared, usually somewhere around six seconds depending on the system. It was not broken, but it certainly did not feel instant. In the new build that wait is essentially gone. Startup now happens in roughly one second. The improvement comes from several small but important changes that together remove unnecessary steps from the initialization process. Instead of performing the same tasks multiple times or repeatedly accessing files during startup, the engine now performs only the work that is actually required. The result is a launch that feels almost immediate.

One of the biggest hidden time sinks turned out to be the ThemeEngine, the part of ScummVM responsible for loading and managing the graphical interface. In earlier versions the ThemeEngine could be initialized twice during the startup sequence. The first initialization occurred during early program setup, and then it could be triggered again when the system checked the display resolution. Nothing visibly broke when this happened, but the engine was effectively doing the same work twice. That meant extra processing and unnecessary memory activity before the user even reached the main interface. The solution was straightforward: add a simple resolution check so the engine only initializes if it has not already been set up. Once that safeguard was in place, the duplicate initialization disappeared and startup immediately became lighter and faster.

Another small detail with surprisingly large impact involved the fonts.dat archive. This file contains the fonts used throughout the ScummVM interface and menus. Previously the archive was opened multiple times during startup — in fact up to four times — because different parts of the engine requested access separately. Every time the archive was opened the system had to perform additional filesystem work, which added small delays that accumulated during initialization. The new approach is much more efficient. The archive is opened once at startup and the resulting ZipArchive object is cached in memory. From that point on, every subsystem simply reuses that cached archive rather than reopening the file again. This eliminates redundant disk access and reduces the amount of work the operating system needs to perform during launch.

Graphics initialization also received a small but meaningful cleanup. Earlier versions attempted to probe the system for MSAA anti-aliasing support during startup. In theory this check would allow the engine to enable smoother rendering if the hardware supported it. However, in the current AmigaOS4 graphics stack using GLES2 and Warp3D Nova, MSAA is not available in this configuration. That meant the probe always failed, making the entire check pointless. Even though the failure was expected, the test still had to run every time ScummVM started. By simply removing this unnecessary probe, the graphics initialization path becomes shorter and avoids needless driver calls.

While most of the work in this release focuses on efficiency, there is also a glimpse of future development in the form of a Vulkan Graphics Manager, currently marked as beta. Vulkan is a modern graphics API designed to provide lower overhead and better control over GPU resources compared to older rendering systems. The implementation in this build is still incomplete, with font rendering support not yet finished, but the core manager is already in place. At the moment it mainly serves as an experimental foundation rather than a fully usable backend. Even so, it represents an important step toward more modern graphics capabilities on AmigaOS4 hardware in the future.

Performance improvements were not limited to startup. The release also adjusts how ScummVM interacts with the operating system’s scheduler by changing the priority of certain threads. Audio playback in particular depends on stable timing. If the audio mixer thread does not receive CPU time when it needs it, small glitches or dropouts can occur. To reduce the risk of this happening, the audio mixer thread priority has been increased by fifteen points, ensuring that audio processing receives the attention it needs even when the system is busy with other tasks. In addition, the main application thread has received a smaller priority increase of five points. This helps keep the interface responsive and ensures that rendering and input processing continue smoothly during gameplay.

Input handling also saw an improvement that cleans up both functionality and diagnostics. Previous builds produced repeated JOY_ warnings* in the debug output because the joystick hardware input interface had not been fully implemented for the platform. The warnings did not necessarily prevent controllers from working, but they were a clear sign that the input layer was incomplete. With the introduction of a proper HardwareInputSet implementation for joysticks, those warnings disappear and the input system behaves exactly as it should. Controllers are now handled more cleanly, and the runtime logs are no longer filled with unnecessary messages.

Another refinement focuses on the user experience when running the program outside of a development environment. Earlier builds could generate a large amount of debug output in the shell, which was helpful for developers but distracting for normal users. Even when launching ScummVM from Workbench, debug messages could still appear behind the scenes. In the new release the debug level for production builds is set so that shell output is completely suppressed unless debugging is intentionally enabled. This means the application launches quietly and behaves like a polished end-user program rather than a development build.

Finally, the executable itself has been optimized for distribution. The binary has been fully stripped, removing debug symbols and other metadata that are not needed during normal operation. The final executable now weighs in at around 18MB, which reduces the program’s overall footprint and allows it to load slightly faster from disk. While this change does not dramatically affect runtime performance, it contributes to a cleaner and more efficient final package. Taken as a whole, the 2026.1.1 release is all about refinement. There are no dramatic visual changes and no huge new features that immediately grab attention. Instead, the improvements work quietly behind the scenes. Startup is dramatically faster, redundant work has been removed, file access is more efficient, audio playback is more reliable, and the engine integrates more smoothly with the system. It is the kind of update that simply makes ScummVM feel better to use. Thanks to the continued work by Maijestro, the AmigaOS4 port keeps moving forward, gradually becoming faster, cleaner, and more polished with every release.

Spread the love

MORE AMIGA & RETRO NEWS