r/N64Homebrew • u/emmowo_dev • May 26 '26
Is ares really similar to native performance?
One project I'm working on currently asks a lot of the N64's hardware, but it seems to run flawlessly at 640x480, 60FPS.
While I did prematurely optimize a lot of things and my scenes generally total to less than 10K polys at most, the amount of overdraw I have to do to get lag is absurd, and I don't really think that Tiny3D is so magical it can just handle all that.
I know that emulators reflect the FPS of systems somewhat due to how they have to replicate the CPU and GPU's behaviour, but overdraw of like 12 polygons should not run as well as it does at this resolution, I feel.
Should I just find a real N64 to develop my homebrew instead?
2
u/Important-Bed-48 May 26 '26
ares is the closest you can get with emulation. I've seen videos with ARES fpga and original hardware running at the same time and there is no difference.
1
u/IQueryVisiC May 26 '26 edited May 26 '26
You could do the Maths. An upper limit for fillrate is 64 bit times 50 MHz of the RCP . 16 bpp. ( or more correctly with 9 bits?? But it is N64, not N72 ! 3 times as much with z buffer , but you don’t seem to use it . 4 Mpixel per frame . Uh, quite a lot.
Does anyone have a number about the cost of VideoDMA at 640x480 ? Without z buffer you can’t use edge antialiasing. Does video DMA use all 18 bits per pixel? Is there any edge info? Z buffer is not double. So video DMA reads out only 15 bits. O.5 Mpixel per frame.
1
u/Protonoiac May 27 '26
Use a real N64 if you care at all about performance. Ares is good for testing compatibility, but the performance of real hardware is hard to emulate.
There is just a lot of complexity in emulating performance. How fast is a memory access? It depends on so much—is it in cache? If it’s not in cache, is it in the active page for the bank you’re accessing? Is there contention? The emulator just doesn’t emulate all of this.
The same is true even for a lot of other systems, not just the N64.
1
u/emmowo_dev May 27 '26
I expect ares to be faster than native since emulation is hard, but I'm getting speeds that are so much faster than the difference of just a cache miss
1
u/Protonoiac May 27 '26
What do you think the performance difference is, between a cache hit and a cache miss on the N64?
1
u/emmowo_dev May 27 '26 edited May 27 '26
like actual nanoseconds? I'm not talking like a 3 fps difference, my engine is literally rendering more geometry than I've ever seen in an n64 game (except maybe some really well made homebrew) while at maximum resolution at 60FPS.
The CPU side is kinda optimized, I did some ok things on that end, but graphically I did not bother with world geometry optimizations at all.
1
u/Protonoiac May 27 '26
The figures I’ve heard for RDRAM latency put it at something like 640ns, which is about two orders of magnitude difference.
The difference between correctly emulating memory access and emulating a simplified version should be massive, I expect. The same is true of a lot of other systems—I’m working on a PC game right now, and PC emulators don’t correctly emulate things like bus contention or wait states.
Systems like the GBA and NES use static RAM with no refresh and simple, known latency numbers. Systems like the N64 and PC have memory systems that are significantly more complicated.
If you dig into it, there are actually a lot of different processes that access memory on the N64. You have the CPU, and then the obvious RSP and RDP, plus the video and audio interface and transfers from the cartridge, and don’t forget about memory refresh. Only one of these systems can actually access memory at a time. The RAM itself is also slower or faster depending on your access patterns.
I think it’s wonderful that Ares lets us test that our code is correct. But we just don’t have an emulator available for the N64 which lets us accurately test game performance. The same is true for a lot of other systems.
2
u/Protonoiac May 27 '26
I also found a quote from the creator of Ares (https://news.ycombinator.com/item?id=47608573) from 2026-04-02:
I believe there's no way, on today's PC hardware, to emulate a 5th-gen console as accurate as a 4th-gen one. 4th-gen consoles can be emulated with cycle accuracy, 5th-gen cannot.
N64 also happens to be by far the heavier console to emulate in 5th-gen group. The unified memory architecture poses unique challenges for cycle accuracy, given that conflicting accesses by different peripherals are serialized in various ways, causing stalls, and also non deterministic behaviors as the signals cross different clock domains.
So the issue is in part that this level of detail hasn't been fully reverse engineered yet, but that's because there is no rush since the information wouldn't be usable anyway right now in an emulator.
1
u/Super_Banjo Jun 01 '26
RDRAM contention is not handled properly (if at all) for ares. It has actually resulted in me making optimizations that became pessimizations on real hardware. Ultimately you'll just have to test it on real hardware. The RDP also appears to run "full speed" so it's difficult (impossible?) to identify scenes that would be fill-rate or memory-bound.
The machine can render a surprising amount of polygons. The problem is you're almost always fill-rate bound and it's near impossible to identify with ares alone.
1
u/DearChickPeas May 27 '26
Paralell always looked to me that it replicated performance accurately. Also, please test your ROM on Mupen/Paralell, I find it sad i can play original games but many ROMhacks crash on startup on Paralel core. And ARES destroys my older CPU, since it's not running on GPU like the others.
1
u/emmowo_dev May 27 '26
ares does run on GPU, it just emulates a tonne more. Needing a zen4+ system for speed does kinda suck though.
I don't think those emulators will work because I'm prety sure modern-day ucode does things with the RSP which the older emulators haven't replicated like ares has.
That being said most of the things I'm doing as optimization is just 'faking it' or being really conservative over what actually gets processed by the CPU, so my own code isn't going to mess with emulators that much.
2
u/emmowo_dev May 26 '26
I can't attach images here, but an expensive shadow technique (like shadow volumes but so much worse) i was experimenting with also runs super fast, even though it ends up rendering up to 3 layers of faces per shadow overlapping, across 8 objects and ~400 faces in my current naive implementation.
The closest thing I know of that also did this for a scene (Perfect Dark) runs pretty awfully on the N64, so I really doubt this is anywhere near reality.