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