Hacker News Reader

Comment by jandrese | Hacker News Reader

No description on how this is achieved? I figure it must be creative since the N64 has a scant 4kB of texture cache. The textures must be streamed directly from ROM somehow, but in the real world this didn't work so N64 games were mostly Gouraud shaded with textures used sparsely.

View on HN

Roughly:

1) 40MB of textures 2) split into mipmaps 3) split into ~32x~32 tiles. 4) streamed in according to camera 5) with the lowest resolution layers always loaded to handle whipping the camera around quickly. 6) and the Z-buffer off to save memory bandwidth.

The video is worth watching too.

watch the "how" video linked in the other comment

> Gouraud shaded

I thought it was phong shaded?

by running SUPER SLOW code in an emulator. There is a reason every single N64 game was either sparsely textured or looked like blurry mess - 4KB of texture cache.

Check the link, the video, or the title. This is all running on real hardware.

Smooth running video https://www.youtube.com/watch?v=plh9OGel-lM does 60 fps on emulator. Real hardware video shows 15-20fps in a small room and author himself confirms its unfeasible for anything more complicated (~8 minute mark).

15-20fps is a pretty normal framerate for many games on the real Nintendo 64 hardware, especially the later ones from Rare.

The PAL versions of Zelda ran at 15-20FPS even on emulators in the PC. Yet they were pretty playable.

It probably looked not as bad on a CRT since LCD and OLED have terrible motion resolution. See https://www.youtube.com/watch?&v=z4xgLUdQhKA

I emulated it back in the day on a CRT monitor, true.

It's not a texture cache, it's 4KB of texture memory that needs to be manually babysat both in an emulator and hardware.

It might be the same situation as with Atari Jaguar where silicon bug turned texture cache into a fixed buffer you have to load manually.

AFAIK, the memory inside the Tom chip was never a cache. The bug you're probably thinking of is one that makes it difficult to run code on Tom's RISC core directly from main RAM. IIRC, jump instructions are pretty bugged when not running from internal RAM, but the homebrew community came up with a workaround. It's still not acting as a cache in that case though. It just fetches instructions from RAM as it goes.

It's not.

Reply on news.ycombinator.com