As the name implies, UltraHLE is ultra high level emulation, meaning it doesn't really emulate the hardware at all. Basically, since the N64 hardware is so complex, N64 game programmers used code libraries to access the hardware; as I understand it, many programmers even at different companies used the same libraries. Rather than actually emulate the hardware, UltraHLE just recognized when ROMs were calling the functions in these libraries, and returned the expected result. (Anything that didn't use those libraries, of course, wouldn't work.)Kerr Avon wrote:But why is N64 emulation still so far from perfect? I mean, fourteen years ago UltraHLE amazed us all by emulating Super Mario 64, Goldeneye, and Legend of Zelda: Ocarina of Time. On the PCs of the day (i.e. around a Pentium 1 233MHz for most people). But now, nearly a decade and a half later, with PCs much more powerful, we still haven't got near-perfect, or at leats very good, N64 emulation.
Jorpho wrote:Basically, since the N64 hardware is so complex, N64 game programmers used code libraries to access the hardware
What makes you think that there is? Sometimes there may be C&Ds, other times people just get sick of working on something. (The conspiracy-minded will suggest that there are cases in which people say they got a C&D just because they got sick of working on something and want a convenient excuse to save face, but I think that might be stretching it.)Joey_sw wrote:but why,there more C&D on N64 emulation
I remember back when Dr. Mario 64 wouldn't work correctly, simply because it was using a slightly unusual drawing technique that the video plugin standard at the time just wasn't able to accommodate.mr_bigmouth_502 wrote:One thing I've often wondered is, why haven't any emulators/graphics plugins been able to do the lighting effects in Perfect Dark? Surely, it can't be THAT hard. I mean, the rest of the game seems to work fine on most emus (if you have the computer for it), but for whatever reason they just haven't been able to nail that or the tranquilizer blur effect.
Just_Desserts wrote:Regarding a few of the things people brought up:Kerr Avon wrote:The (few) other game hacks I've tried all work great (Goldeneye X is brilliant!), but it turns out that the Super Mario 64 hacks won't work on any real N64 at all, as their code crashes real N64s, but doesn't crash N64 emulators, and the hacks were made using a program that was only tested on emulators.
Yes, that's correct, but ROM hacks that aren't tested on real hardware are a fairly common thing. Before bsnes came around, there were a ton of Super Mario World hacks floating around that didn't work on real hardware because zsnes and snes9x had (have?) faulty audio emulation. For what it's worth, these same Super Mario 64 hacks fail in the same way in MESS, as it has proper low-level emulation of the N64.leileilol wrote:MESS is on the right track toward this, but of course, since it's slow and underdeveloped, no one really cares.
Funny, considering as you people are complaining endlessly about high-level N64 emulators, one would think you'd be a bit more encouraging about what is ostensibly the only low-level emulator that actually runs games. It would be much faster if I could get a proper recompiler hooked up for the RSP, but my efforts in that regard are stymied by the fact that different N64 games have different requirements for how tightly the RSP and main CPU are synchronized. The RSP has the ability to request service from the CPU, and the CPU has the ability to request service from the RSP, and this symmetry is at odds with the whole principle behind dynamic recompilation, which is that you can recompile a large swath of a given CPU's code and run it in one go. This falls apart when you have two CPUs that can signal each other, as it's hard to tell when to end a given recompiled block in order to service the other CPU. Many games are just fine syncing 1-10 times per frame, others like World Driver Championship require extremely tight synchronization or the game will crash because the RSP or MIPS has not responded to the other in a sufficient amount of time.swaaye wrote:The RSP is a custom MIPS-like vector processor and typically handles audio and some graphics functions
No, that's not quite correct - the RSP is a MIPS processor. It has nearly all MIPS II opcodes, but instead of having an FPU available as COP1, the vector unit is available via COP1 instead. The other notable aspect is that it has a Harvard memory architecture rather than Von Neumann, as for simplicity's sake, SGI simply turned the cache RAM into actual program RAM, 4k for data and 4k for instructions.swaaye wrote:Anyway the reason I think it's not fully emulated is because the computational demands to do so are enormous even for today's hardware. It is full-featured 3D hardware, but it is not like any PC GPU/API, so it has to be done entirely on the CPU. MESS is going for this AFAIK.
That's correct. For a quick example of how the RDP differs from existing 3D hardware, consider the fact that triangles are not specified using 3D coordinates. Most if not all GPUs nowadays simply have a triangle defined by three triplets of floats - X0/Y0/Z0, X1/Y1/Z1, X2/Y2/Z2. By contrast, the RDP specifies the starting Y coordinate of each edge, and how much the edge moves for each Y coordinate. I can explain a bit more in-depth, but suffice it to say that you can draw a quad (with a flat bottom edge) by supplying degenerate values that would not actually result in an enclosed, 3-sided triangle. Goldeneye uses this to draw its sky with one triangle command instead of two.
Long story short, the only way to get accurate N64 emulation is by emulating both the RSP and main CPU, but this is at odds with the way dynamic recompilation works, so it will be rather difficult to work around this and still get acceptable performance.
Users browsing this forum: No registered users and 1 guest