5 ms·

I’m been doing some Nintendo 64 development lately, and sometimes all ask the CEO at my workplace for advice or insights as he worked on Nintendo 64 games when

I’m been doing some Nintendo 64 development lately, and sometimes all ask the CEO at my workplace for advice or insights as he worked on Nintendo 64 games when he was younger. It’s not uncommon for him to finish the conversation with noting that he worked on Sega Saturn before the Nintendo 64, and the former was difficult to work with due to its particular architecture.

FillardMillmore 6y ago
Out of curiosity, what kind of tools do you use to do N64 development?
- danbolt 6y ago
  The last version of the SDK and the GCC-based toolchain were leaked a long time ago, which runs on Windows computers pre-Vista. I'll program in C with Sublime Text, and then run the compiler/toolchain in a VM running Windows XP. The VM can see my source code via a shared folder. I'm waiting on the mail for a flash cartridge to run ROMs on retail hardware, so for now I use the mupen64plus emulator on Mac OS X, but also a more accurate (but slower) one called CEN64 from time to time. Nintendo 64 emulators are kind of odd; the popular ones don't really "emulate" a game console the way I would have expected. Sometimes I post pictures of my progress on Twitter if you're interested: https://twitter.com/danielsavface/status/1258896460604555264 https://twitter.com/danielsavface/status/1258896460604555264
- yellowapple 6y ago
  As someone else digging into this... The short answer seems to be to use either SGI's N64 SDK and a modern toolchain (https://github.com/trhodeos/modern-n64sdk https://github.com/trhodeos/modern-n64sdk) or libdragon (https://dragonminded.com/n64dev/libdragon/ https://dragonminded.com/n64dev/libdragon/). The latter comes at the cost of not having built-in support for 3D (but it seems like there's enough there to take a DIY approach) and also being incompatible with most emulators (which "cheat" a bit by intercepting calls to the original libultra instead of directly emulating all the hardware). One could also run SGI's original compilers/toolchain, whether on a Linux system (using qemu-irix, which is what the folks over at https://github.com/n64decomp https://github.com/n64decomp have been doing) or on a Windows 98 VM. The N64Homebrew subreddit (https://www.reddit.com/r/N64Homebrew/ https://www.reddit.com/r/N64Homebrew/) is also a pretty useful resource.
danbmil99 6y ago
Peculiar is an understatement. The development tools were also a nightmare
- danbolt 6y ago
  Whelp at least we got Radiant Silvergun!
AdmiralAsshat 6y ago
My understanding is that the Sega Saturn was a nightmare to program for. Everything else at the time rendered with triangles, while the Saturn uniquely used quadrilaterals. It's also been a huge pain to emulate.
- masklinn 6y ago
  > Everything else at the time rendered with triangles, while the Saturn uniquely used quadrilaterals. Isn't that still the case? I know that quads are used quite a lot for modelling but is there any modern system which uses quads for rendering?
  - Narann 6y ago
    Quads are used as geometric data primitives because they allow consistent subdivision. But quads are not good as a rendering primitive compared to triangles. Triangles are rasterizer-friendly because they are composed of two edges and its quick to know if you are inside or outside two edges.
    - dylan604 6y ago
      > Triangles are rasterizer-friendly because they are composed of two edges Huh? Can you elaborate on how a triangle has 2 edges opposed to 3?
      - BearOso 6y ago
        For any span of pixels, you render from one edge to another because your y-coordinate is fixed. You only have to consider 2 edges at a time during rasterization. You can subdivide a quad easily, though, so it's not that much of an advantage.
      - Figs 6y ago
        I assume they mean for scanline rendering where you trace two edges at a time while drawing the scanline between them. Basically, the way it works is that you arrange the 3 vertices of a triangle from top to bottom, then take the middle vertex and split the triangle along the scanline from that vertex to the opposite edge. Each "half" of the triangle can be rendered by simply drawing a scanline between the two edge positions, stepping down to the next line, advancing the two edge positions, and repeating. (See "Bresenham's line algorithm" and "Digital differential analyzer" on wikipedia for efficient ways to compute the edge positions.) Note that if the middle vertex shares a scanline with another vertex, the other "half" of the triangle in this algorithm has a height of zero lines, and can just be ignored. It's a simple, straightforward way to rasterize a triangle that can be implemented efficiently.

