BurgerBaron

Inside the foam-insulated briefcase were hundreds of screws and the wiring to make the improvised explosive device explode, RCMP in Sherwood Park said.

Finally a successor to the very out of date DolphinVR fork. DolphinXR is a GameCube / Wii emulator, allowing you to play games for these two platforms on PC with improvements and in VR. - iChris4/dolphinXR

I hope you enjoyed our April Fools’ Day announcement. With that out of the way, it’s time to discuss actual upcoming changes to MAME. We’re upgrading the development language standard from C++17 to C++20 and winding back support for obsolete configurations. We’ll also be reducing the frequency of releases a bit, so there will no longer be a release nearly every month. There will be no April release; our next release will be near the end of May.

A summary of updated requirements:

A compiler and C++ standard library with a reasonable level of C++20 support. GCC 11 is the oldest version of GCC that we will support. You can also use a reasonably up-to-date version of clang.  
Windows releases will require an updated installation of Windows 10 or later. Microsoft has already discontinued mainstream support for Windows 10, as well as all prior versions of Windows Home and Pro, and Windows 11 is already four years old.  
MAME’s Qt-based debugger will require Qt 6.  

A summary of some functionality we’re removing:

The 32-bit x86 (i686) recompiler back-end. It’s been over two decades since the x86-64 architecture was introduced. All major x86 operating systems have supported x86-64 for years, and 32-bit x86 support is being wound back.  
Support for compiling on OpenSolaris and other System V UNIX systems. There are no actively developed OpenSolaris distributions remaining, and no other System V UNIX variants have a meaningful presence on desktop systems.  
Specific optimisations for PowerPC host systems. PowerPC and OpenPOWER currently have no meaningful desktop presence, and the Libre-SOC project to produce a completely free, high-performance OpenPOWER implementation has stalled.  
The obsolete aueffectutil tool for macOS. This tool is no longer relevant with MAME’s new audio output system, and it had not been updated to work with recent versions of macOS.  
The pre-built MSYS2 environments with included development tools. There are multiple issues with our MSYS2 environment that we can’t practically solve.  

Read on for some more background and details.

We’ve decided it’s time to upgrade to the next version of the C++ standard and start taking advantage of the new functionality. It’s been long enough that libraries and tools with adequate C++20 support should be widespread. We’ll support building with GCC 11 and GNU libstdc++ 11 or later for now. If you’re using clang to compile MAME, please be aware that clang 11 and 12 have unacceptably bad bugs in their implementation of C++20, and clang 13 may crash when compiling some constructs. This means you may need a reasonably up-to-date version of clang to continue using it to build MAME.

Similarly, Qt 6 is available in MSYS2 and has been provided by all major Linux distributions for quite some time. We feel it’s a good time to remove support for Qt 5.

Due to increased memory usage of newer versions of GCC and the removal of clang and other LLVM-related packages from the MSYS2 MINGW32 package repository, it’s no longer practical to create 32-bit x86 builds of MAME for Windows. As such, features for supporting 32-bit x86 on Windows will become unmaintained. Since 32-bit x86 support in other operating systems is also being scaled back, we’ve decided it’s no longer worth the effort to maintain features catering to 32-bit x86 specifically. We’re removing functionality catering to PowerPC specifically at the same time as it has become similarly impractical to maintain.

We will be switching to building x86-64 Windows release with clang, the libc++ standard library, and the Microsoft Universal CRT (UCRT) C runtime library. This will mean our 64-bit x86 and ARM releases will be built with the same tools and libraries.

It’s become apparent that support for MSYS2 environments using the obsolete MSVCRT C runtime library is being wound down. Various packages are being removed from the repositories rather than being updated. It will become necessary to migrate to one of the environments using the UCRT C runtime library, i.e. UCRT64 or CLANG64 for 64-bit x86, or CLANGARM64 for 64-bit ARM. Our build scripts currently include support for building MAME using these environments with no additional effort.

There are multiple issues with the pre-packaged MSYS2 environments we provide for download. These include:

They have not matched the exact package versions used to build MAME releases for a long time, so they are not useful for reproducing official MAME releases.  
They are updated infrequently. This makes trying to update the core MSYS2 runtime or any of the included packages fraught with issues, as MSYS2 packages often have poor support skipping multiple versions when updating.  
Including packages to support building MAME across supported configurations, as well as generally useful development tools, would make the download impractically large. On the other hand, omitting packages leads to users encountering all the issues with updating MSYS2 packages when they attempt to add packages to support their use cases.  
Packaging development tools isn’t part of our core mission, so to speak, and takes time away from working on MAME development.  

