The Super FX is one of the odder pieces of consumer hardware ever shipped. Faced with a console that could not do 3D, Nintendo did not wait for the next console — they put a RISC coprocessor on the game cartridge. Buy Star Fox, and the chip that renders it comes in the box with it.
Tobi has used that chip to run a version of Super Mario 64 on a Super Nintendo, with a new engine called SMFX.
Tobi’s own demonstration — the title is a response to years of people asking.
What it is and isn’t
A new engine, original assets. Tobi wrote SMFX from scratch; the original SM64 models and textures could be reused. This is not a port in the sense of recompiling code — the N64 ran a MIPS R4300i with a dedicated Reality Coprocessor, and the SNES plus Super FX shares nothing with it architecturally. The geometry came over; the engine is new.
It runs reasonably well. Which, for a console released in 1990 running a game from 1996, is the whole headline.
The two technical constraints, and why the second is worse
Frames are drawn back to front, because there is no Z-culling to work with.
That is the painter’s algorithm, and it is what you do when you have no depth buffer. Sort your polygons by distance, draw the far ones first, let the near ones paint over them. It costs you nothing in memory — a Z-buffer at even modest resolution is more RAM than the Super FX has to spare — and it costs you correctness: intersecting polygons cannot be resolved, and the sort itself can be ambiguous for certain arrangements, producing the characteristic flicker of objects swapping draw order.
This is not a limitation Tobi invented around. It is how most early 3D worked, including a great deal of the PlayStation 1 library, which also lacked a depth buffer and sorted per-primitive.
The 2MB memory limit is the bigger obstacle, and parts of levels may need to be cut to fit.
This is the more interesting problem, and it is the one people consistently underestimate. Frame rate is a performance constraint — you can optimise, simplify, reduce polygon counts, accept a lower frame rate. Capacity is a hard wall. The data either fits or it doesn’t.
SM64 shipped on an 8MB cartridge. A Super FX cartridge tops out around 2MB. That is a factor of four, and you cannot optimise your way past a factor of four in asset volume — you can compress, and then you have to cut. Which is why Tobi’s honest framing is that parts of levels may need to go.
It is worth appreciating what this means about the original: SM64’s levels are large, varied and dense, and fitting them in 8MB in 1996 was itself an extraordinary compression achievement.
The rumour, killed
There is a long-running story that Nintendo had a “Super Mario FX” in development — a 3D Mario for the SNES using the Super FX chip. Per the reporting on this project: there is no evidence Nintendo ever had such a game in the works.
The rumour has a plausible origin. Argonaut Software, who co-designed the Super FX with Nintendo, worked on Star Fox, and “Super Mario FX” was reportedly used internally as a codename for the Super FX chip project itself — not for a Mario game. Decades of retelling turned a chip codename into a cancelled title.
Worth stating plainly because it is the kind of rumour that gets stronger each time a project like this appears, and this project is evidence of what the hardware could do, not evidence that Nintendo tried.
Why this is creative coding rather than nostalgia
Because writing a 3D engine for hardware with no depth buffer, no floating point and two megabytes forces you to understand rendering in a way that using a modern API does not. Every decision — the sort, the fill, the fixed-point maths, the level of detail, what gets cut — is yours, visible, and consequential.
The demoscene has understood this for forty years: a severe constraint is a generative device. A platform that gives you everything gives you no shape to push against. And the results are legible in a way that unconstrained work often isn’t — anyone can see that this shouldn’t fit, which is most of why it is worth doing.
Tobi has said he plans to release the project in some form once satisfied with how it runs.