TL;DW on the video: It's a texture atlas + mipmapping + streaming only parts of the texture atlas into RAM depending on where the view frustum intersects + discarding the z-buffer for a little more memory. Does not require the expansion pak. Impressive because a lot of N64 devs at the time didn't do these now-common things, and yet the N64 remains capable of them at a playable framerate.

Plus the video was using the N64’s high-res mode that most games didn’t use.

Presumably using the more standard resolution would let you use smaller textures and get a higher frame rate.

I hope someone makes something really cool with this some day. It’s always amazing to see what people are capable of pushing old hardware to do given the additional the knowledge we’ve gained and without the constraints of commercial timelines.

There's one developer that has spent a few years optimizing Mario 64 performance while also fixing various bugs and interactions. He also makes some videos showcasing other modern N64 games.

https://youtube.com/@KazeN64

     Impressive because a lot of N64 devs at the 
     time didn't do these now-common things

Absolutely, but it's also worth noting that these techniques might not have been viable in the context of a game (or at least, most games) anyway.

The author himself addressess this at the end of one of the videos and concludes that it might be a stretch unless a game was designed specifically around this rendering strategy.

He skips the N64's hardware Z-buffer (to conserve bandwidth) and DIY's it, which works for the demo because the demo room has exceedingly simple geometry. I don't know that this approach would work once you involve player models with 500-700 polys as seen here: https://www.copetti.org/writings/consoles/nintendo-64/

The transition between texture detail levels is also a bit jarring: it's an amazing demo, but might be too jarring or frustrating for a game.

On the positive side, the demo runs in the N64's hires mode, which could be avoided to free up some (a lot of?) perf. Also the author admits that the highest detail level of the textures is not something that would necessarily be needed for a game.

One also wonders if a hybrid approach would work: "megatextures" and DIY z-buffering for the scenery, trad rendering for the characters. I don't know if that is possible.

Bypassing Z-buffer was one thing late period correct games actually did to speed things up http://gliden64.blogspot.com/2019/02/hle-implementation-of-b...

> unless a game was designed specifically around this rendering strategy

This used to happen all the time.

An N64 game with this level of graphics would have sold like crazy back in the day, even if the game wasn't that great.

The N64 lifecycle was only about six years. Homebrewers have had nearly thirty years plus better tools to come up with new techniques.

He also states in the video the textures take up 40mb of the 64mb an N64 cart can realistically hold.

The author noted that this approach might be workable for a "real" game with smaller textures -- the biggest levels of detail for textures in the demo are 1024x1024. (And, I don't think the author mentioned this explicitly, but the demo is running in hires mode which could be dropped for a game)

His approach might be feasible with smaller textures and still represent a visual upgrade over the typical N64 "blurry mess"

> typical N64 "blurry mess"

At least N64 had correctly-projected textures.

PlayStation had sharp pixelated textures that were incorrectly mapped onto 2D triangles (they didn't account for depth).

So N64 was blurry but correct. PlayStation more aptly deserves the "mess" descriptor.

For the disk limit, what about procedurally generated textures?

Makes you wonder what modern hardware is truly capable of, if only we had the sacred knowledge.