Yes. But Proton has the advantage of working with well documented APIs on both sides. All the PS5 stuff is proprietary and has to be reverse engineered, that’s why it doesn’t work so well.
But why does that make a difference? Regardless of whether you reverse engineer an API or have the full documentation available, when you translate from it to something else, you’re building the same thing: an API translator. It doesn’t change whether it’s an emulator.
Traditionally, “emulator” refers to hardware emulation. APIs are reverse engineered, mocked, translated, etc. all the time, but we don’t call it “emulation”.
Even simply mimicking the behavior of a unified virtual memory space is not called “emulation”, unless there are hardware-specific quirks that need to be emulated (which may very well be the case for PS5 caches, I don’t know).
Ok, so if it’s translating to a reverse engineered API, it’s emulation. But if it uses the proprietary documentation and does the same exact translation it…wouldn’t be emulation anymore? What part are we saying is being emulated again?
You said it’s emulation because it handles ps5’s graphics APIs and unified memory. I noted that proton is also translating vulkan to another graphics API. You said it’s different because the api we’re targeting is proprietary and needs to be reverse engineered, implying that is the distinction. Right?
So then doesn’t that imply that if we did the same thing, but without needing to reverse engineer anything, it would now be an apples-to-apples comparison with what proton is doing?
Yes. But Proton has the advantage of working with well documented APIs on both sides. All the PS5 stuff is proprietary and has to be reverse engineered, that’s why it doesn’t work so well.
Maybe i am not understanding well but all this seems just a translation layer to me
The problem is that you don’t really know from what you’re translating.
But why does that make a difference? Regardless of whether you reverse engineer an API or have the full documentation available, when you translate from it to something else, you’re building the same thing: an API translator. It doesn’t change whether it’s an emulator.
Traditionally, “emulator” refers to hardware emulation. APIs are reverse engineered, mocked, translated, etc. all the time, but we don’t call it “emulation”.
Even simply mimicking the behavior of a unified virtual memory space is not called “emulation”, unless there are hardware-specific quirks that need to be emulated (which may very well be the case for PS5 caches, I don’t know).
Ok, so if it’s translating to a reverse engineered API, it’s emulation. But if it uses the proprietary documentation and does the same exact translation it…wouldn’t be emulation anymore? What part are we saying is being emulated again?
You don’t really need to emulate stuff, you need to reimplement the APIs, and those aren’t well documented, at least not publicly.
I didn’t say anything to that effect
I’m trying to understand, what is being emulated?
You said it’s emulation because it handles ps5’s graphics APIs and unified memory. I noted that proton is also translating vulkan to another graphics API. You said it’s different because the api we’re targeting is proprietary and needs to be reverse engineered, implying that is the distinction. Right?
So then doesn’t that imply that if we did the same thing, but without needing to reverse engineer anything, it would now be an apples-to-apples comparison with what proton is doing?
You asked if proton is doing basically the same thing and I said yes
I then explained why KytyPS5 doesn’t work as well, with issues like the one mentioned in the article
Ah I see. So what makes kytyps5 an emulator given that proton is emphatically not an emulator?