Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Super Mario 64 for the PS1

github.com

Post reply on HN
Print view View original

101–110 of 116 posts

Re: Super Mario 64 for the PS1

#101

Post by mghackerlady »

greeniskool wrote: post #97
01HNNWZ0MV43FF wrote: post #40

Earlier quoted context omitted.

The N64 definitely has the nicer GPU of the two. An N64 with a CD-ROM drive would have been amazing.

There was actually an unauthorized third-party CD-ROM drive for it, the Bung Doctor V64[1]. It didn't actually expand the available ROM space beyond what was possible with cartidges, but its still interesting in that it was allegedly used by licensed Nintendo devs as a lower-cost alternative to the devkits officially provided to them. [1] https://en.wikipedia.org/wiki/Doctor_V64

not allegedly, iirc the turok devs used one

Re: Super Mario 64 for the PS1

#102

Post by deaddodo »

pmarin wrote: post #92
kibwen wrote: post #24

Earlier quoted context omitted.

Given that this is HN, I'm contractually obligated to mention that the GBA port is written in Rust: https://www.digitec.ch/en/page/the-impossible-port-super-mar...

That sound more like a demake than a port. Very cool anyway.

A demake would be a reimagining of a modern game into the style and aesthetics of the time. E.g. taking God of War and turning it into a 2D Shinobi-style platformer for Sega Genesis. Or turning Gran Turismo into a Mode7-style racer on SNES.

In this case, the creator wrote a custom 3D renderer and recreated the models/meshes to get as close of an approximation of the N64 experience onto the GBA.

I wouldn't call it a port necessarily ("recreation" seems more apt), but it's closer to that than a demake.

Re: Super Mario 64 for the PS1

#103

Post by baud147258 »

pezezin wrote: post #99
eru wrote: post #86

Earlier quoted context omitted.

The discs being black was a marketing gimmick, the actual magic was in the 'wobble'. > Nintendo had a hard enough time with preventing piracy and unlicensed games with the NES and SNES [...] Yes, so I'm not sure that the cartridge drawbacks bought them that much in terms of piracy protection? I agree that the PS1 had more piracy, but I'm not sure that actually diminished its success?

> I agree that the PS1 had more piracy, but I'm not sure that actually diminished its success? At least in my corner of the world (Spain), piracy improved its success. Everybody wanted the PSX due to how cheap it was, I think it outsold the N64 10:1.

it works if the console isn't sold at a loss, which isn't always the business model

Re: Super Mario 64 for the PS1

#104

Post by indigo945 »

pezezin wrote: post #98
indigo945 wrote: post #72

Earlier quoted context omitted.

The N64's CPU, with pretty much every single game released on the platform, is just sitting there idling along at maybe 30% load tops, and usually less than that. It's a 64 bit CPU, but Nintendo's official SDK doesn't even support doubles or uint64! Of course, Nintendo clearly cared about the CPU a lot for marketing purposes (it's in the console's name), but from a purely technological perspective, it is wasteful. Mo…

> So, getting a much smaller CPU would have been a big corner to cut, that could have saved enough resources to increase the texture cache to a useful resolution like 128x128 or so. How? The texture RAM (TMEM) is in the RSP, not in the CPU.

