# Supermodel: a reverse engineered Sega Model 3 arcade emulator

> Supermodel emulates Sega's Model 3 arcade board, the 1996 to 1999 platform behind Virtua Fighter 3 and Scud Race, using OpenGL and SDL2, with network play over low latency links and automated builds for Windows, macOS and Linux. It suits a collector of that specific era of arcade hardware, and it does nothing for the boards around it.

**trzy/Supermodel** — Official repository of the Sega Model 3 arcade emulator.

- Repository: https://github.com/trzy/Supermodel
- Website: https://supermodel3.com
- Stars: 670 · Forks: 85
- Language: C++
- License: not declared
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/trzy-supermodel

## Emulating one board with no documentation to read

Supermodel emulates Sega's Model 3 arcade platform, and the project's stated aim is to develop an emulator that is both accurate and playable.

What makes that aim difficult is stated plainly in the overview: as with virtually all arcade hardware, no public documentation for the Model 3 platform exists, and what is known so far has been painstakingly reverse engineered from scratch. There is no reference manual to consult, no vendor errata, no chipset datasheet. Every behaviour of the board was reconstructed by observing what the real hardware did and working out why.

The scale of the original hardware explains the effort. Model 3 first made its debut in 1996 with Virtua Fighter 3 and Scud Race, and for the subsequent three years it boasted the most powerful 3D hardware of any gaming platform. It was developed by Real3D, then a Lockheed Martin company, with a heritage rooted in advanced flight simulator technology. Using an on-board scene graph and geometry processor, it could store, transform, light and rasterize tens of thousands of polygons per frame at a fluid 57.524 frames per second.

That figure is the benchmark the emulator is implicitly measured against, and the documentation treats it as a fact about the target rather than a claim about the emulator. The scene graph and the geometry processor are the parts a faithful implementation has to reproduce, and they are the reason the project is a sustained reverse engineering effort rather than a weekend port.

## Three processor families, one graphics path

The Model 3 board was not a single chip design, and the repository's topic tags say so directly: 68k, PowerPC and Z80 are the three processor families involved, alongside Sega, arcade and emulation topics.

A 68k is the Motorola 68000 family, the general purpose processor the board used for control logic, the Z80 is the Zilog part that arcade boards of the period used for sound and auxiliary tasks, and PowerPC is the piece that matters for the 3D. That is the classic Model 3 division of labour, with the PowerPC running the main program and the other two handling the board's other jobs.

The rendering side goes through OpenGL, and the windowing and input layer through SDL2, with SDL_net carrying the network play. The repository layout is organised around that: Src/ for the emulator sources, Libraries/ for the vendored dependencies, Makefiles/ for the per platform build files, MSVC/ for the Visual Studio path, Config/ and Assets/ for the runtime data, Scripts/ and Docs/ for the rest.

What the repository does not contain is game content. The tree is source, libraries, configuration, assets and scripts, so the emulator is a platform implementation that somebody else supplies the arcade data for, which is also why the licence question matters more here than it would for an ordinary library.

## Building on Windows with MSYS2 and GCC

The preferred Windows build is GCC under MSYS2, and the dependency list is installed with the pacman package manager. The four packages are the mingw-w64 GCC compiler, the mingw-w64 make, SDL2 and SDL2_net:

```
pacman -S mingw64/mingw-w64-x86_64-gcc
pacman -S mingw64/mingw-w64-x86_64-make
pacman -S mingw64/mingw-w64-x86_64-SDL2
pacman -S mingw64/mingw-w64-x86_64-SDL2_net
```

After that, both gcc and mingw32-make have to be on your path, and the documentation is specific about how: in the MSYS2 shell the binaries live in /mingw64/bin, and from the Windows Command Prompt, with MSYS2 installed in the default location, you add C:\msys64\mingw64\bin to the Windows PATH variable.

The build itself is one make invocation against a platform makefile:

```
mingw32-make -f Makefiles/Makefile.Win32
```

And there is a note that saves a step: network support is built in by default now, so there is no need to specify it anymore.

A Visual Studio 2026 path also exists. You make sure to run the Get_Libs.cmd files in the libraries directory, which pulls in the required dependencies automatically, and then either build inside the GUI or use the Build.cmd file in the MSVC folder.

The per platform makefile convention is worth noticing, because it is how the project keeps three operating systems building from one source tree without a single unified build system.

## Linux and macOS, and the Gatekeeper prompt on the first run

On Linux the dependency set is SDL2 and the OpenGL utility library, and the documentation suggests the standard package manager route. On Ubuntu that is:

```
sudo apt install libsdl2-dev
sudo apt install libsdl2-net-dev
sudo apt install libglu1-mesa-dev
```

Then the build is make -f Makefiles/Makefile.UNIX.

macOS needs the Xcode Command Line Tools, installed with xcode-select --install, and SDL2 and SDL_net, where the documentation tells you to download the latest .dmg files from the two links given and install them per the READMEs in the .dmgs, that is into /Library/Frameworks. The build is then make -f Makefiles/Makefile.OSX.

There is a note about running the result on macOS that saves an afternoon of confusion. If you try to run a macOS binary that was downloaded from the internet, or built on a different machine, macOS will not execute it until you grant permission. You open the folder containing the binary in Finder, right click or control click it, and click Open when the dialogue appears, the one saying that macOS cannot verify the developer. Then you close the terminal window that opens.

That is a one time step, and the documentation links Apple's own page on opening an app from an unidentified developer. It is the standard friction of shipping unsigned macOS binaries, and it applies to the automated builds published on the releases page.