FillardMillmore 6y ago

Out of curiosity, what kind of tools do you use to do N64 development?

danbolt 6y ago
The last version of the SDK and the GCC-based toolchain were leaked a long time ago, which runs on Windows computers pre-Vista. I'll program in C with Sublime Text, and then run the compiler/toolchain in a VM running Windows XP. The VM can see my source code via a shared folder. I'm waiting on the mail for a flash cartridge to run ROMs on retail hardware, so for now I use the mupen64plus emulator on Mac OS X, but also a more accurate (but slower) one called CEN64 from time to time. Nintendo 64 emulators are kind of odd; the popular ones don't really "emulate" a game console the way I would have expected. Sometimes I post pictures of my progress on Twitter if you're interested: https://twitter.com/danielsavface/status/1258896460604555264 https://twitter.com/danielsavface/status/1258896460604555264
yellowapple 6y ago
As someone else digging into this... The short answer seems to be to use either SGI's N64 SDK and a modern toolchain (https://github.com/trhodeos/modern-n64sdk https://github.com/trhodeos/modern-n64sdk) or libdragon (https://dragonminded.com/n64dev/libdragon/ https://dragonminded.com/n64dev/libdragon/). The latter comes at the cost of not having built-in support for 3D (but it seems like there's enough there to take a DIY approach) and also being incompatible with most emulators (which "cheat" a bit by intercepting calls to the original libultra instead of directly emulating all the hardware). One could also run SGI's original compilers/toolchain, whether on a Linux system (using qemu-irix, which is what the folks over at https://github.com/n64decomp https://github.com/n64decomp have been doing) or on a Windows 98 VM. The N64Homebrew subreddit (https://www.reddit.com/r/N64Homebrew/ https://www.reddit.com/r/N64Homebrew/) is also a pretty useful resource.

danbmil99 6y ago

Peculiar is an understatement. The development tools were also a nightmare

danbolt 6y ago
Whelp at least we got Radiant Silvergun!

AdmiralAsshat 6y ago

My understanding is that the Sega Saturn was a nightmare to program for. Everything else at the time rendered with triangles, while the Saturn uniquely used quadrilaterals. It's also been a huge pain to emulate.

masklinn 6y ago
> Everything else at the time rendered with triangles, while the Saturn uniquely used quadrilaterals. Isn't that still the case? I know that quads are used quite a lot for modelling but is there any modern system which uses quads for rendering?
- Narann 6y ago
  Quads are used as geometric data primitives because they allow consistent subdivision. But quads are not good as a rendering primitive compared to triangles. Triangles are rasterizer-friendly because they are composed of two edges and its quick to know if you are inside or outside two edges.
  - dylan604 6y ago
    > Triangles are rasterizer-friendly because they are composed of two edges Huh? Can you elaborate on how a triangle has 2 edges opposed to 3?
    - BearOso 6y ago
      For any span of pixels, you render from one edge to another because your y-coordinate is fixed. You only have to consider 2 edges at a time during rasterization. You can subdivide a quad easily, though, so it's not that much of an advantage.
    - Figs 6y ago
      I assume they mean for scanline rendering where you trace two edges at a time while drawing the scanline between them. Basically, the way it works is that you arrange the 3 vertices of a triangle from top to bottom, then take the middle vertex and split the triangle along the scanline from that vertex to the opposite edge. Each "half" of the triangle can be rendered by simply drawing a scanline between the two edge positions, stepping down to the next line, advancing the two edge positions, and repeating. (See "Bresenham's line algorithm" and "Digital differential analyzer" on wikipedia for efficient ways to compute the edge positions.) Note that if the middle vertex shares a scanline with another vertex, the other "half" of the triangle in this algorithm has a height of zero lines, and can just be ignored. It's a simple, straightforward way to rasterize a triangle that can be implemented efficiently.