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

71–80 of 116 posts

Re: Super Mario 64 for the PS1

#71

Post by eru »

nmz wrote: post #68
krispyfi wrote: post #54

Earlier quoted context omitted.

I had the opposite reaction. As someone who was on team PSX, the wobbly jank is pleasingly nostalgic. Didn't someone say that the limitations and artifacts of the obsolete media of the past become the sought-after aesthetics of the future?

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?

Re: Super Mario 64 for the PS1

#72

Post by indigo945 »

president_zippy wrote: post #60
klipklop wrote: post #47

Earlier quoted context omitted.

And a bit more texture memory!

The whole thing about the texture cache being the worst design decision in the N64 just gets parroted so much, but nobody can cogently explain which corner should have been cut instead to fit the budget.

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. Most of the actual compute is done on the RSP anyway. 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.

It should be noted, though, that the N64 was designed with multitexturing capabilities, which would have helped with the mushy colors had games actually taken advantage of it (but they didn't, which here again, the Nintendo SDK is to blame for).

Re: Super Mario 64 for the PS1

#73

Post by eru »

redox99 wrote: post #64
klipklop wrote: post #47

Earlier quoted context omitted.

And a bit more texture memory!

The RAMBUS speed is the main issue. The RDP can literally be stalled over 70% of the time waiting for memory. It's extremely flawed. They could have used SDRAM and it would perform so much better, and I believe the cost is around the same. If you wanted to cut something, cut the antialiasing. While very cool, it is a bit wasted on CRTs. Worst of all, for some reason they have this blur filter which smears the picture…

Would SDRAM have been faster and cheaper? Why did they pick RAMBUS?

Re: Super Mario 64 for the PS1

#74

Post by eru »

president_zippy wrote: post #60
klipklop wrote: post #47

Earlier quoted context omitted.

And a bit more texture memory!

The whole thing about the texture cache being the worst design decision in the N64 just gets parroted so much, but nobody can cogently explain which corner should have been cut instead to fit the budget.

You could have saved a lot of money by using CDs instead of cartridges.

If you sell games for roughly the same amount as before (or even a bit cheaper), you have extra surplus you can use to subsidise the cost of the console a bit.

Effectively, you'd be cutting a corner on worse load times, I guess?

Keep in mind that the above ignores questions of piracy. I don't know what the actual impact of a CD based solution would have been, but I can tell for sure that the officials at Nintendo thought it would have made a difference when they made their decision.

Re: Super Mario 64 for the PS1

#75

Post by eru »

indigo945 wrote: post #72
president_zippy wrote: post #60

Earlier quoted context omitted.

The whole thing about the texture cache being the worst design decision in the N64 just gets parroted so much, but nobody can cogently explain which corner should have been cut instead to fit the budget.

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…

> 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.

Re: Super Mario 64 for the PS1

#76

Post by eru »

vereis wrote: post #27
anthk wrote: post #20

Earlier quoted context omitted.

That was an issue in tons of PSX games.

yeah this is the distinctive ps1 look I think all games look like this, at least polygonal games

You can use lots of tricks to make your PS1 game not look like this. Or at least much less like this.

Re: Super Mario 64 for the PS1

#77

Post by eru »

anthk wrote: post #32
threethirtytwo wrote: post #12

Earlier quoted context omitted.

This is emulated as I'm sure the other videos are, but the PS1 back in the day had no way of running anything this crisp, so the emulator is `enhancing` it here. It's not an actual representation of what the game would have looked like.

CRT's smoothed out the image a little bit. Also, the screens were much smaller back in the day.

> Also, the screens were much smaller back in the day.

Not if you watch the video on your phone or iPad or laptop!

Actually, even most desktop pc monitors aren't bigger than people's TVs back then.

(Of course, TVs now are bigger than TVs back then. And desktop pc monitors are bigger than desktop pc monitors back then.)

Re: Super Mario 64 for the PS1

#78

Post by eru »

spicyjpeg wrote: post #26
mewse-hn wrote: post #18

Earlier quoted context omitted.

I see a lot of texture warp like you mentioned but I'm not seeing the geometry popping (wobble?) that was a hallmark of ps1 games, I'm guessing they're using soft floating point for the geometry and doing perspective-correct texture mapping would just be too expensive for decent frame rate

The PS1's GPU does not support perspective correction at all; it doesn't even receive homogeneous 3D vertex coordinates, instead operating entirely in 2D screen space and leaving both 3D transformations and Z-sorting to the CPU [1]. While it is possible to perform perspective correct rendering in software, doing so in practice is extremely slow and the few games that pull it off are only able to do so by optimizing f…

It's funny that the PS1 got so famous for 3d games, when its 'GPU' was entirely 2d.

I guess the main thing the console brought to the table that made 3d (more) feasible was that the CPU had a multiplication instruction?

Re: Super Mario 64 for the PS1

#79

Post by redox99 »

eru wrote: post #73
redox99 wrote: post #64

Earlier quoted context omitted.

The RAMBUS speed is the main issue. The RDP can literally be stalled over 70% of the time waiting for memory. It's extremely flawed. They could have used SDRAM and it would perform so much better, and I believe the cost is around the same. If you wanted to cut something, cut the antialiasing. While very cool, it is a bit wasted on CRTs. Worst of all, for some reason they have this blur filter which smears the picture…

Would SDRAM have been faster and cheaper? Why did they pick RAMBUS?

I think the main reason is that when they architected it, RDRAM seemed like the better choice based on price and bandwidth at that time, and they underestimated the performance issues it would cause (RDRAM has amazing bandwidth but atrocious latency).

By the time the N64 launched, SDRAM was better and cheaper, and they considered it was too late to make the switch. Allegedly SGI wanted to make changes but Nintendo refused.

Basically they made the wrong bet and didn't want to change it closer to release.

Re: Super Mario 64 for the PS1

#80

Post by eru »

malucart wrote: post #29
mewse-hn wrote: post #18

Earlier quoted context omitted.

I see a lot of texture warp like you mentioned but I'm not seeing the geometry popping (wobble?) that was a hallmark of ps1 games, I'm guessing they're using soft floating point for the geometry and doing perspective-correct texture mapping would just be too expensive for decent frame rate

it's not possible to have either subpixel vertex precision or perspective correct mapping with the PS1 GPU, as it only takes 2D whole-pixel coordinates for triangle vertices. (contrary to popular belief, N64 also uses exclusively fixed point for graphics btw, it just has subpixel units.) better tessellation can mitigate the perspective issues by a lot, but the vertex snapping is unsolvable, and it is indeed present h…

Interesting!

I guess you could pretend to have sub-pixel precision on the PS1, if you did it manually? Eg change the colours around 'between pixels' or something like that?

But that would probably get very expensive very soon.

Post reply on HN