How is that relevant? "Resources" really just means money, which can be allocated between different items on the BoM at-will. The N64's chips are all (more or less) bespoke, so the functionality of each individual part is completely under Nintendo's control. Spend less on the CPU, and you suddenly have money left to spend on the RSP. (And on the RDP, which contains the TMEM -- it lives on the same chip as the RSP, but is a distinct thing. I assume you know this, but just to add to the discussion for readers - the RSP is the N64's SIMD coprocessing unit, which most games use to perform vertex shading, whereas the RDP is the actual rasterization and texturing hardware.)

Re: Super Mario 64 for the PS1

#105

Post by indigo945 »

malucart wrote: post #95
eru wrote: post #75

Earlier quoted context omitted.

> It's a 64 bit CPU, [...] Only really in the marketing material. It's a bit like calling a 386 with an arithmetic co-processor an 80 bit machine, when it was still clearly a 32 bit machine by all metrics that matter. However, I agree in general that the N64 CPU sits idle a lot of the time. It's overspecced compared to the rest of the system.

no, it really is a true 64 bit CPU. it's just that that fact is useless and it usually runs in 32 bit mode because games don't need that.

Yes. Although people like to point out that on the N64's CPU the external data bus is restricted to 32 bits, that's irrelevant in practice. The real limitation is the RDRAM's data bus, which is only 9 bits wide (of which the CPU uses 8 bits). The problem is that the rest of the system simply cannot match the overspecced CPU.

Re: Super Mario 64 for the PS1

#106

Post by president_zippy »

01HNNWZ0MV43FF wrote: post #40
bluedino wrote: post #33

Earlier quoted context omitted.

It looks pretty decent but seeing the texture warping and glitching reminds me of why I was team N64

The N64 definitely has the nicer GPU of the two. An N64 with a CD-ROM drive would have been amazing.

That "expansion pak" RDRAM upgrade was designed to give the N64DD enough buffer space so devs could continue using about 4MB of RAM for everything else, so I can't imagine how expensive the N64 would have been if they had to ship it with 8MB of RDRAM to maintain the same standard of visual quality and a 2X CD-ROM drive.

Then again, the good games would have been $50 instead of $70, and there would have been a lot more developers willing to pay $0.20 per unit to ship games than $20 per unit for the common 12MB and 16MB ROM chips.

However, I don't know if Ocarina of Time or Majora's Mask would have worked as well without that ability to load entire scenes in Not saying you're wrong, just that I'm glad things turned out the way they did because Ocarina and Majora's Mask likely could not have been done on a Saturn or PS1 beefed up with the N64's GPU.

I could be wrong, and some experienced romhackers could conjure up enough clever optimizations to make a faithful PS1 port of Ocarina of Time that doesn't have noticeable load times, but it would have been the result of years of research with no deadline pressure. I admit I'm just speculating, but not in a presumptuous and baseless way.

Re: Super Mario 64 for the PS1

#107

Post by whizzter »

zamadatix wrote: post #49
whizzter wrote: post #41

Earlier quoted context omitted.

Affine texture mapping is kinda jarring to look at, especially in this GBA port since there is no fixup with huge ground polygons drifting around. One of the listed features in the PS1 port in the OP article is tesselation to reduce the issues of the PS1 HW affine texture mapper, on the GBA you have some base cost of doing manual software texture mapping but also oppurtunities to do some minor perspective correction…

The GBA version does actually leverage dynamic polygon splitting in direct reference to how PS1 games used this approach https://www.youtube.com/watch?v=1Oo2CZWbHXw&t=271s I think the resolution makes it particularly rough though.

Almost felt like the second video (despite being older) looked better in terms of texture jumping, looking closer now the wandering textures actually seems more to be more of an clipping issue than directly perspective correction related.

Re: Super Mario 64 for the PS1

#108

Post by wk_end »

alexisread wrote: post #94
takantri wrote: post #56

Earlier quoted context omitted.

ClassiCube ( https://github.com/ClassiCube/ClassiCube ) exists, which is an open-source Minecraft Classic reimplementation with an N64 port among dozens of others. HN discussed it two years ago ( https://news.ycombinator.com/item?id=37518874 ). ClassiCube has a WIP GBA port, but according to commits it only hits 2 FPS as of now and is not listed in its README. On a related tangent, there's also Fromage, a separate Mi…

Related to this is the Atari Falcon port of Minecraft using a sparse voxel octree, might work for the GBA seeing as the Quake ports are similar performance-wise: https://www.youtube.com/watch?v=nHsgdZFk22M

Man, that DSP made the Falcon an insane piece of hardware for its time. Shame that it never found any real success.

Re: Super Mario 64 for the PS1

#109

Post by nmz »

ginko wrote: post #88
nmz wrote: post #68

Earlier quoted context omitted.

This is all subjective so I suppose I should add an IMO, Even back then many games were preferable on the N64 like megaman legends, what the PS1 offered that was superior was storage, which allowed for more music and FMVs, and also allowed for voice acting and probably why MGS is still talked about to this day, my guess is the lack of detail helps immersion the same way you would read a novel, and I imagine the PS1 w…

>Even back then many games were preferable on the N64 like megaman legends Huh, I generally see megaman legends cited as an example where the PSX version looks better due to the crisper textures. https://www.youtube.com/watch?v=J6lravGmPPQ

I stand corrected.

Re: Super Mario 64 for the PS1

#110

Post by nmz »

eru wrote: post #71
nmz wrote: post #68

Earlier quoted context omitted.

This is all subjective so I suppose I should add an IMO, Even back then many games were preferable on the N64 like megaman legends, what the PS1 offered that was superior was storage, which allowed for more music and FMVs, and also allowed for voice acting and probably why MGS is still talked about to this day, my guess is the lack of detail helps immersion the same way you would read a novel, and I imagine the PS1 w…

> [...] and I imagine the PS1 with its storage would've been the perfect vehicle for Visual Novels, but that still is not popular anywhere but Japan. I guess you can pretend that the JRPG or Resident Evil are Visual Novels with some action game play (or turn based combat) thrown in?

That's what I do with sons of liberty
Post reply on HN