Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to Make a Nintendo 64 Game in 2026

phoboslab.org

Post reply on HN
Print view View original

61–70 of 312 posts

Re: How to Make a Nintendo 64 Game in 2026

#61

Post by ryan_n »

shoobiedoo wrote: post #21
boricj wrote: post #3

I'm tinkering with a PlayStation homebrew (voxel space renderer) and development for fifth generation consoles has never been easier. Modern toolchains, programming languages, dev cartridges and libraries from the community makes all the difference. Outside of some niceties like ICE (gotta write that GDB stub for target hardware at some point), it's not that different from what you'd experience with modern embedded w…

There is something so charming about the N64/PS1 era. They were so unique in their own right and you could tell at a passing glance which system was displaying on the screen even if you didn't know what game it was. Two radically different systems at the dawning of 3D console games. I bought a MiSTer for me and my son and we played the heck out of Mario Kart 64 and Mario Golf. I think he picked up my "gaming is dead…

I grew up playing diablo II and super smash bros (super nintendo before that!). While I don't have as much time for it these days, gaming couldn't be farther from dead, IMO. There are incredible games and worlds being created both from AAA and indie studios alike.

Re: How to Make a Nintendo 64 Game in 2026

#64

Post by Mizza »

Libdragon has been improved massively in the past year or so, there are now simple demo games that show capabilities far beyond the original N64 games (bump mapping textures, HDR, seamless loading of massive overworld maps, etc.) Really talented core team, fun to give them a follow.

Demos: https://www.youtube.com/watch?v=XP8g2ngHftY

Re: How to Make a Nintendo 64 Game in 2026

#65

Post by cubefox »

inigyou wrote: post #59
cubefox wrote: post #49

Earlier quoted context omitted.

> It may be counterintuitive at first, but why wouldn't be possible? For the same reason it wasn't possible at the time for a third-party to make N64 cartridges themselves to avoid Nintendo's fees. But I assume these lockout chips are replicated or circumvented by now.

Fairly recently the chip was studied in detail and replicated. But like most systems of that era, I believe it was circumvented fairly quickly by pirates. The easiest way would be to piggyback a licensed cartridge - unlike the NES, it has to be one with the same region and bootloader as there are several lockout chip variants, but that basic technique still works.

I never saw a piggyback cartridge at the time though, or one that was obviously unlicensed. Of course, this could have more to do with Nintendo's legal pressure than with technological possibility.

Re: How to Make a Nintendo 64 Game in 2026

#66

Post by phoboslab »

crest wrote: post #51

Strange choice to go for a raycaster with sprites on the N64. The hardware is basically begging to be fed textured polygons.

All geometry is rendered as textured polygons. The raycasting step only determines visibility.

But yes, the N64 isn't particularly well suited for this type of game (or anything 2D, really). I didn't know that when I started the project.

Re: How to Make a Nintendo 64 Game in 2026

#67

Post by lucideer »

gambiting wrote: post #18
lucideer wrote: post #15

Earlier quoted context omitted.

I guess the curiosity here is in why game design for a modern target platform wouldn't garner the same enjoyment.

It's just not the same. I made games for the PSP and Vita and it's "different" than making games for Windows or Playstation/Xbox. There's something about seeing your creation on a tiny handheld. I guess maybe nowadays we got desensitized to it because our phones are actual supercomputers which can run Fortnite without breaking a sweat, but making a device with 2MB of ram play your game as you imagined it is just hype…

I'm not trying to be dismissive here - I am the type to be into the nitty gritty nerdy stuff that using Claude skips, BUT I have exactly zero experience developing anything for a legacy hardware platform in any capacity (with or without Claude) so genuinely curious to learn varying perspectives here.

Is it about the idea of the platform having limited capabilities (e.g. akin to Game Bub or MiSTer) or about tactile aesthetics (e.g. possibly vaguely comparable - though not really - to r36t or play.date) or something different entirely.

Re: How to Make a Nintendo 64 Game in 2026

#68

Post by inigyou »

cubefox wrote: post #65
inigyou wrote: post #59

Earlier quoted context omitted.

Fairly recently the chip was studied in detail and replicated. But like most systems of that era, I believe it was circumvented fairly quickly by pirates. The easiest way would be to piggyback a licensed cartridge - unlike the NES, it has to be one with the same region and bootloader as there are several lockout chip variants, but that basic technique still works.

I never saw a piggyback cartridge at the time though, or one that was obviously unlicensed. Of course, this could have more to do with Nintendo's legal pressure than with technological possibility.

I think a lot of the early flashcarts were piggybacks. I was never into that scene though.

Re: How to Make a Nintendo 64 Game in 2026

#69

Post by pjmlp »

spicyjpeg wrote: post #58
boricj wrote: post #3

I'm tinkering with a PlayStation homebrew (voxel space renderer) and development for fifth generation consoles has never been easier. Modern toolchains, programming languages, dev cartridges and libraries from the community makes all the difference. Outside of some niceties like ICE (gotta write that GDB stub for target hardware at some point), it's not that different from what you'd experience with modern embedded w…

I am still amazed my own minimalist PS1 tutorial series [1] became as popular as it did, given that prior to it basically all learning material on the internet was written around the decent-for-the-time-but-horrible-now Sony SDK and often based on 30-year-old example code full of 30-year-old C practices (in particular the complete disregard for aliasing and concurrency, which resulted in plenty of headaches once peop…

To put this into perspective for youngsters, that horrible Sony SDK was considered a wonder for its time, and what kickstarted the movement away from Assembly into C for home console development, as main language.

Until then, only arcades had already made the switch.

On PS2, PS2Linux, Dreamcast there was already C++ support, by the way.

Re: How to Make a Nintendo 64 Game in 2026

#70

Post by spicyjpeg »

dottjt wrote: post #14
boricj wrote: post #3

I'm tinkering with a PlayStation homebrew (voxel space renderer) and development for fifth generation consoles has never been easier. Modern toolchains, programming languages, dev cartridges and libraries from the community makes all the difference. Outside of some niceties like ICE (gotta write that GDB stub for target hardware at some point), it's not that different from what you'd experience with modern embedded w…

How did they do it back in the day? Was basically everything from the tooling etc. just created inhouse from scratch?

The same way it's done now with current generation consoles: the manufacturer would provide you with SDKs and development hardware once you paid them a decent chunk of money and signed an NDA. Prior to the fifth generation it was common for the SDK to be just an assembler, debugger and register-level hardware documentation, leaving the implementation of a kernel and game engine up to the game developer.

Sony however decided to provide a full C toolchain based on GCC as well as a set of very high level libraries that abstracted away basically all aspects of the PS1 [1], all the way up to implementing a ready-to-go 3D engine and MIDI sequencer. This was an unpopular move as the libraries were slow, inefficient and most game developers were used to having full control over the hardware, but it also allowed inexperienced devs to get started quickly (as proven by the thousands of low budget PS1 titles that used the high level APIs) and eventually contributed to the popularity of the console over its peers with worse tooling.

Sony would eventually go on to release some slightly lower level documentation for certain aspects of the console as well as APIs that better mapped to how the hardware actually worked under the hood. It wasn't however until years later that the hardware would be fully reverse engineered at the register level [2], and it took even longer for most homebrew to move away from the official SDK (which only really started happening a few years ago as accurate emulators and homebrew SDKs started popping up).

[1] https://psx.schnappy.xyz/sdk/Psy-Q/DOCS/LibOver47.pdf

[2] https://psx-spx.consoledev.net/

Post reply on HN