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.
Interesting, I'm wondering if the GBA could handle a light version of a Minecraft style game, but the N64 looks like it could be great at it too. I need to get me a SummerCart64 one of these days and experiment with my old N64.
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:
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 to lessen the worst effects (such as doing perspective correction during the clipping process).
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.
You’re misremembering. SM64 was fully textured, outside of specific models.
Also flat shading (vs. say gouraud shading) is isomorphic to the question of texture mapping, and concerns how lighting is calculated across the surface of the polygon. A polygon can be flat shaded and textured, flat shaded and untextured, smoothly shaded and textured, or smoothly shaded and untextured.
Amazing feat. I was a very happy owner of both consoles back in the day, and this port clearly shows how much the N64 brought that "SGI at home" feel in mid‑1996; at least until Voodoo 1 / QuakeGL, maybe even up to Unreal (Glide) or Sonic Adventure on DC?
I still remember gasping when I first saw the basically unattainable (for me) Japanese‑import N64 running Mario 64.
Such an interesting and varied gaming landscape back then; for example, the Wipeout experience on PSX was beyond the N64 port in that particular niche, for its own set of reasons.
Being a teenager, I honestly viewed the N64 (Ultra 64) as being an unstoppable force during the early news. We even had a 486 PC running Doom since the early-to-mid 90s. LOL. I couldn't wait to see what Doom would be like on the N64.
In typical fanboyism, I viewed the main SGI systems are the superior systems to the N64.. but they were for the office.. not the home. The other was Panasonic M2.
Of course.. either the N64 was released in the UK or not far away, I remember walking into PC World (a cool computer shop at the time) with a demo of Tomb Raider. I believe it was running a Voodoo1 card and the realisation kicked in. The N64 is already surpassed.
Wasn't long before we had a Voodoo2 card and the first game we played was a demo of Turok:Dinosaur Hunter. It was much better than the N64 version (which I owned)
Once I started playing GLQuake it was a PC master race.
It was at this point I snapped out being a Nintendo 'fanboy' and accept that hardware gets you so far... its the games that make a console.
I still think the N64 was a great console. Goldeneye, Ocarina of Time, etc. Great memories. Also got a Gamecube, Wii, and Switch.
As I got older and snapped out of the fanboyism, I realised the Playstation was a good console. I am on the fence with the Cartridge vs CD argument. There are cases for both. If we look at Mario 64, many aspects worked well on Cartridge. I guess faster load times and transition of music. With CD.. you have CD quality music and more variation of textures and level design (generally speaking)
Putting all the aside, Playstation is just as much capable of doing a good Super Mario 64 port despite the (many like) PS1 jaggy polygons.
> Tessellation (up to 2x) to reduce issues with large polygons
From the videos I've watched there is still insane amounts of affine transformation texture warping, is that because it's not enable or because 2x is not enough?
I guess they will need to also redo all level geometry to be more amenable to tesselation... I guess that's why many ps1 games had blocky looking levels.
right now there is basically no preprocessing of level polygons and they are copied as is, but when it is implemented, the largest polygons will be split to solve this
this is also necessary to fix the occasional stretched textures, as texture coordinates are also limited to a smaller range per polygon on PS1
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 for a special case (see for instance the PS1 version of Doom rendering perspective correct walls by abusing polygons as "textured lines" [2]).
A little more than just a multiplication instruction (the 68000, used in, say, the Sega Mega Drive, had one of those too). Have a look at https://www.copetti.org/writings/consoles/playstation/, and in particular, read about the GTE - it offered quite a bit of hardware support for 3D math.
Also, even though it didn't handle truly 3D transformations, the rasterizer was built for pumping out texture mapped, Gouraud shaded triangles at an impressive clip for the time. That's not nothing for 3D, compared to an unaccelerated frame buffer or the sprite/tile approach of consoles past.
It's not just a multiplication instruction. The CPU is equipped with a fixed-point coprocessor to accelerate the most common computations in 3D games, the geometry transformation engine [1], capable of carrying them out much faster than the CPU alone could. For instance, the GTE can apply a transformation matrix to three vertices and project them in 23 cycles, while the CPU's own multiplier takes up to 13 cycles for a single multiplication and 36 (!) for a division. Combined with a few other "tricks" such as a DMA unit capable of parsing linked lists (which lets the CPU bucket sort polygons on the fly rather than having to emit them back-to-front in the first place), it allowed games to push a decent number of polygons (typically around 1-3k per frame) despite the somewhat subpar performance of the cache-less MIPS R3000 derivative Sony chose.
If you have some basic familiarity with C, you can see both the GTE and the Z bucket sorting of GPU commands in action in the cube example I linked in the parent comment.
The README mentions that it uses both (new) fixed point as well as soft floating point.
Unless I'm mistaken, the PS1 just plain doesn't support perspective correction. All texture mapping is done in hardware using a very not-programmable GPU; there'd be no way to do perspective correction, decent frame rate or not, outside of software rendering the whole thing (which would be beyond intractable).
The common workaround for this was, as suggested, tessellation - smaller polygons are going to suffer less from affine textures. Of course that does up your poly count.
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 here. look closer and you might see it.
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.
It notes in the Known Issues section that "Tessellation is not good enough to fix all large polygons".
Maybe it just needs more tessellation or something else is going on, because you're right - even as someone who grew up on the PS1 and is accustomed to early 3D jank, it looks painfully janky.
The distorted textures and weird triangle clipping issues are exactly what you'd expect from an unoptimized port to a platform that doesn't support perspective correct texturing or depth testing.
Playstation rendered with affine texturing which made it impossible to get perspective correct rendering without hacks. The porting team ultimately did a very interesting hack where they would use polygons to render 1 pixel wide strips effectively simulating how non-hardware (that is CPU-based/integer) acclerated rendering was done on the PC.
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?
They are certainly sometimes a key part of the retro look that makes things nostalgic.
But even during the PSX era I found it distracting and annoying to look at so I can't say I have any nostalgia for it even now in the way I do for N64-style low-poly 3-D games or good pixel art.
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 with its storage would've been the perfect vehicle for Visual Novels, but that still is not popular anywhere but Japan.
Even with realism, ports to dreamcast were better overall and considering the latest port of Final Fantasy Tactics does not emulate any of its PS1 limitations, I don't think a lot of people strive/like the aesthetic.
As someone who was team N64 I do agree PSX has more of a "trademark look" compared to the N64 which is pretty much just a very limited version of a modern graphics rasterizer.
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 < 500ms. Diddy Kong Racing and Indiana Jones & The Infernal Machine relied on the ability to stream data from the cartridge in real time to smoothly transition between scenes/areas. DKR only used it in the overworld AFAIK, but it was still impressive.
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.
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.
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 horizontally. Luckily it can be deblured by appliying the inverse operation.
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.
OK, I also just read that basically Nintendo bet on ram bandwidth, but ignored latency.
A more general lesson: Nintendo bet on cutting edge, speculative technology with RDRAM, instead of concentrating on 'Lateral Thinking with Withered Technology'.
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).
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.
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.
I wonder what the maximum addressable memory of the N64 is?
Of course, even 32 bit are massively more than they actually need for the paltry amount of memory they actually get, even if you map ROM and various devices into the same virtual address space.
> 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.)
Realistically it wasn't even "We only have X dollars to spend". They needed the console to have a final budget and they really could have "just" added more transistors dedicated to that texture unit without significantly altering prices or profit.
But hardware was actively transitioning and what we "knew" one year was gone the next and Nintendo was lucky to have made enough right choices to support enough good games to survive the transition. They just got some bets wrong and calculated some tradeoffs poorly.
For example, almost everything Kaze is showing off, all the optimizations were technically doable on original hardware, but devs were crunching to meet deadlines and nobody even thought to wonder whether "lets put a texture on this cube" needed another ten hours of engineering time to optimize. Cartridges needed to be constructed by Christmas. A lot of games made optimization tradeoffs that were just wrong, and didn't test them to find out. Like the HellDivers 2 game size issue.
Sega meanwhile flubbed the transition like four different ways and died. Now they have the blue hedgehog hooked up to a milking machine. Their various transition consoles are hilariously bad. "Our cpu and rasterizer can't actually do real polygon rendering and can't fake it fast enough to do 3D graphics anyway. Oh, well what about two of them?"
You are right about the RSP/RDP distinction. My point is that removing transistors from one chip doesn't magically let you add more transistors to another chip, that's not how IC fabrication works. And the CPU was not a custom design, it was a VR4300 licensed by NEC from the original R4300.
Anyway, the real problem is that TMEM was not a hardware-managed cache, but a scratchpad RAM fully under the control of the programmer, which meant that the whole texture had to fit under a meagre 4 kB of RAM! It is the same mistake that Sony and IBM later made with the Cell.
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.
imho, Nintendo had a hard enough time with preventing piracy and unlicensed games with the NES and SNES and saw the PS1 got modded within a year, even with the special black coated discs to hide the tracks. There wasn’t a lot of optical/compact disc copy protection magic at the time and, cd-rs and writers started getting popular quickly as well. ps1 in 1994, n64 in 1996, backwards Dreamcast GD-ROMs and beginnings of larger discs and DVDS in 98.
> 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.
Its incredible to how compltely unwatchable modern youtube norms are, to me at least. I feel like youtubers now aim almost exclusively for the 12-18 demographic. I mean, this person is doing some kind of character or affectation instead of using a normal voice. Everything is some kind of grift or character or PR or persona now it seems. I understand they do this to get viewers, but its just depressing how much more content I'd enjoy if the PR gimmicks and lowest-common-denominator tricks were stopped.
I just saw techtips Linus interview Linus Torvalds and the constant manboying and bad jokes was just embarrassing and badly hurt the interview. I really wish people like this would turn it way, way down. I think we all love some levity and whimsy, but now those gimmicks are bigger and louder than the actual content.
Torvalds didn't hold back either though, so not sure what the complaint is... If you watch some WAN you'll see you're not getting some weird persona in that video, just the same guy with a bit of extra energy - which is just what you want to do for presentations / shows / whatever. It was a genuine experience.
To me this sounds like a computer-generated voice for obvious pro-privacy reasons for this kind of project. If it bothers you, then maybe work on better voice synthesis tech! I assume it sounds not-leading-generation because it was locally rendered but I could be wrong.
> I just saw techtips Linus interview Linus Torvalds and the constant manboying and bad jokes was just embarrassing and badly hurt the interview.
If you've been watching LTT for any amount of time, it wouldn't be surprising that that's just LTT Linus' nervous awkward style, he's just a person. The jokes can be cringe as hell, but I thought the video was great, I don't think most nerds would be any different in front of a camera.
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.
It doesn't really work right on "normal" PS1s yet, at least when it was making the rounds a few weeks ago, so you need either an emulator or modded/dev PS1 with more RAM to prevent crashes and most people won't have the latter https://www.reddit.com/r/psx/comments/1p45hrm/comment/nqjtdp.... Probably shared a few months to early.
But yeah, on a "real" PS1 it would be blockier due to lower res. The main rendering problems should be the same though.
nah, it's not even configured to use the extra RAM, though there is a compile option for that. seems like the freeze was some sort of bug in the tessellation code, but I'm rewriting that part, so the bug is gone now. it should be working fine on hardware after I publish the changes.
The 14" Nokia TV from my old bedroom disagreed a little :)
In the end if you reescaled the emulator window down to 320x240 or 640x480 with a 25% scanline filter on LCD's or a 50% in CRT, the result would be pretty close to what teenagers saw in late 90's.
Obligatory mention of Kaze, who has spent the past several years optimizing Mario64 using a variety of interesting methods. Worth a watch if your interests are at the intersection of vintage gaming and programming.
I was just about to post his video from August explaining how much excess ram mario 64 uses and where, which was the first serious mention I saw of a ps1 port being possible. He uses the ps1's smaller ram size as a kind of benchmark.
There is an explosion of decompilation projects spawning new ports, but was there something that enabled better decompilations? I see it across many retro games.
It has been enabled mainly by the the advent of streamlined tooling to assist with 1:1 byte-by-byte matching decompilations (https://decomp.me/ comes to mind), which allows new projects to get off the ground right away without having to reinvent basic infrastructure for disassembling, recompiling and matching code against the original binary first. The growth of decompilation communities and the introduction of "porting layers" that mimic console SDK APIs but emulate the underlying hardware have also played a role, though porting decompiled code to a modern platform remains very far from trivial.
That said, there is an argument to be made against matching decompilations: while their nature guarantees that they will replicate the exact behavior of the original code, getting them to match often involves fighting the entropy of a 20-to-30-year-old proprietary toolchain, hacks of the "add an empty asm() block exactly here" variety and in some cases fuzzing or even decompiling the compiler itself to better understand how e.g. the linking order is determined. This can be a huge amount of effort that in many cases would be better spent further cleaning up, optimizing and/or documenting the code, particularly if the end goal is to port the game to other platforms.
If you like this port, you may also enjoy this ground-up effort to clone SM64 on the GBA https://youtu.be/nS5rj80L-pk
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.
Interesting, I'm wondering if the GBA could handle a light version of a Minecraft style game, but the N64 looks like it could be great at it too. I need to get me a SummerCart64 one of these days and experiment with my old N64.
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 Minecraft Classic clone written for the PS1 (https://chenthread.asie.pl/fromage/).
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.
Probably. There's Tomb Raider for the GBA via OpenLara: https://www.youtube.com/watch?v=_GVSLcqGP7g
this guy builds a very similar engine https://www.youtube.com/@3DSage/videos
Does anyone know where the source to this is? It seems to have been nuked.
I'm slowly preparing it to be released, I just have a lot of IRL stuff going on!
No worries I was just making sure it didn't get lost to a takedown.
While this is cool, it is really hard to look at for me.
Still bravo! I know getting it working and complete is the real goal and it is commendable.
> it is really hard to look at for me.
What were you expecting?
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 to lessen the worst effects (such as doing perspective correction during the clipping process).
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.
I am probably misremembering but wasn’t super Mario 64 “flat shaded” ie no textures just colors?
You’re misremembering. SM64 was fully textured, outside of specific models.
Also flat shading (vs. say gouraud shading) is isomorphic to the question of texture mapping, and concerns how lighting is calculated across the surface of the polygon. A polygon can be flat shaded and textured, flat shaded and untextured, smoothly shaded and textured, or smoothly shaded and untextured.
(Too late to edit but did not mean “isomorphic”, meant “orthogonal”. Wrong smart person word trying to look smart, how embarrassing, sigh.)
Like a lot of N64 titles, there were many solid colour objects to save on RAM, but lots of things in the environment especially were textured too.
Nothing. I have zero expectations. Giving an honest take on what I saw is all.
Amazing feat. I was a very happy owner of both consoles back in the day, and this port clearly shows how much the N64 brought that "SGI at home" feel in mid‑1996; at least until Voodoo 1 / QuakeGL, maybe even up to Unreal (Glide) or Sonic Adventure on DC?
I still remember gasping when I first saw the basically unattainable (for me) Japanese‑import N64 running Mario 64.
Such an interesting and varied gaming landscape back then; for example, the Wipeout experience on PSX was beyond the N64 port in that particular niche, for its own set of reasons.
Being a teenager, I honestly viewed the N64 (Ultra 64) as being an unstoppable force during the early news. We even had a 486 PC running Doom since the early-to-mid 90s. LOL. I couldn't wait to see what Doom would be like on the N64.
In typical fanboyism, I viewed the main SGI systems are the superior systems to the N64.. but they were for the office.. not the home. The other was Panasonic M2.
Of course.. either the N64 was released in the UK or not far away, I remember walking into PC World (a cool computer shop at the time) with a demo of Tomb Raider. I believe it was running a Voodoo1 card and the realisation kicked in. The N64 is already surpassed.
Wasn't long before we had a Voodoo2 card and the first game we played was a demo of Turok:Dinosaur Hunter. It was much better than the N64 version (which I owned)
Once I started playing GLQuake it was a PC master race.
It was at this point I snapped out being a Nintendo 'fanboy' and accept that hardware gets you so far... its the games that make a console.
I still think the N64 was a great console. Goldeneye, Ocarina of Time, etc. Great memories. Also got a Gamecube, Wii, and Switch.
As I got older and snapped out of the fanboyism, I realised the Playstation was a good console. I am on the fence with the Cartridge vs CD argument. There are cases for both. If we look at Mario 64, many aspects worked well on Cartridge. I guess faster load times and transition of music. With CD.. you have CD quality music and more variation of textures and level design (generally speaking)
Putting all the aside, Playstation is just as much capable of doing a good Super Mario 64 port despite the (many like) PS1 jaggy polygons.
> Tessellation (up to 2x) to reduce issues with large polygons
From the videos I've watched there is still insane amounts of affine transformation texture warping, is that because it's not enable or because 2x is not enough?
I guess they will need to also redo all level geometry to be more amenable to tesselation... I guess that's why many ps1 games had blocky looking levels.
right now there is basically no preprocessing of level polygons and they are copied as is, but when it is implemented, the largest polygons will be split to solve this
this is also necessary to fix the occasional stretched textures, as texture coordinates are also limited to a smaller range per polygon on PS1
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 for a special case (see for instance the PS1 version of Doom rendering perspective correct walls by abusing polygons as "textured lines" [2]).
[1]: https://github.com/spicyjpeg/ps1-bare-metal/blob/main/src/08... - bit of a shameless plug, but notice how the Z coordinates are never sent to the GPU in this example.
[2]: https://fabiensanglard.net/doom_psx/index.html
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?
A little more than just a multiplication instruction (the 68000, used in, say, the Sega Mega Drive, had one of those too). Have a look at https://www.copetti.org/writings/consoles/playstation/, and in particular, read about the GTE - it offered quite a bit of hardware support for 3D math.
Also, even though it didn't handle truly 3D transformations, the rasterizer was built for pumping out texture mapped, Gouraud shaded triangles at an impressive clip for the time. That's not nothing for 3D, compared to an unaccelerated frame buffer or the sprite/tile approach of consoles past.
It's not just a multiplication instruction. The CPU is equipped with a fixed-point coprocessor to accelerate the most common computations in 3D games, the geometry transformation engine [1], capable of carrying them out much faster than the CPU alone could. For instance, the GTE can apply a transformation matrix to three vertices and project them in 23 cycles, while the CPU's own multiplier takes up to 13 cycles for a single multiplication and 36 (!) for a division. Combined with a few other "tricks" such as a DMA unit capable of parsing linked lists (which lets the CPU bucket sort polygons on the fly rather than having to emit them back-to-front in the first place), it allowed games to push a decent number of polygons (typically around 1-3k per frame) despite the somewhat subpar performance of the cache-less MIPS R3000 derivative Sony chose.
If you have some basic familiarity with C, you can see both the GTE and the Z bucket sorting of GPU commands in action in the cube example I linked in the parent comment.
[1]: https://psx-spx.consoledev.net/geometrytransformationengineg...
Darn I posted the same thing in another thread
The README mentions that it uses both (new) fixed point as well as soft floating point.
Unless I'm mistaken, the PS1 just plain doesn't support perspective correction. All texture mapping is done in hardware using a very not-programmable GPU; there'd be no way to do perspective correction, decent frame rate or not, outside of software rendering the whole thing (which would be beyond intractable).
The common workaround for this was, as suggested, tessellation - smaller polygons are going to suffer less from affine textures. Of course that does up your poly count.
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 here. look closer and you might see it.
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.
It notes in the Known Issues section that "Tessellation is not good enough to fix all large polygons".
Maybe it just needs more tessellation or something else is going on, because you're right - even as someone who grew up on the PS1 and is accustomed to early 3D jank, it looks painfully janky.
There was also just recently a Dreamcast port made, as well as Star Fox 64 for Dreamcast and also Mario Kart 64 for multiple platforms.
https://github.com/CharlotteCross1998/awesome-game-decompila...
They just finished a Star Fox 64 port as well
Are there any pictures or video of it running? I understand why they are not on the GitHub page
here's another video that showed good gameplay shots that I happened to see last night.
https://www.youtube.com/watch?v=kscCFfXecTI
The distorted textures and weird triangle clipping issues are exactly what you'd expect from an unoptimized port to a platform that doesn't support perspective correct texturing or depth testing.
John carmack complained about this same issue for the Playstation DOOM port: page 337 https://fabiensanglard.net/b/gebbdoom.pdf
Playstation rendered with affine texturing which made it impossible to get perspective correct rendering without hacks. The porting team ultimately did a very interesting hack where they would use polygons to render 1 pixel wide strips effectively simulating how non-hardware (that is CPU-based/integer) acclerated rendering was done on the PC.
That link gives a 403 for me, presumably because fabiensanglard.net disabled hotlinking.
For others who run into the same problem, the file can be accessed via https://fabiensanglard.net/gebbdoom/index.html#:~:text=High%... . (I've highlighted the link to click.)
It looks pretty decent but seeing the texture warping and glitching reminds me of why I was team N64
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?
They are certainly sometimes a key part of the retro look that makes things nostalgic.
But even during the PSX era I found it distracting and annoying to look at so I can't say I have any nostalgia for it even now in the way I do for N64-style low-poly 3-D games or good pixel art.
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 with its storage would've been the perfect vehicle for Visual Novels, but that still is not popular anywhere but Japan.
Even with realism, ports to dreamcast were better overall and considering the latest port of Final Fantasy Tactics does not emulate any of its PS1 limitations, I don't think a lot of people strive/like the aesthetic.
> [...] 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
>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.
As someone who was team N64 I do agree PSX has more of a "trademark look" compared to the N64 which is pretty much just a very limited version of a modern graphics rasterizer.
psx is r3000, n64 is r4300 a much faster and capable cpu.
Personally I'd take it over the N64s muddy textures, the playstations wobbly but I can at least make out what something's supposed to be
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 < 500ms. Diddy Kong Racing and Indiana Jones & The Infernal Machine relied on the ability to stream data from the cartridge in real time to smoothly transition between scenes/areas. DKR only used it in the overworld AFAIK, but it was still impressive.
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.
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
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 horizontally. Luckily it can be deblured by appliying the inverse operation.
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.
Thanks!
OK, I also just read that basically Nintendo bet on ram bandwidth, but ignored latency.
A more general lesson: Nintendo bet on cutting edge, speculative technology with RDRAM, instead of concentrating on 'Lateral Thinking with Withered Technology'.
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).
> 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.
I wonder what the maximum addressable memory of the N64 is?
Of course, even 32 bit are massively more than they actually need for the paltry amount of memory they actually get, even if you map ROM and various devices into the same virtual address space.
> 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.)
Realistically it wasn't even "We only have X dollars to spend". They needed the console to have a final budget and they really could have "just" added more transistors dedicated to that texture unit without significantly altering prices or profit.
But hardware was actively transitioning and what we "knew" one year was gone the next and Nintendo was lucky to have made enough right choices to support enough good games to survive the transition. They just got some bets wrong and calculated some tradeoffs poorly.
For example, almost everything Kaze is showing off, all the optimizations were technically doable on original hardware, but devs were crunching to meet deadlines and nobody even thought to wonder whether "lets put a texture on this cube" needed another ten hours of engineering time to optimize. Cartridges needed to be constructed by Christmas. A lot of games made optimization tradeoffs that were just wrong, and didn't test them to find out. Like the HellDivers 2 game size issue.
Sega meanwhile flubbed the transition like four different ways and died. Now they have the blue hedgehog hooked up to a milking machine. Their various transition consoles are hilariously bad. "Our cpu and rasterizer can't actually do real polygon rendering and can't fake it fast enough to do 3D graphics anyway. Oh, well what about two of them?"
You are right about the RSP/RDP distinction. My point is that removing transistors from one chip doesn't magically let you add more transistors to another chip, that's not how IC fabrication works. And the CPU was not a custom design, it was a VR4300 licensed by NEC from the original R4300.
Anyway, the real problem is that TMEM was not a hardware-managed cache, but a scratchpad RAM fully under the control of the programmer, which meant that the whole texture had to fit under a meagre 4 kB of RAM! It is the same mistake that Sony and IBM later made with the Cell.
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.
imho, Nintendo had a hard enough time with preventing piracy and unlicensed games with the NES and SNES and saw the PS1 got modded within a year, even with the special black coated discs to hide the tracks. There wasn’t a lot of optical/compact disc copy protection magic at the time and, cd-rs and writers started getting popular quickly as well. ps1 in 1994, n64 in 1996, backwards Dreamcast GD-ROMs and beginnings of larger discs and DVDS in 98.
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
See https://news.ycombinator.com/item?id=46227453
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.
Its incredible to how compltely unwatchable modern youtube norms are, to me at least. I feel like youtubers now aim almost exclusively for the 12-18 demographic. I mean, this person is doing some kind of character or affectation instead of using a normal voice. Everything is some kind of grift or character or PR or persona now it seems. I understand they do this to get viewers, but its just depressing how much more content I'd enjoy if the PR gimmicks and lowest-common-denominator tricks were stopped.
I just saw techtips Linus interview Linus Torvalds and the constant manboying and bad jokes was just embarrassing and badly hurt the interview. I really wish people like this would turn it way, way down. I think we all love some levity and whimsy, but now those gimmicks are bigger and louder than the actual content.
Torvalds didn't hold back either though, so not sure what the complaint is... If you watch some WAN you'll see you're not getting some weird persona in that video, just the same guy with a bit of extra energy - which is just what you want to do for presentations / shows / whatever. It was a genuine experience.
To me this sounds like a computer-generated voice for obvious pro-privacy reasons for this kind of project. If it bothers you, then maybe work on better voice synthesis tech! I assume it sounds not-leading-generation because it was locally rendered but I could be wrong.
> I just saw techtips Linus interview Linus Torvalds and the constant manboying and bad jokes was just embarrassing and badly hurt the interview.
If you've been watching LTT for any amount of time, it wouldn't be surprising that that's just LTT Linus' nervous awkward style, he's just a person. The jokes can be cringe as hell, but I thought the video was great, I don't think most nerds would be any different in front of a camera.
Thanks for the link!
The first comment is pretty funny:
> Finally, Super Mario 32.
https://www.youtube.com/watch?v=6f92hKbz5Eo
For those that prefer pure gameplay to skip through https://youtu.be/kkJWZlAjZp0
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.
It doesn't really work right on "normal" PS1s yet, at least when it was making the rounds a few weeks ago, so you need either an emulator or modded/dev PS1 with more RAM to prevent crashes and most people won't have the latter https://www.reddit.com/r/psx/comments/1p45hrm/comment/nqjtdp.... Probably shared a few months to early.
But yeah, on a "real" PS1 it would be blockier due to lower res. The main rendering problems should be the same though.
nah, it's not even configured to use the extra RAM, though there is a compile option for that. seems like the freeze was some sort of bug in the tessellation code, but I'm rewriting that part, so the bug is gone now. it should be working fine on hardware after I publish the changes.
Cool work man - can't wait to try it out when the fixes land!
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.)
The 14" Nokia TV from my old bedroom disagreed a little :)
In the end if you reescaled the emulator window down to 320x240 or 640x480 with a 25% scanline filter on LCD's or a 50% in CRT, the result would be pretty close to what teenagers saw in late 90's.
For a video, yes.
Though I suspect for interactive use, CRTs might have had better latency?
Lots of people complaining that this has warped textures and whatnot - but come on! This is amazing!
Obligatory mention of Kaze, who has spent the past several years optimizing Mario64 using a variety of interesting methods. Worth a watch if your interests are at the intersection of vintage gaming and programming.
https://www.youtube.com/@KazeN64
I was just about to post his video from August explaining how much excess ram mario 64 uses and where, which was the first serious mention I saw of a ps1 port being possible. He uses the ps1's smaller ram size as a kind of benchmark.
I did not expect it to happen so soon.
https://www.youtube.com/watch?v=oZcbgNdWL7w - Mario 64 wastes SO MUCH MEMORY
I've been working on it since mid 2024, so that video was a funny coincidence :)
He's great. (And ripped!)
I wonder what someone who has PS1 knowledge equivalent to Kaze's N64 knowledge could do on that console---perhaps using Mario 32 as the benchmark.
(Mario 32 = Mario 64 on PS1.)
There is an explosion of decompilation projects spawning new ports, but was there something that enabled better decompilations? I see it across many retro games.
It has been enabled mainly by the the advent of streamlined tooling to assist with 1:1 byte-by-byte matching decompilations (https://decomp.me/ comes to mind), which allows new projects to get off the ground right away without having to reinvent basic infrastructure for disassembling, recompiling and matching code against the original binary first. The growth of decompilation communities and the introduction of "porting layers" that mimic console SDK APIs but emulate the underlying hardware have also played a role, though porting decompiled code to a modern platform remains very far from trivial.
That said, there is an argument to be made against matching decompilations: while their nature guarantees that they will replicate the exact behavior of the original code, getting them to match often involves fighting the entropy of a 20-to-30-year-old proprietary toolchain, hacks of the "add an empty asm() block exactly here" variety and in some cases fuzzing or even decompiling the compiler itself to better understand how e.g. the linking order is determined. This can be a huge amount of effort that in many cases would be better spent further cleaning up, optimizing and/or documenting the code, particularly if the end goal is to port the game to other platforms.
Perhaps AI has made it easier?
AI
Aye, AI.
AI what?
More people have discovered Ghidra.
Cool stuff! Make sure to also check: https://sm64coopdx.com Recently we are having tons of fun with this with a couple of friends.
No screenshots :(
this is the devil's work. nicely done. what stood out to me is that one of the known issues is the pause menu not working. wonder why that is.
edit: whoever did the gameplay video is really good at mario n64. They were playing to and reacting to stuff that had rendered very late, if at all.
“Finally, Super Mario 32”
And they said it could never be done