As such, we recommend installing a standard MSYS2 environment and installing packages needed to build MAME using the pacman package manager command. We list the necessary packages in our documentation, and our Windows workflows on GitHub Actions show the necessary packages in a structured form.

There will always be some bumps in the road with a major change like this, but we believe this is a necessary step as part of our mission to keep MAME development viable for the long term.

But why?... Asphaltian in the comments: I'm planning a scripting API to allow anyone to create add-ons for any ROM you want, just not a priority right now. And because why not? Besides, I have lots of plans in store for it too.

I came across a post from Pixel Cherry Ninja on X of a new flashcart made by David Brito, who has turned this thought into a reality. David has a big history of modding retro consoles, having adapted N64s to be powered by USB-C, working with HDMI mods, and creating better controller solutions. He even made a built-in display for the Xbox 360 which is incredibly cool!

You know how the movie Inception was like a dream within a dream? Well, the Dolphin emulator can now emulate the Game Boy Player within the emulator itself, meaning that the GameCube has some inception of its own going on!

Plus: A launcher for recompilations and a new PS1 fan translation.

by Wes Fenlon

March 29, 2026 — 15 min read

Hello hello hello! In this week-late-but-worth-the-wait edition of ROM, I'm back to my old hijinks with a meaty interview for one of the most exciting open source projects on the scene right now: ReXGlue, the Xbox 360 recompilation tool.

The Dream Color Plus really is the gift that keeps on giving. Fans of the Dreamcast have been rejoicing over the fact that Angelo Pontes, aka Nai Adventure, has shown off the new Dreamcast controller with two joysticks, finally righting a 28-year wrong. It always amazed me that it only came with one stick when the other consoles of the time were boasting two, and perhaps that's one of the reasons why it didn't succeed as well as the competition.

For the past few weeks, our lead developers have been focusing on redesigning the ingame overlay of the emulator and we're announcing these updates with this video!

Everything shown is already available, just update RPCS3 and give it a try!

" This frame of Screamer 2 was rendered not by an original 3dfx card and not by an emulator, but by an FPGA reimplementation of the Voodoo 1 that I wrote in SpinalHDL. Available on GitHub.

What surprised me was not just that it worked. It was that a design like this can now be described, simulated, and debugged by one person, provided the tools let you express the architecture directly and inspect execution at the right level of abstraction.

The Voodoo 1 is old, but it is not simple. It has no transform-and-lighting hardware and no programmable shaders, so all of its graphics behavior is fixed in silicon: gradients for Gouraud shading, texture sampling, mipmapping, bilinear and trilinear filtering, alpha clipping, clipping, depth testing, fog, and more. A modern GPU concentrates much of its complexity in flexible programmable units. The Voodoo concentrates it in a large number of hardwired rendering behaviors.

One of the bugs that drove this home looked at first like a framebuffer hazard. Small clusters of partially translucent text and overlay pixels would go mysteriously transparent, even though most of the frame looked fine. The real issue turned out not to be one broken subsystem, but several small hardware-accuracy mismatches stacking up in exactly the wrong way. That bug ended up being a good summary of the whole project: the hard part was not "making triangles appear." It was matching the Voodoo's exact behavior closely enough that the wrong pixels stopped appearing.

This post is about the two abstractions that made that tractable. The first is how I represented the Voodoo's register semantics in SpinalHDL. The second is how I debugged a deep graphics pipeline using netlist-aware waveform queries in conetrace. "

cont. in dev blog.

Description Copy Paste: I built a custom open-world engine for the N64. In this video, I break down how I achieved a seamless, massive world with zero loading screens on N64 hardware.

You can download it here
https://github.com/lambertjamesd/n64brew2025/releases

Here is the team that helped me work on this.

Pyroxene: https://x.com/pyrox3ne
Caitlin G Cooke: https://cgcooke.itch.io/
terzdesign
Kælin: https://betadynast.bandcamp.com/

I will be using these same techniques in my ongoing project. If you want to support this work and follow the development journey, you can find me on

Patreon: patreon.com/JamesLambert

tl;dr: "I forked mGBA to print Game Boy Camera output directly to a thermal printer."

"The Game Boy Camera was brilliant and stupid in equal measure, a 128x112 pixel sensor bolted on top of a cartridge, printing to thermal paper on a Game Boy Printer the size of a brick. I got both for Christmas when I was 12 and somehow spent hours with them. The minigames are absurd, the image quality is aggressively awful, and the whole thing looks like a prop from a cheap sci-fi film. I loved it."

Cont. reading in linked dev blog.