F
Fanatic 64
Guest
Couldn't you add an option to output at 320x240?
Couldn't you add an option to output at 320x240?
OH! I forgot to mention, I was concerned about the bit of assembly you used since I had previously mentioned in regards to SSE that x86-lock in isn't really the best of ideas nowadays...especially with an accuracy-focused emulator that could be useful for who knows how many years to come.
There are extremely high-end CPUs that are PowerPC-based, but said high-end CPUs are not used in consumer products. Nintendo also seems to be commited to the PowerPC architecture for consoles, so I wouldn't be surprised if in 10-20 years from now they're still using PowerPC based CPUs.No other architecture has a processor even remotely capable of running the simulator at it's target speed at the moment, so I'm not concerned.
Either way, being a simulator, it would be useful even for years and years to come since you can't ever surpass the accuracy of 100%. Remember, this is N64 emulation we're talking about, where the most accurate video plugin is designed for a GPU released over 10 years ago - I would think by now that requiring a specific hardware architecture would be something to shy away from and instead putting that effort into just optimizing for a specific architecture would be preferred (optimized != required).
But is that not optimization for x86? I'm not against that at all, but it shouldn't be something that actually prevents other architectures from running CEN64, even if it's at a tenth of the speed.Yes, but I think you're underestimating the amount of tuning that has to go into even, say, a *fast*, modern Intel processor to get this thing churning at full speed. The only reason that I've been able to pull this off so far is by hammering down everything so tightly that it all just clicks... eliminating SSE support could seriously hamper RSP performance.
Regardless, the simulator is implemented in such a way that you can disable SSE support at any time by simply removing the -DUSE_SSE flag in the RSP module (though there's no faithful ANSI implementation of most instructions, yet).
In 20 years I don't think it'd be ridiculous to say we'd have smart phone-like devices that are at least as fast as Ivy Bridge, but could very well be even faster. Considering their history of not being x86, they'd most likely be ARM-based. And considering the inactive history of N64 emulation, I would not be surprised if between now and then nobody created another accuracy-focused N64 emulator (outside of Nintendo themselves) that is compatible with ARM even though the hardware would be fast enough to handle it.
Even just having CEN64 be able to run, even if unoptimized, would make a much greater chance of such a future to not happen, especially since speed optimizations for a specific architecture is something that many more people will be familiar with vs people that could make an accuracy-focused N64 emulator from scratch.
And this is without considering the fact that such a future ARM CPU may be so fast that it could run CEN64 at full speed even without optimizations. Again, being a simulator, it by nature will have lasting value for years to come.
I still don't think you're understanding fully how much of a difference these optimizations are making.
Is there any way to test this code? I might want to try implementing a C version sometime.again; somebody just needs to implement the non-SSE version before it's usable. If you compile with debugging macros, the simulator will emit warnings everytime instructions are executed that are lacking support.
Is there any way to test this code? I might want to try implementing a C version sometime.
At the risk of beating a dead horse but in the interest of clarification...so you ARE saying you have a full C implementation without the x86-exclusive code?Excellent! Iconoclast/cxd4@github already has a faithful C ... implementation of everything.
At the risk of beating a dead horse but in the interest of clarification...so you ARE saying you have a full C implementation without the x86-exclusive code?
I dislike vendor lock-in just as much is the next guy, which is why I provided a mechanism to still fall all the way back to ANSI C, or allow programmers to insert intrinsic for other architectures.
The cracks just need to be filled in.
Ah, ok. I presume this is what Guru64 was alluding to?
Alright, we finally got that all cleared up now.
In other news, I noticed that the video you posted didn't have a framerate counter...how are you able to tell how close you are to running at fullspeed?
Speaking of eyeballing and performance, I was just thinking... wouldn't rendering in high-res mode (whether enabled in-game or forced via emulator) require considerably more CPU cycles since everything is software and therefore 4 times the pixels, or is the rendering of graphics nothing compared to the CPU cycles being spent on emulating everything?