Nintendo is a little mysterious when it comes to what their actual tooling was, but I remember Donkey Kong Country being the first time I read they were using SGIs (or at least the studio "Rare" was).

It's somewhat surprising they used the Indy for developing Mario 64 – I always got the sense that it was somewhat lightweight in performance compared to the Indigo, but a very cool machine either way.

What does this mean?

I think of QEMU as emulating hardware... What exactly is being emulated here?

I've noticed spillover effects into Japanese gamers as well -- people being suspicious of or derisive about mods, even when they're perfectly legal and the game has built-in mod support (looking at you Monster Hunter World).

My (Japanese) girlfriend is on the very conservative side of the spectrum there and absolutely hates it when I bring up any kind of modding, and so do her friends -- the culture of "authorial intent is king" is very strangely strong for a culture that also appreciates and enjoys doujin.

Wrong console?

But not much has changed, I guess it's hard to make progress in a month.

I can not figure out the right keywords to find it again, but you may be able to if you are interested.

EDIT: Even though I can't find the video anywhere (I promise it existed!), from https://warosu.org/vr/thread/5644072

"To answer your questions, yes: This is a full source code which can be recompiled with modern toolchains (gcc: ive done this already) and even target other platforms (PC) with quite a bit of work. There already exists some proof of concept wireframe stuff."

(The additional characters in the DS remake were horribly unbalanced, so I wonder if the earlier implementation would have been better...)

Most of the other "assembly" files are for data, like the level scripts. It's not assembly of machine code.

You could try to put those into C, but you're not gaining much--assuming that it's even something that can be represented in C without a bunch of fancy compiler specific tricks. You'd be better off creating a DSL or a custom program suite, which is probably what Nintendo was doing 25 years ago.

More than likely SM64 was written in c with some critical performance parts in ASM (like mode7 and some of the OAM stuff other threads talk about).

Also there are "Controller Converter" N64->USB available on i.e. Amazon and iNNEXT has an Retro 64-Bit N64 Controller on Amazon as well.

Don't know if any of these will work for you, at least the iNNEXT is mentioned in the retropie wiki[0].

[0] https://retropie.org.uk/docs/Nintendo-64/

I mean, you're right, it's not a literal implementation of OAM in the sense of controlling the same things OAM controls. I was speaking kinda metaphorically.

NES/SNES OAM was useful for reading back entity physics data (because it gave objects X/Y position registers) which meant that developers (incl. Nintendo themselves) often chose to rely on the OAM-object "components" of a entity as the canonical handle for tracking the entity in the game physics (Rather than having a table somewhere in work-RAM of separate "physical" components for entities.) Games like SMW literally just index a table of actor behaviors off the OAM-object's name-table data; what an entity "is" from the game's perspective, is determined by what it currently looks like!

Since the OAM had a finite size, this reliance on OAM for tracking entities forced games into a structure where entities' lifetimes are coupled to the lifetime of their OAM-object representations. Which meant that every NES/SNES game relying on OAM to track entities needed an algorithm for dynamically allocating OAM-object slots to entities; and so, for evicting entities if OAM was exhausted. (Level design was done with a hard eye for avoiding OAM "thrashing" by keeping entities spaced apart, but the system still needed to be able to handle the case where mobile entities ended up following you and piling up.) Which brought into existence the common OAM LRU cache-eviction algorithm—i.e., the practice of "despawning" the oldest off-screen entities when new on-screen entities need OAM slots.

This determined a lot about the design of these NES/SNES games. It made mobs in these games into things that would lose their state whenever they were scrolled "far enough" off the screen; which in turn forced a design where—rather than a level just running a "start script" that would spawn entities at initial positions, tracking them in RAM from then on—you instead had adopt a hybrid approach where entities had both an OAM-object representation, and also an associated "spawner" (usually existing just as static level-data in ROM, though sometimes coupled to a bitflag tracking destroyed spawns) that would trigger [re]spawning for the entity.

SM64 is essentially "emulating OAM" in the sense that it assigns entities handles in a fixed-sized buffer, and then uses a very OAM-like logic (basically, "memory pressure" on this buffer) to decide when entities should be de-spawned; and then uses spawners to recreate entities that have been de-spawned due to this memory pressure (meaning that most entities don't "exist" until you get close enough to them.)

SM64 didn't need to do things this way; the N64 has enough RAM to track all the entities in every SM64 map at once, IIRC. They chose to impose this constraint artificially, in order to continue to build SM64 levels according to the design philosophy they had "discovered" due to the original constraints of the OAM system.

Later games in the Mario series, if-and-when they choose to have this de-spawn/re-spawn tracking feature†, are essentially "pretending to have OAM", but not really emulating it the way SM64 does. For example, Mario Maker de-spawns entities when they're scrolled sufficiently far off the screen, in a way that mimics OAM sufficiently well that re-spawning and enemy spawner semantics still work—but which isn't really an OAM-like system, in that there's no static buffer with memory-pressure causing de-spawning (and in fact, as long as the entities are willing to squeeze into one visual screen, existing entities will never be forced to de-spawn.)

† You could get a very interesting analysis of the way Nintendo probably internally divides/project-manages the Mario games, by just determining which titles "emulate" OAM the way SM64 does; which titles loosely mimic OAM, like Mario Maker; and which titles don't even bother with de-spawn/re-spawn tracking at all, but instead have persistent physical entities that just "go quiescent" when they're out of sight. (IIRC there's no Mario title that uses the fourth option—pure view-frustum culling of distant models that continue to "tick" while culled.)

(Side-note: I've always wondered how the mini-games in IS's WarioWare series work—whether each game is entirely custom code, or whether they've come up with some sort of DSL for specifying reflex games. If the latter, I would bet that that has a decent genealogy too.)

Picture a background jobs system like Sidekik/Resque. Imagine that one worker-node of this jobs system had a fixed-size ring array of jobs it had taken. Now imagine that you could push new jobs onto a specific node. And now imagine that the worker-node responded by not just overwriting one of the filled slots of the local jobs set, but actually ACKing said job to drop it from the global job-queue system. It's destroying a real entity with persistent global identity, in order to reclaim the slot that the local representation of that entity takes up.

That's what OAM is, when combined with the design pattern I'm talking about. It's a ridiculous system that'd never fly in a business; but it happens to work for games, where you control the world such that you can make the world hold "reminders" for the state you destroyed.