F
Fanatic 64
Guest
People basically want all the graphic improvements currently available in HLE, regardless of accuracy.
Announcement: Cycle-accurate N64 development underway.
- Thread starter MarathonMan
- Start date
Nintendo Maniac
New member
MarathonMan has previously mentioned the possibility of a future OpenGL renderer after the software renderer is made, so I would imagine the soft-rasterizer will be purely for accuracy while the GL-rasterizer will be purely for visual prettiness and graphical enhancements.
It's more of a side effect being able to play it then actually going out to spend that much money for a single piece of software. Like for example I'm probably due for an upgrade anyway since my machine is like five years old. But yeah no one in their right mind would spend 350 dollars just to play n64 games in an accurate emulator. You could spend less then that on a real n64 with a flashcart.
Last edited:
Not sure where you are from but consoles per se stops being cool when they come out and it's pretty lackluster to have nes, snes, n64, gc, wii, wii2, sega etc, infront of the tv. So from a cost vs benefit standpoint, you have to see more then one or two emulators for the cost. Just switching inputs to the computers (with setup from above) is worth 350 usd to get away from.
And since most people probaly use their computers from something different then emulation, its' all value added.
If you see the natural progression from UltraHLE way back then when cpu power was scarce and now it's, almost, abundant. Low level emulation is the next step. Then however if it really needs to be cycle-accurate, pixel-accurate or something-else-accurate. I don't know.
I do however know that you seem pretty sure that the natural progression is wrong. And often when someone is sure, they are probaly wrong
And since most people probaly use their computers from something different then emulation, its' all value added.
If you see the natural progression from UltraHLE way back then when cpu power was scarce and now it's, almost, abundant. Low level emulation is the next step. Then however if it really needs to be cycle-accurate, pixel-accurate or something-else-accurate. I don't know.
I do however know that you seem pretty sure that the natural progression is wrong. And often when someone is sure, they are probaly wrong
OP
MarathonMan
Emulator Developer
I see people pretty excited about the ps4 and the steambox. Both aren't full on PCs though you could say the steambox is but that's only if you decide to install your own operating system. Otherwise it runs a cut down version of linux. You're right about people not wanting a billion consoles in front of the TV though. I was just using the real system as an example to spend less on a theoretical 350 dollar CPU for an n64 emulator.
these are core i3 tier, it would be great if your emulator ran smoothly on CPUs of this speed
Nintendo Maniac
New member
F
Fanatic 64
Guest
I actually remember byuu saying that's the reason he wouldn't make a N64 emulator, it wouldn't be remotely useable...
Nintendo Maniac
New member
I don't know how much multi-threading (if any) MarathonMan is using, but I do know that the bsnes emulation core is purely single-threaded.
Last edited:
ShadowFX
Guardian
That is why we should wait until this emulator is much further along in its development and in a usable state. If it actually runs with playable speeds on higher spec hardware, it would counter byuu's statement. It will be awhile I'm sure, though I'm still very excited.
OP
MarathonMan
Emulator Developer
squall_leonhart
The Great Gunblade Wielder
Why is byuu in the conversation again?
its a matter of fact (and stated by many emulator devs) that byuu has no idea how to properly implement code optimisations - unlike Marathonman who has been doing so from the start.
Retroarch guys have vocally commented on the fact Byuu does everything in such a non optimal way.
He's certainly no Gabest, thats for sure.
Last edited:
squall_leonhart
The Great Gunblade Wielder
That stuff is completely overrated
and totally voids your cpu warranty because it scours off the top of the cpu due to the microminerals.
Whoah, so basically everything fit in the 64 KB L1 cache/core?
That's impressive, to say the least.
OP
MarathonMan
Emulator Developer
- Thread Starter
- #279
VR4300 [total = ~36K]:
Caches (32KB)
CP0 Registers (160b)
Fault Data (96b)
Pipeline Latches (192b)
Registers (288b)
TLB (2192b)
RSP is smaller, since it doesn't have a TLB and only has 8KB of cache data. I'd reckon I'm well under 64K.
Thanks, it's my baby.