VR Powered by N64 [video] | Hacker News Reader

VR Powered by N64 [video]

youtube.com

111 pointszdw30 comments

The interesting thing is that the original chip inside the N64 was created by Silicon Graphics and was called Project Reality, and it was originally created to pursue consumer VR before that whole industry blew up in the 90s and it was made to power a 3D console instead. More details: https://medium.com/@AguyinaRPG/the-nintendo-64-was-the-culmi...

They already had called it the EyePhone. I'm dying

Got to play with the N64 at the "soft" launch at SIGGRAPH '96. It was pretty mind-blowing.

But even more mind-blowing was the SGI booth where they had an Onyx running a VR demo where the user was building downtown New Orleans in legos. Based on that, our shop actually found quite a few customers willing to pay for VRML development, of all things.

This guy is a wizard. I'm glad he's still hacking on cool stuff after he was forced to stop working on Portal64

Couldn't he just release something what wasn't call Portal instead? Couldn't he call it "Hole Jump" and just not use Portal's assets for it?

The issue wasn’t portal, it was Nintendo. Even if he reskinned it Nintendo would still be mad at him for using their libraries.

Valve seemed to be relatively cool about it until Nintendo decided to come knocking and then it became too much of a legal threat.

I doubt they are "mad". There will be a team of people whose job it is to pursue ip infringement for Nintendo, they probably don't get emotional about it.

Did they ever explicitly state that Nintendo brought up issues?

I remember with Dolphin, Valve took it down without Nintendo ever even contacting them, which was just very weird. Especially because it was a high-profile Steam launch that they were very much aware of ahead of time.

The only reason Valve pulled it was because they feared Nintendo would come after them as it was using Nintendos proprietary graphics API. They could not distribute the code.

If it was to use a custom built API then there is no issue but hacking N64s RSP is a tricky beast of a chip due to all the oddities of it being essentially experimental 3D hardware at the time.

>hacking N64s RSP is a tricky beast of a chip due to all the oddities of it being essentially experimental 3D hardware at the time

It was basically trimmed down cost reduced SGI hardware, noting too exotic or revolutionary.

Its not so much that is revolutionary, more that it was finicky and precise in its ways.

He could use libdragon / tiny3d which has zero nintendo code in it. https://mbeboek.gitlab.io/rspl/ (posted this to hn but of course it got ignored)

It is a path that was being explored. I think the issue was that so much of the standing work was based on the explicit functions of the original API. A case of they would have to build up Tiny3D to get equivalent functions.

Definitely viable but I guess if you are working on a game, all of a sudden you are focusing on the core workings of an API rather than getting a project done.

Like building an app in Rust and then getting side tracked on optimizing the actual compiler. Very cool but a different task.

Was curious about what happened and did some digging. Here is a PC Gamer write up [1] as the original Patreon post requires a login [2].

[1]: https://www.pcgamer.com/that-portal-64-demake-we-liked-so-mu...

[2]: https://www.patreon.com/posts/new-about-future-96205584

Lambert's Portal 64 work was too impressive for words, so I am truly sad that it has been halted. I was unaware that he relied on Nintendo's proprietary libraries, but I guess I should not be too surprised to see that from a project that used the name and assets from a proprietary game. The silver lining I suppose is that we know that Lambert is likely to produce great things in the future, wherever his mind and heart takes him.

This is really cool. I was involved with getting the HTC Vive (SteamVR) headset working on a low power Intel NUC with embedded graphics - to do VR without using Valve's software. Like James, we used Occulus code as a guide, particularly guiding our efforts for the chromatic aberration correction - One thing that James will not have the processing power to handle. It was difficult but in the end we got it all working at 90 FPS (11 ms) - Good luck on your efforts James!

I'd love to see what he could do to optimise and compare the Jaguar VR. I don't think the rendering would be as good, but the lag might be lower with a more raw interface:

https://www.youtube.com/watch?v=Xh8T6iSbMhc https://www.youtube.com/watch?v=Sb-MD8P0c6U https://www.youtube.com/watch?v=MFZCgNBxkcM

Interestingly, the NES had 3D glasses that go over your face like the occulus and the power glove (mentioned in the video), which has roll and flex sensors. No games combined the two, but I wonder what that could have been like with such little power. It wouldn't be true VR in any sense we think of today, but it would have been very unique gaming experience at home in the late 80s.

The Famicom 3D system was shutter glasses; these were also used on the Sega Master System. On the NES, there wasn't a shutter glasses peripheral released, so dual perspective 3D games used anaglyph glasses (red/blue).

In my book, that's not really 'over your face like the occulus', but that's up to you. Shutter glasses have come and gone several times on computers; many supported by Descent from 1995 on several different types of glasses, and there was a revival of the concept around 2009 with Nvidia 3D Vision. Having used some of the 1995 stuff, gearVR, and a quest 3, shutter glasses are a big pain.

On the power glove, man is it trash. Theoretically maybe, and I think some determined moders have turned it into something useful, but period gamepay is atrocious. My brother bought one with his paper route money and I think it turned him off video games.

Shutter glasses were also used on PC even where games did not support them. I remember playing WWIIOL on a CRT with shutter glasses. The effect was amazing, even though a few non-3d assets rendered flat. When VR came along I was hoping that it too could be handled entirely within drivers, negating the need for a title to "support VR". I am so far disappointed.

Core memory unlocked! I had completely forgotten about those things. When it worked it was pretty cool.

I guess the issue with driver based VR support is that the headset movement would be independent of the game code. Thus you would get a lot of issues because you are overriding the games camera system.

I'm assuming this is the kind of side-project that gets you hired on the spot in the VR teams at Apple/Meta/Snap without the LC bullshit?

This is what James Lambert does as a follow up when Valve shuts down [1] his "Portal in N64" project [2].

James is like Kaze [3] and builds incredible N64 demos [4] and technical videos about them.

[1] https://www.youtube.com/watch?v=AdBzok8GjA0

[2] https://www.youtube.com/watch?v=r4KGm7ixcqI

[3] https://www.youtube.com/watch?v=t_rzYnXEQlE

[4] https://www.youtube.com/watch?v=Sf036fO-ZUk

LC=?

Leet Code

Someone who can create Portal 64 would easily breeze through LC. Why would LC be such a big barrier to someone to whom mastering the undocumented N64 graphics architecture is just a fun hobby project?

Because leetcode BS is about memorizing useless trivia.

It is? I didn't know that. What kind of trivia?

Dijkstra's Algorithm required for some LC feels a bit like trivia. Not sure if most people could come up with that on their own.

Are you telling me that a highly qualified coder who can create Portal 64.... will be unable to find the shortest path between two points?

Not even given the chance to spend an evening or weekend skimming their old algorithms textbook before interviewing, as any reasonable person does?

Would you also say Depth First Search and Breadth First Search are too complicated to expect average devs to understand?

This is amazing. A decade after we posted the firmware source code on GitHub, this is the first project I've seen use it! https://github.com/facebookarchive/RiftDK1

Reply on news.ycombinator.com