Very cool. In 1998 (oof) we built Road Rash 64 which was accidentally open world -- even though you had race on a particular road, with a start and finish line, you could drive anywhere, see traffic all over the map, jump off of mountains, etc. The r4k plus reality coprocessor was quite potent -- we got to over 750k shaded triangles per second in optimized testing -- though finicky because you had to manage audio during vblank, etc. Plus, the reality coprocessor fog had a brutal hardware bug that made it really tricky to use.
Road Rash 64 is a really underrated game. As you say, the environment is alive, and nearly every race has a lot of potential for wacky slapstick fun. The driving feels really nice and is rewarding to learn.
if you were on the development team of that game I send my biggest thanks out to you. it was one of the few things me and my (hard to bond with) father bonded over growing up. We would play I think ..course 2 or 3 with the insanity level bikes ALL night trying to get out times down to something like 1 1/2 minutes. within ms of each other's times. run after run. so thanks.
There is a nice video by Kaze Emanuar demonstrating N64 easily pushing 300k shaded triangles per second without special optimizations in a game engine:
I just loved road rash, I had the demo version initially, I used to call it demo rash. Once in a race I accidentally jumped on a building, it was first open world experience for me!
In case anyone is interested, this creator built a remake of Portal for the N64, uploading a really cool set of videos describing the work that went into building it.
He's since stopped to work on his own IP, I believe that the issue was that Valve couldn't allow it because they'd never get Nintendo to agree to it. Something along those lines, anyway.
I think the main issue was he used Nintendo owned tools and libraries to make his game instead of the GPL ones, making the release of the port dependent on Nintendo's approval too. I guess even Valve didn't want to deal with their lawyers.
In principle he could use alternative tools, like libdragon, but he said even if he did that it was unlikely Valve would permit it, as Nintendo would still be antagonized somehow. And Valve it seems wants to improve their relationship with Nintendo (See: Valve blocked Dolphin on steam, and took down a video showing yuzu installed on the steam deck).
I actually used similar camera draw distance trick in my game Rogue Stargun.
The real way to optimize this stuff really well is for the artist to spend a lot of time making LODS for the distant objects. For the really distant objects, esp for a platform like n64, you can replace the distant objects with billboard imposters which are basically just flat poster textures that swap perspectives at certain angles.
GTA V does this extremely well with many manually made LODs and its very costly
Another game that I find has very impressive draw distance is Just Cause 2. You can see objects very far away when flying etc, but they look very detailed and do not change when moving closer. Definitely blew me away the first time playing it.
This is really cool. Kaze Emanuar[0] seems to be able to hit 60hz consistently with his Mario 64 rework, I wonder if such perf is achievable for these wide open landscapes.
Iirc Shadow of the Collosus rendered distant geometry into the skybox, which always struck me as a neat trick.
I emailed him the video from OP and he mentioned they’ve done some collaboration. I’m assuming there’s a retro programming discord that I’m not worthy of.
Yeah I remember hearing that SOTC's "SuperLow" LOD was a 2D image. Trespasser also did that, but only for trees and props, not for terrain objects. Trespasser being basically a heightmap with dinosaurs dropped in
Even modern games replace distant geometry with billboards. Simplygon is one middleware that does this. The Remedy folks talked about how Alan Wake 2 used it at GDC last year or the year before.
This reminds me of Magicore Anomala, a side scrolling game being made for the 1985 Atari. I wish there was a way to know how people contemporary to the release of the Atari or the N64 would react to seeing these modern engines.
Magicore Anomala seems to actually be a sideview non-scrolling bullet hell game for the Amiga, which came out in 1985. Teen me owned one of the first Amigas in my city and the in-progress videos I can find of Magicore don't feel too out of place with the games I was seeing on it by the early nineties. It's moving around a couple of sprites and rendering a single-bitplane image of projectiles, and has some basic copper list tricks to get a 3-plane background image to have more than eight colors, which was pretty normal for the Amiga.
Magicore is generally a bit zippier than most Amiga games, so many of them were kind of chunky and sluggish when I look back at them. Also the dev notes on using modern compression schemes that use what would be apocalyptic amounts of RAM and CPU by 1990 standards to crunch the data are amusing, but it's not like 1990 me wasn't used to chilling out for a few minutes between levels for a disc load, it was still worlds faster than the horrible load times of the C64 that was my first computer.
A super impressive feat, but also the games art style is like having bleach poured into my eyes. Am I just the wrong age for this specific retro nostalgia? Probably.
The same guy, James Lambert, also implemented texture streaming (which would not be invented until two console generations later) in an N64 demo. The textures look uncharacteristically high res: https://youtube.com/watch?v=Sf036fO-ZUk
Yes, id invented it, but I think they published one slightly earlier game which also had texture streaming. The technique (virtual textures) would not become ubiquitous in most engines until the PS4 era though.
Unfortunately nowadays id Software doesn't seem to be at the cutting edge of engine technology anymore. Most interesting new developments now come from Unreal Engine as far as I can tell. Like virtual geometry (Nanite) or efficient ray traced direct illumination (MegaLights).
It might be because he is not using nintendo's sdk anymore, particularly the "microcode" for RSP "coprocessor". Most N64 emulators usually do not emulate RSP properly, but detect which specific nintendo's microcode is used and then emulate it's behavior.
Correct, both of them are really really old, accuracy wise. N64 emulation has improved a lot in the past 4-5 years, but old emulators haven’t caught up
Very cool. In 1998 (oof) we built Road Rash 64 which was accidentally open world -- even though you had race on a particular road, with a start and finish line, you could drive anywhere, see traffic all over the map, jump off of mountains, etc. The r4k plus reality coprocessor was quite potent -- we got to over 750k shaded triangles per second in optimized testing -- though finicky because you had to manage audio during vblank, etc. Plus, the reality coprocessor fog had a brutal hardware bug that made it really tricky to use.
Road Rash 64 is a really underrated game. As you say, the environment is alive, and nearly every race has a lot of potential for wacky slapstick fun. The driving feels really nice and is rewarding to learn.
if you were on the development team of that game I send my biggest thanks out to you. it was one of the few things me and my (hard to bond with) father bonded over growing up. We would play I think ..course 2 or 3 with the insanity level bikes ALL night trying to get out times down to something like 1 1/2 minutes. within ms of each other's times. run after run. so thanks.
There is a nice video by Kaze Emanuar demonstrating N64 easily pushing 300k shaded triangles per second without special optimizations in a game engine:
https://www.youtube.com/watch?v=GC_jLsxZ7nw
I just loved road rash, I had the demo version initially, I used to call it demo rash. Once in a race I accidentally jumped on a building, it was first open world experience for me!
Massive fan, would love to hear some details about the culture in the office at that time!
Comments like this are why I just love Hacker News
> Plus, the reality coprocessor fog had a brutal hardware bug that made it really tricky to use.
What was the bug?
In case anyone is interested, this creator built a remake of Portal for the N64, uploading a really cool set of videos describing the work that went into building it.
He's since stopped to work on his own IP, I believe that the issue was that Valve couldn't allow it because they'd never get Nintendo to agree to it. Something along those lines, anyway.
I think the main issue was he used Nintendo owned tools and libraries to make his game instead of the GPL ones, making the release of the port dependent on Nintendo's approval too. I guess even Valve didn't want to deal with their lawyers.
In principle he could use alternative tools, like libdragon, but he said even if he did that it was unlikely Valve would permit it, as Nintendo would still be antagonized somehow. And Valve it seems wants to improve their relationship with Nintendo (See: Valve blocked Dolphin on steam, and took down a video showing yuzu installed on the steam deck).
> And Valve it seems wants to improve their relationship with Nintendo
Valve are the 200kg gorilla of the gaming industry and can throw their weight around.
However Nintendo are a 250kg gorilla.
I actually used similar camera draw distance trick in my game Rogue Stargun.
The real way to optimize this stuff really well is for the artist to spend a lot of time making LODS for the distant objects. For the really distant objects, esp for a platform like n64, you can replace the distant objects with billboard imposters which are basically just flat poster textures that swap perspectives at certain angles.
GTA V does this extremely well with many manually made LODs and its very costly
Another game that I find has very impressive draw distance is Just Cause 2. You can see objects very far away when flying etc, but they look very detailed and do not change when moving closer. Definitely blew me away the first time playing it.
They have a very complicated and robust pipeline that generates all of those LODs automatically. The artists aren't manually creating them.
I watched this on YouTube the other day. Another beautiful example of the creative power yielded from building within constraints.
Such a clever way to approach the problem! I'd say only possible with a detailed understanding of the N64 constraints.
This is really cool. Kaze Emanuar[0] seems to be able to hit 60hz consistently with his Mario 64 rework, I wonder if such perf is achievable for these wide open landscapes. Iirc Shadow of the Collosus rendered distant geometry into the skybox, which always struck me as a neat trick.
[0] http://www.youtube.com/@KazeN64
VRAM goes vroom vroom.
I emailed him the video from OP and he mentioned they’ve done some collaboration. I’m assuming there’s a retro programming discord that I’m not worthy of.
A lot of stuff is happening on the n64brew discord. https://discord.gg/WqFgNWf
Yeah I remember hearing that SOTC's "SuperLow" LOD was a 2D image. Trespasser also did that, but only for trees and props, not for terrain objects. Trespasser being basically a heightmap with dinosaurs dropped in
Hey! It also had a barely working physics engine.
Then again the dinosaurs were physics entities, so maybe you already mentioned it. :)
Even modern games replace distant geometry with billboards. Simplygon is one middleware that does this. The Remedy folks talked about how Alan Wake 2 used it at GDC last year or the year before.
The first comment:
> "The N64 is very memory bound"
> Aren't we all these days?
This reminds me of Magicore Anomala, a side scrolling game being made for the 1985 Atari. I wish there was a way to know how people contemporary to the release of the Atari or the N64 would react to seeing these modern engines.
Magicore Anomala seems to actually be a sideview non-scrolling bullet hell game for the Amiga, which came out in 1985. Teen me owned one of the first Amigas in my city and the in-progress videos I can find of Magicore don't feel too out of place with the games I was seeing on it by the early nineties. It's moving around a couple of sprites and rendering a single-bitplane image of projectiles, and has some basic copper list tricks to get a 3-plane background image to have more than eight colors, which was pretty normal for the Amiga.
Here's a dissection of the title screen of Shadow Of The Beast (1989), for instance: https://codetapper.com/amiga/sprite-tricks/shadow-of-the-bea...
Magicore is generally a bit zippier than most Amiga games, so many of them were kind of chunky and sluggish when I look back at them. Also the dev notes on using modern compression schemes that use what would be apocalyptic amounts of RAM and CPU by 1990 standards to crunch the data are amusing, but it's not like 1990 me wasn't used to chilling out for a few minutes between levels for a disc load, it was still worlds faster than the horrible load times of the C64 that was my first computer.
You know that 1985 was when 50-year-olds were starting high school right?
A super impressive feat, but also the games art style is like having bleach poured into my eyes. Am I just the wrong age for this specific retro nostalgia? Probably.
The same guy, James Lambert, also implemented texture streaming (which would not be invented until two console generations later) in an N64 demo. The textures look uncharacteristically high res: https://youtube.com/watch?v=Sf036fO-ZUk
Like in id softwares RAGE?
Yes, id invented it, but I think they published one slightly earlier game which also had texture streaming. The technique (virtual textures) would not become ubiquitous in most engines until the PS4 era though.
Enemy Territory: Quake Wars used an earlier version of it but only for the terrain. I think Rage was the first to use it for everything.
Unfortunately nowadays id Software doesn't seem to be at the cutting edge of engine technology anymore. Most interesting new developments now come from Unreal Engine as far as I can tell. Like virtual geometry (Nanite) or efficient ray traced direct illumination (MegaLights).
This is awesome!
Somewhat annoyingly, the actual homebrew z64 seems to crash both of the N64 cores that RetroArch supports. :(
It might be because he is not using nintendo's sdk anymore, particularly the "microcode" for RSP "coprocessor". Most N64 emulators usually do not emulate RSP properly, but detect which specific nintendo's microcode is used and then emulate it's behavior.
That means they are not accurate cores since it works fine on real hardware.
Correct, both of them are really really old, accuracy wise. N64 emulation has improved a lot in the past 4-5 years, but old emulators haven’t caught up
At the end of the video he says it needs real hardware or a "highly accurate emulator like Ares".