[Raion]

So Stormy, I had my 3d buddy sit down with me and review some issues with SMB and Zelda's code, or rather, why it runs fine on an N64, but not say an SGI.

The first thing is hardware differences. The N64 uses 4M of Rambus RDRAM than SIMM (Indy) or SDRAM (Most everything before Chimera) which means that a lot of raw C operations are simply not well optimized for the underlying hardware.

The second thing is that the Nintendo 64 simply does not operate on OpenGL rules. Unlike the Nintendo 64 most SGI hardware doesn't allow you to directly access the underlying graphics and instead abstracts it via IRISGL or OpenGL APIs. A lot of the matrix operations that occur in the code here are apparently much faster on the Nintendo 64. The other thing is that the Nintendo 64's GPU is R4k-based with a few 64-bit (MMX class) SIMD instructions, which are basically high performance floating point instructions. In a lot of cases b;the microcode (either Nintendo/SGI supplied or customized by the dev) modifies the behavior of certain parts of the RSP, the reality signal processor which controls things like audio and some DSP operations.

There are many other things that we went over, including lack of a native audio API which is why disabling the audio on Super Mario 64 improves performance. Native dmedia API would be much faster.

So how do we solve the first two? Well lucky us, the compiler can abstract away the first issue in some cases.

Both GCC and MIPSPro offer various kinds of operations that can optimize for the processor and/or platform. The main flag for GCC is -mabi, which has been discussed on here but I'll go over real quick. -mabi sets the microarchitecture instructions used by GCC. So for instance if you have an R10k, you can set that. However I need to put a warning here, -mabi has no effect above R10000, because the R12000 and up are essentially the same basic design only scaled up and with minor incremental improvements that are invisible to the compiler. Same with MIPSPro, -TARG:proc=r10000 is the highest it can go. It'll choke on any other higher because undefined behavior/flag. But I'm not sure if GCC has an equivalent to platform= subflag of -TARG. What this does is optimize for cache size and presumably other undocumented things which is useful. It might be possible to do this on GCC, not sure. It certainly does not have a direct comparison on x86 which is primarily what I was reading for documentation purposes here.

The question remains to me if platform flag can change or leverage the co-processors such as ice on the O2 which is vaguely similar to the N64's RSP or RCP, I forget which. GCC certainly cannot by itself but there's not but so much documentation about how to use those directly. So that's problem number one.

Problem number two is not solvable by a compiler abstraction, it gets into what I have been talking about before. You can crank compiler optimization levels up all the way until you start breaking things but the fundamental issue remains that it's simply not able to run efficiently when everything is basically a bunch of raw display and binary code for things like textures. For instance because we already know what's going on here we could convert the assets into a modern object format and find ways to store them in memory more efficiently so they can be more effectively pushed to the graphics chips when necessary, without unnecessary dma copying. You might for instance be able to optimize meshes so that they can be drawn more efficiently, open Morrowind has the same problem. The engine is quite superior in their case but the outdatedness of the architecture holds them back from achieving extremely good performance.

Guys who have more experience here are free to correct me and my friend, who basically was there explain certain things to me in a quick and cursory fashion.

But that's the long and short of it. You might be able to squeeze out a frame or two extra performance on MIPSPro out of the box but that's a hypothetical. Until these bottlenecks are solved there's not really a whole lot we can do.

[stormy]

Thanks for the reply but I wasn't talking about poor performance due to compiler issues and hardware design. There are some specific GL extensions not supported on Irix GL 1.1 or 1.2, these as far as I am aware are the primary concern with the graphical glitches. This is because the emulators renderer was written with OpenGL 1.3+ in mind, but as we know, the original N64 did not use OGL 1.3+, and Irix maxxes out at 1.2 on vPro and 1.1 on Mgras, so really we just need the renderer to be re-written to conform to OGL 1.1.

[Raion]

Fair enough in some respects, that's an equally difficult issue I can't exactly give a clear solution on.

[Raion]

Hey Stormy, I thought you'd find this video useful:

https://www.youtube.com/watch?v=t_rzYnXEQlE

A lot of the things that Kaze talks about here I didn't even know. Of course I disagree with some of his things like trying to remove crash safety as a general programming rule; but for a game application it probably is less of a problem.