[HN Gopher] Super Mario 64 for the PS1
       ___________________________________________________________________
        
       Super Mario 64 for the PS1
        
       Author : LaserDiscMan
       Score  : 123 points
       Date   : 2025-12-10 18:58 UTC (4 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | BugsJustFindMe wrote:
       | No screenshots :(
        
       | Larrikin wrote:
       | Are there any pictures or video of it running? I understand why
       | they are not on the GitHub page
        
         | ranger_danger wrote:
         | https://www.youtube.com/watch?v=6f92hKbz5Eo
        
           | zamadatix wrote:
           | For those that prefer pure gameplay to skip through
           | https://youtu.be/kkJWZlAjZp0
        
             | threethirtytwo wrote:
             | 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.
        
               | zamadatix wrote:
               | 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/comm
               | ent/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.
        
               | malucart wrote:
               | 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.
        
               | anthk wrote:
               | CRT's smoothed out the image a little bit. Also, the
               | screens were much smaller back in the day.
        
         | platevoltage wrote:
         | here's another video that showed good gameplay shots that I
         | happened to see last night.
         | 
         | https://www.youtube.com/watch?v=kscCFfXecTI
        
           | ginko wrote:
           | 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.
        
             | anthk wrote:
             | That was an issue in tons of PSX games.
        
               | vereis wrote:
               | yeah this is the distinctive ps1 look I think _all_ games
               | look like this, at least polygonal games
        
             | bluedino wrote:
             | It looks pretty decent but seeing the texture warping and
             | glitching reminds me of why I was team N64
        
               | 01HNNWZ0MV43FF wrote:
               | The N64 definitely has the nicer GPU of the two. An N64
               | with a CD-ROM drive would have been amazing.
        
             | LarsDu88 wrote:
             | 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.
        
           | zoeysmithe wrote:
           | 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.
        
             | kanzure wrote:
             | 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.
        
             | brailsafe wrote:
             | > 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.
        
       | ranger_danger wrote:
       | 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...
        
         | bena wrote:
         | They just finished a Star Fox 64 port as well
        
       | zamadatix wrote:
       | If you like this port, you may also enjoy this ground-up effort
       | to clone SM64 on the GBA https://youtu.be/nS5rj80L-pk
        
         | giancarlostoro wrote:
         | 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.
        
           | maximilianburke wrote:
           | Probably. There's Tomb Raider for the GBA via OpenLara:
           | https://www.youtube.com/watch?v=_GVSLcqGP7g
        
         | kibwen wrote:
         | 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...
        
         | no_wizard wrote:
         | 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.
        
           | throwaway314155 wrote:
           | > it is really hard to look at for me.
           | 
           | What were you expecting?
        
             | whizzter wrote:
             | 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).
        
         | ddtaylor wrote:
         | Does anyone know where the source to this is? It seems to have
         | been nuked.
        
       | amlib wrote:
       | > 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.
        
         | wk_end wrote:
         | 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.
        
         | mewse-hn wrote:
         | 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
        
           | wk_end wrote:
           | 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.
        
           | spicyjpeg wrote:
           | 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
        
             | LarsDu88 wrote:
             | Darn I posted the same thing in another thread
        
           | malucart wrote:
           | 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.
        
         | malucart wrote:
         | 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
        
       | mywittyname wrote:
       | 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
        
       | itomato wrote:
       | "Finally, Super Mario 32"
        
       | aussieguy1234 wrote:
       | And they said it could never be done
        
       | SpaceManNabs wrote:
       | 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.
        
       ___________________________________________________________________
       (page generated 2025-12-10 23:00 UTC)