## Nightly builds and a community that lost its forum

Automated builds for Windows, macOS and Linux are published on GitHub, and the release page is where you get them. The tag names tell you what the release process actually is: the three most recent are v0.3a-20261020-git-98fcbff, v0.3a-20261018-git-ddbc306 and v0.3a-20261017-git-b05ef21. That is a version series, a date and a short commit hash, which means the artefacts are cut from the tip of the repository rather than from a hand tagged release. The last push was on 2026-10-20, matching the newest tag.

For an emulator with a reverse engineering workflow, that is a sensible arrangement. The work is continuous, and a dated build tells you exactly which state of the tree it came from, so a bug report can name a build and a later build can be compared against it.

The community section is thinner than the code. The project points at a Discord server for questions, and it says why: they lost their web hosting and have no backup of the recent forum, so the GitHub page is the place for official releases and Discord is where the questions go. That is a real cost of the project, because the accumulated forum knowledge about specific games and specific boards is not recoverable, and a newcomer has to rediscover the quirks that used to be written down.

The copyright line covers 2003 to 2026, which is a reasonable measure of how long the reverse engineering has been running.

## What Supermodel does not do

Three limits are worth stating before you plan an evening around it.

The first is scope. This is a single board emulator, not a multi-system arcade front end. Model 3 is the target, and nothing in the documentation suggests support for the Model 2 hardware that came before it or the later Naomi and Chihiro boards. If your collection spans Sega arcade generations, this is one tool among several.

The second is the fidelity ceiling imposed by the missing documentation. The project aims to be accurate, but reverse engineering from observation means that an obscure game with unusual behaviour may still misbehave in a way nobody has diagnosed, because there is no manual to compare against. The accuracy claim is a goal rather than a guarantee, and the realistic expectation for a title that few people own is that it may not boot at all.

The third is that the network play is honest about its constraints. The overview says the emulator supports network play on low latency network connections, which is a narrow requirement. This is a shared screen, latency sensitive protocol over an Ethernet segment or a good local link, not a remote session over the internet.

The licence is also worth a careful look. The overview states that the source code is freely available under the terms of the GNU General Public License, while the licence field on the repository itself is recorded as unknown and cannot be classified by GitHub. The documentation in the repository is the one to read.

## Depth on one board instead of breadth across many

The obvious alternative to a single board emulator is a multi-system arcade emulator that covers dozens of boards behind one interface, and the difference in approach is exactly what you are choosing between.

The multi-system approach is breadth. One program, one input path, one configuration, and support for a long list of boards, most of which are emulated to a level that is good enough to play rather than to study. The cost is that each board gets a fraction of the attention, and a game on a less common board may have rough edges for years.

Supermodel is depth on a single board. The entire reverse engineering effort is pointed at one set of custom chips, which is why it can claim to be aiming at an emulator that is both accurate and playable, and why a Model 3 game behaves the way the documentation and the community expect it to.

The other difference is the build and the community. A multi-system project tends to ship a large, frequently updated binary and a busy forum. Supermodel gives you three makefiles and a Discord, and the forum history it would have accumulated is gone.

For a person with a shelf of Model 3 games and a graphics card, the trade is easy. The board is the interesting one, the hardware was extraordinary for its time, and the alternative to a faithful implementation is not a better emulator but a different set of games entirely.

## Conclusion

Adopt Supermodel if you own games from the Model 3 era and want them emulated with the accuracy that a single board can attract, and you are prepared to build from source or grab a nightly build. Do not adopt it for anything outside Model 3, since the project targets that board alone, and do not expect a finished community archive, since the project lost its web hosting and the recent forum with no backup. Verify first that the release you download matches the game set you own, that your machine can drive the renderer at the board's native 57.524 frames per second, and that the licence recorded in the repository is the one the project actually offers, since the README and the metadata disagree.

## FAQ

### What platform does Supermodel emulate?

Sega's Model 3 arcade platform, the 1996 to 1999 hardware that debuted with Virtua Fighter 3 and Scud Race. The project aims to develop an emulator that is both accurate and playable, and everything known about the platform has been reverse engineered from scratch because no public documentation exists.

### How do I build Supermodel on Linux?

Install the dependencies with sudo apt install libsdl2-dev, sudo apt install libsdl2-net-dev and sudo apt install libglu1-mesa-dev, then run make -f Makefiles/Makefile.UNIX. The macOS equivalent is make -f Makefiles/Makefile.OSX and the Windows one is mingw32-make -f Makefiles/Makefile.Win32.

### Where do I get Supermodel binaries?

Automated builds for Windows, macOS and Linux are published on the GitHub releases page. The release tags are dated and carry a commit hash, for example v0.3a-20261020-git-98fcbff, so each build can be traced to a state of the source tree.

### Why does my macOS Supermodel build not open?

A binary downloaded from the internet or built on another machine needs a one time permission grant. Open the folder containing the binary in Finder, right click or control click it, click Open in the dialogue saying that macOS cannot verify the developer, then close the terminal window that opens.

### Does Supermodel support network play?

Yes, the overview states that it supports network play on low latency network connections, with SDL_net carrying the traffic. That is a local or low latency link rather than a session across the internet.

## Sources

- [Issues](https://github.com/trzy/Supermodel/issues)
- [Project website](https://supermodel3.com)
- [README](https://github.com/trzy/Supermodel/blob/master/README.md)
- [Releases](https://github.com/trzy/Supermodel/releases)
- [trzy/Supermodel on GitHub](https://github.com/trzy/Supermodel)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/trzy-supermodel