Genuine question - under the hood is this more of an emulator like PCSX2 or a compatibility layer like Wine?
Since the PS4 is more or less an x86 computer, I imagine most of the hard work would be implementing the system/graphics APIs of the PS4. Or are there major hardware differences between an x86 PC and the PS4 that also need to be handled?
they must have a shader recompiler infra, because all the shaders are shipped precompiled directly for the platform on consoles. so it's a good bit more than what wine does, at the very least in that regard.
For PC games and applications, Direct3D shaders are supplied in a high-level shader language (not-so-coincidentally called High-Level Shader Language), given that there is no standard GPU architecture on Windows PCs. Wine does still need to translate that to the target graphics library, as well as all the drawing calls themselves, though.
There are also some considerations regarding texture compression, I believe, which is a function usually performed in dedicated GPU hardware, and not all GPUs support all formats.
Not a developer in the field, but I believe generally the HLSL isn’t packaged in the game. Instead an intermediate format called DXIL is produced at build time from the HLSL, and that’s what is packaged.
Ah, sorry, then I carried over an assumption from OpenGL (where GLSL is actually what's packaged, or at least was a couple of years ago when I last looked at it).
In any case, that intermediate representation is probably still easier to compile to hardware-specific code, especially if the hardware has a Direct3D implementation. That's what it's designed for, after all!
Technically true but if you are going to use SPIR-V you might as well jump over to Vulkan. Do you know of any OpenGL games that actually ship SPIR-V? I can imagine it getting used in CAD applications with huge legacy OpenGL code bases but for Games OpenGL+SPIR-V doesn't really have a good use case.
When one tries to really nail down the exact, precise, 100% accurate definition of "what an emulator is", one finds it is like nailing jello to the wall.
I've seen several people online discover what the idea of an emulator is, and then they'll say in amazement "so we could do this and that and the other?", and the answer, no matter what it is they propose, is "yes, someone's done that". Recompile the code entirely into another assembler? Partially do so? JIT it? Ship specific patches for specific content? Emulate gates? Rewrite on the fly? Shim things slightly to change what functions are loaded? All that and more has been done. And even if you draw a sharp line through those things, all the combinations you can think of have also been done, and how will you draw the line through that?
I think one of the best ways of thinking about it is that there really isn't any such thing as an emulator. There's just numbers, and they need an interpreter and the ability to reach out to some set of externally-defined functionality, and there is a profound sense in which you have to have some particular hardware manifestation of an interpreter and some functionality to get anywhere, but that particular manifestation is a lot less important than people think. This has only become more true in a world where your CPUs are already not actually executing assembler opcodes anymore, and your OS is already shimmed away from the hardware in another level, and the OS is wrapping your program in yet more abstraction before it even runs a single instruction, which may well include providing a choice of which sets of "externally-defined functionality" the numbers can ask for (different Windows subsystems, etc.). Even the "base system" has a lot of "emulators" in it nowadays. It's emulators almost all the way down! Which suggests that rather than being special, they're actually quite fundamental, and sure, sometimes you need a greater translation layer between this program written with these numbers and this particular chunk of hardware and sometimes you need less, but it's a lot less a distinction of "kind" than you might think.
This is not the only way to think about it; there are certainly valid perspectives from which "emulators" exist, e.g. as a distinct category in a software catalog they're sensible. We all know what that means. But for your own understanding of how the world works, the previous paragraph has a lot to recommend it.
Indeed, it was a backronym. I'm glad they finally got rid of it, because it was untrue, and because it continues to be the source of unpleasant exchanges online.
Wine doesn't emulate hardware, but it absolutely does emulate the Windows runtime environment. (In fact, it wouldn't work very well if it merely implemented APIs based on a spec instead of emulating observed behavior, since some of the bits required for compatibility are undocumented.)
Unfortunately, that phrase was in fashion at a time when a lot of people first discovered Wine, so there is now a generation of enthusiasts incorrectly chiding people who refer to Wine as emulation. And, of course, others who see this happen and don't know any better sometimes go on to perpetuate it themselves. Makes me sad every time it crosses my path.
On a 4090 with most of the shading still not implemented/broken :) . Probably won't be 120+ fps once everything is correctly emulated on a "normal" machine. Still huge tho
It will be 100+ fps on a current mid-tier system easily, because this is not hardware emulation.
Most emulators need to implement/compile a whole different architecture to x86, even if similar to x86 it causes issues because cache gets filled faster, more memory lookups, etc.
PS4 doesn't need to emulate almost anything hardware wise, the CPU is a standard x86 and the GPU is a modified radeon. Similar to how wine can get the same or better performance on linux than windows, the ps4 "emulators" will achieve performance parity because they're not emulating anything, they're just reimplementing the core PS4 libraries. That said there are some differences in hardware, the big one being the PS4s unified memory, but it shouldn't be much of a problem, there's also the usual shaders need to be recompiled, etc.
So it's ok to get hyped for high performing bloodborne gameplay on PC with affordable PCs :)
Amazing. This made me want to play BB on my old PS4 that's gathering dust. Then, I remembered it's 30FPS locked, and has pretty bad loading times. I'll wait for the emulator, or a remaster, whatever comes first I guess :))
Apparently someone made it run at 60fps on a PS5 devkit, and it's frustrating because I actually have access to one but there are no instructions anywhere so I can't experience the beauty of Bloodborne in 60fps :-(
The PS4 Pro struggles to run this game at 60fps due to a CPU bottleneck. On the other hand, PS5 runs it remarkably stably at 60fps and even 120fps is decent.
Don't worry, I think it's only a matter of time before you'll be able to do this. Either through an official PS5 remaster, an official PC release (less likely) or via some funky unofficial emulation.
Even though it's only 30fps the game is quite beautiful for being 9 years old and running on a previous gen console.
it is something to worry about if you care about playing the original. I'm only interested in straight ports with minimal QOL features like 60fps(or unlocked if viable), higher resolution and controller rebinding.
I haven't played a single remaster that I preferred to the original game. I'm fine with remasters existing, but only if faithful ports are made available as well.
Those are remakes and not remasters. Different beast.
The trouble with remasters is they're usually farmed out to third-party devs who don't always give it the same attention to detail as the original developers. A prime example would be Dark Souls Remastered, which actually makes some of the graphics worse compared to the original PC version.
The line between remaster and remake is a blurry one.
Nier Replicant ver.1.22... isn't officially called either a remake or a remaster, and a convincing case could be made for either. Yet it changes more than Demon's Souls PS5 does.
It is easy to find criticism of Demon's Souls' remaster's art style by entering that term into your favourite search engine. This isn't "considered" true by "almost everybody".
Regardless of any person's opinion on the changes, being substantially different is enough reason that it isn't a suitable substitute for the original.
Lance McDonald (@manfightdragon) is the someone, I don't think the patch is shared publicly though. He plays it sometimes on his Twitch channel. I've seen LobosJr play the 60 fps version too.
Not sure whether you know about it or not, so: you have to do a little bit of work, but it _does_ run in 4k on PCs. Do some googling, you'll find all you need.
It is really depend on the hardware you want to make the emulator. Usually there are 2 kind:
1. Emulate the whole system.
2. Emulate the system API.
The first one you write the code to emulate the CPU of target system like OP code interpreter (e.g. NES). The second one you write the code to re-implement the API of the target system (e.g. Wine). For the second one you may need to write a JIT compiler if the target system use a different CPU architecture (e.g. PS3).
Most modern console emulator are the later one because how the modern console work is similar to how the PC work. It have an OS kernel and a user-mode libraries for applications.
For the latter one there are 2 kind of it. The first one is emulate the user-mode libraries and the second one is re-implement the console kernel and reuse the system libraries from the console itself.
> Most modern console emulator are the later one because how the modern console work is similar to how the PC work. It have an OS kernel and a user-mode libraries for applications.
And additionally because the past couple of console generations have had x86-64 CPUs, there's no need to do full instruction translation/emulation—something like Wine would suffice.
An average programmer can probably get an emulator for that running in a weekend, and there are lots of guides and documetnation out there for the opcodes and similar.
NES / Gameboy / GameGear / similar are probably well-documented, but they will be harder at least because the processors have more opcodes you have to care about.
Yeah CHIP8 is a simple enough system that i even made two emulators (one in DOS and one in Windows) and an assembler back in 1999-2000 or so when i was in highschool and could barely put eight bits together to form a byte.
Also somehow for some reason i was convinced back then that mobile phones in the future will have a CHIP8 emulator to play games :-P. Sadly(?) they got Java instead.
I would say this is a good place to start. I did a Game Gear emulator in a single night with a buddy, having never written one before, just for the lulz.
You are bound to have an awesome game you can find on an 8-bit system and it's really fun trying to get to the point where you can play the game: getting the logo to appear, getting the title screen up, getting the sprites working, adding controls etc.
There are loads of resources online on how to write a gameboy emulator, these use a straightforward enough architecture that it's pretty easy to follow. I'd recommend starting there in your language of choice.
Well no, I said there are loads of tutorials in the language of your choice - I have no idea what language OP is proficient in - my personal preference is for C++, but would that be useful here? No idea.
>>The way you go about writing a N64 emulator is vastly different from GB
I specifically said "There are loads of resources online on how to write a gameboy emulator", what does N64 has to do with this?
Have a data structure for CPU registers.
Have a data structure for memory.
Have a data structure for i/o.
Read a series of instructions that are being emulated.
Create a series of rules as to how those instructions interact with CPU, memory, i/o, in a mutable fashion. A long if/then/elif/elif/elif/elif/else type loop, or switch case type loop, if you will.
Create bridges between particular pieces of memory and system output: video, sound, controllers.
That's most of it in the classic case at least.
Now you have an emulator.
The "big league" emulators work differently. They may be simple compilers. Instead of compiling C code or java code, they compile machine code from system A to system B. A transpiler. This affords speed beyond the simple case. Speed, however, is only necessary if the machine running the emulator is weak, or if the machine being emulated is strong.
This looks like an interesting project to follow! Given the current lack of a portable option from Sony it would be interesting to see how this might run on the Steam Deck.
Depending on how the emulation is done PS4 might have a slightly easier time. AFAICT from some time ago i checked it, PS3 is probably the hardest architecture of all to emulate with RPCS3 basically using LLVM to "compile" code fragments from PS3's CPU to native code.
I'd expect running x86 code written to run on an AMD APU with a Unix-based OS in another AMD APU with a Unix-based OS to be a bit easier, probably with some VM involved (even Xemu, the original Xbox emulator, is basically a QEMU PC configuration with some Xbox-specific hardware for the GPU and audio).
Emulating a PS3 is significantly harder than emulating a PS4, since on the PS3 you need to convert from the Cell architecture, whereas the PS4 is already x86.
I think this too. My perception of the PS4 is it's just a PC in a box running FreeBSD (or something). I don't think there is any custom architecture at all. Much like a steam deck, which can already run some first party PS4 games just fine (e.g. Death Stranding). Would any emulation even be required?
They have custom graphics APIs (and semi custom GPUs) which makes graphics translation one of the hardest parts.
The graphics systems also assume shared memory which is not a given elsewhere.
There are sometimes also some extra CPU instructions if it benefits the console that may not be prevalent, and require some translation.
And it’s even more different when you get to the PS5 era where the systems have some very critical hardware systems like kraken decompression and direct storage which don’t have super prevalent equivalents.
>And it’s even more different when you get to the PS5 era
Do you think a PS4 emulator should be 90% of the way to a PS5 emulator being that they both use x86, AMD GPU and NVM/X?
ps. I argued with you here[0] about Vulkan on MacOS, and after reading more about graphics APIs and game engines I can say I was wrong about some of what I said eg. "studios are generally using modified versions of UE so my guess is that means they are generally making low level changes sometimes, and so it makes sense to me that they sometimes may write their Dx/ Vulkan code for different things sometimes" which after researching, studios do heavily modify Unreal, but they do not seem to touch the rendering APIs. (with some exceptions like here[1]). Also "Adding an extra platform like MacOS [on UE] is not simply clicking a button" which I simply assumed is true but have no evidence for.
I don’t think the PS4 and PS5 are all that similar.
They use very different generations of CPU, and GPU. So shader libraries will be different for the most part. Also custom hardware on top of that for decoding and direct storage access, as well as a fairly updated SDK.
It’ll certainly help because the underlying systems have the same thread of design running through them but I think it’s the same way a 3DS emulator can help with the switch or how Dolphin can’t really do Wii U games. They’re similar but not quite.
And I’m surprised that conversation was remembered :-) thanks for bringing it up.
>They use very different generations of CPU, and GPU. So shader libraries will be different for the most part.
Can you expound on this? Why do the shader libraries change due to new hardware? I get that the compiled shaders would change, but why would the libraries themselves change? The other points I understand.
>I’m surprised that conversation was remembered
I remembered the conversation because I spent some time trying to prove I was right about gamedevs using raw vulkan/directx (they seemingly do not, I was wrong) and then learning more about graphics APIs in general. I realized you were the the one I had had that conversation with because when I searched hn.algolia for Gnm earlier to answer my question elsewhere in this thread your name kept popping up, making roughly the same arguments from that thread I responded to you in.
To your question, consider that console games ship precompiled shader libraries that target the known GPU of that console. This prevents shader compile hitches etc.
So the PS5 is effectively a superset of the PS4, with a significant new set of capabilities. There’s no opportunity to take an intermediate language like Proton etc does to transpile it first.
Main differences would be hardcoded expectations regarding very tight integration between GPU and CPU, and the available memory bandwidth.
PS4 (and PS5, iirc) both use a custom OS built out of FreeBSD with specialized variant of an AMD APU using GDDR memory, plus PS5 got few extra coprocessors for handling things like decompression in line with storage access
Sony also did some really weird stuff with the PS4 to make emulation harder, chiefly among them the PCIe “glue device”, a PCIe device that masquerades as one of 15 (?) different ones, depending on the function needed at that instant. Geohotz has a section on it in his presentation about jailbreaking the PS4.
There are various ways they could be made to care, e.g. wrapping a function call in a macro that expands with some sort of assertion about hardware state. But I'm guessing that if they were told to design emulation counter-measures, it was to defeat hardware emulation and not WINE-style library shimming.
You'd most likely need to run it in a VM and either implement the needed APIs or implement whatever the official OS needs to run (RPCS3 has you download the OS from Sony and implements whatever needed to run, Xenia on the other hand -Xbox360 emulator- reimplements the OS so that you don't need anything from Microsoft).
That's a different problem. I guess emulation devs targeting consoles which originally ran x86 code will not ship arm binaries for a long time. That layer of translation will be left to rosetta 2 and whatever microsoft ships as translation layer.
I’d take that bet. Given a million years of concentrated effort, I’m feeling confident we’d find a way. Even if it takes a hobbyist replacing some internal components on the Steam Deck.
Given a million years, I'd say the human race ending is more likely than the human race figuring out how to run Bloodborne 4 on a Steam Deck, given that in a couple years, Steam Deck 2 will outperform the original SD.
this will run better than both switch and ps3 (even wii u and ps2 in same case ) emulator because of ps4/ps5 hardware architecture is the same as normal PC/steam deck
Those wiki has some incorrect information. How shadPS4 and fpPS4 works are the same. Almost of them can be categorized as a compatibility layer. The only one that can be called a PS4 emulator is Orbital because it virtualize (and emulate) the PS4 hardwares.
I wonder what the hell Sony is doing still neglecting, almost vindictively, this S-tier culturally significant game. Are they waiting to use it for a launch PS6 title or what?
Always enjoyed Sony games. I will not forget that Sony didn't make the PS4 backwards compatible, claiming no one cared about that, and then later offered the ability to play older games via their subscription-based PSNOW service. You can download some of them, but others can only be streamed and you need to have a good internet connection to play a PS2 game. Ridiculous.
There will always be a demand for playing older games, hence emulators like this.
I don't know about the older generation so I'll explain how PS4 emulation can be achieve. The first step is to understand how the console run the game. The good news is the PS4 has been hacked and almost all of its file and information has been decrypted and dumped. The official PS4 SDK also leaked.
Now we know how the console run the game. The next step is how to use this information run the game outside the console. The good news is PS4 system is just a modified version of FreeBSD, which mean how it works is very similar to the PC. A PS4 executable is just a custom ELF file. So to run a PS4 game outside the console we need to manually map the game executable and provide the symbol it needed somehow (e.g. a custom implementation or reuse the PS4 library).
Exactly. I will make explain more how PS4 emulator can be achieve.
First, you can make the whole universe. You need a universe for PS4 to live in.
Then, you make do PS4 emulator.
Now you have achieve.
We also have better access to others doing the same thing thanks to the Internet, and better and more computing power to figure out how these things work. But I imagine better access to information is a big driver.
The common ISA definitely helps -- it opens the door to just running the game image directly and shoving the right dependencies under it (i.e. what WINE does) rather than having to boot the console's OS.
Generally speaking there's been a lot of good work in the industry for binary translation too, cf. Rosetta 2. That's another tool in the box for hoisting a binary on to a different host environment.
Can't speak with 100% authority about the PS4 in particular, but for most modern consoles (from roughly the Xbox/PS2/Gamecube generation onward) the easiest way to dump a game disc/cartridge is to have a hacked/modified console that decrypts and dumps the game data for you.
finally someone did it! i was wondering why we stopped at ps3 emulators, now i can run ps4 games on pc aswell!
but would love to know whats holding the devs back.
Not sure about PlayStation, but the last two generations of Xbox have been some of the most secure consumer devices available. I imagine the difficulty of breaking into and analyzing the system has been a factor.
I can only say that after watching the respective video, I found MVG's explanation to misinterpret fundamental concepts of computing graphics, as the linked comment explains. Granted, everyone can make mistakes - but it's the fact that he doesn't correct them that I find disrespectful, it only spreads wrong information!
I feel bad for the people blindly defending him, many of his videos are wrong [1] and his viewers end up incorrectly learning a lot technical stuff, especially when there're actual knowledgeable youtubers out there.
He is fairly accurate about topics I have expertise on - modding of the PS1 / PS2 / GC / Xbox / Wii - and has his explanations of videos he made on 8/16-bit generations have been accurate.
I can't say much about his videos linked in another post (about PS1 shimmering) as I haven't touched graphics programming / APIs (beyond coding a very basic 3d rendering engine which ran on the CPU).
After reading some of the linked discussions - yes he does appear to have posted some bullshit. That doesn't make all of his content bullshit though, and doesn't make him "non technical". The fact that he has shipped several games on constrained platforms is proof that he is technical.
He does now go into the same box as I put 99.9% of content creators in - entertaining but don't trust them on the details.
He developed the Shantae port which I believed included emulation development. He’s released a few games with limited run games. In the 2000s he ported several emulators to the original Xbox.
He appears to have a long history in emulation and games development and is presently works as a lead dev at limited run games. What are your claims based on?
Funnily enough from the way that he talks in his videos I always assumed he wasn't that knowledgeable, until I found out more about him and realised what an incredibly skilled programmer he actually is.
I think maybe he just comes off that way because of how he presents things in videos.
The problem with making hard things sound accessible for wider audiences, is that people who understand the hard stuff natively then cannot separate the layman’s explanation from the technical capabilities of the person making those explanations.
Perhaps ironically, over the years I’ve found it’s those who cannot look past the tech-jargon to be the lesser experienced because they learn the words without fully understanding the concepts.
>The problem with making hard things sound accessible for wider audiences, is that people who understand the hard stuff natively then cannot separate the layman’s explanation from the technical capabilities of the person making those explanations.
it can also be the case that the 'laymen explanation' is actually patently wrong -- not just over-simplified or 'dumbed-down'; wrong.
some things just require a certain level of background knowledge; this is why generally any 'celebrity scientist' explanation of anything with the word 'quantum' in the subject line is generally just down-right wrong.
there is no decent metaphor by which to onboard a laymen in certain technical topics.
that isn't to say that the 'wrong' answers don't have value in educating the laymen, but the liberties that some experts take in 'wrongness allowance' is quite different from one another.
personally I think it's the responsibility of the explainer to step aside at some point and say : "Look, this is wrong, but without the background this is as close as I can get you to understanding this thing, so just don't take what I say as gospel from this point forward." -- the reason this is important is simply due to the fact that the laymen doesn't stand a chance at finding out which parts are wishy-washy by themselves without some further guidance.
not mentioning where the fairy tale begins is what leads people into thinking that there is actually an alive/dead cat out there somewhere. they grasp the metaphor itself rather than the statistics concept that is being explored.
You’re conflating entertainment shows with university lectures.
The point of videos like the aforementioned isn’t to give people a background into game development. It’s to give people who have no experience an overview for entertainment purposes.
That's not true. Science communicators in the past have successfully taught complex theories to a wider audience without compromising in integrity and accuracy.
The issue here is that many youtubers have sold factual correctness for a view count.
You say that and I guarantee you that people who have dedicated their career to that particular topic will say those “science communicators” are technically incorrect due to the generalisations and/or analogies made in the explanation.
It’s such a common behavioural tendency with general audience publications that someone coined a law for it (the name of which I forget but I’m sure someone else on here can reply with it).
Those people who have dedicated their career to a narrow topic can also be wrong. Not so much about the facts, but in assessing whether or not certain compromises or analogies that don’t map 1:1 matter for the purposes of what is trying to be communicated.
Odd I've seen multiple videos where he does code, albeit simple examples but still low level C stuff. His video explaining how the original gameboy graphics work is pretty informative imo. I suppose he could just be parroting stuff he has found online but I wouldn't call him clueless.
Not really. I agree that these days his videos are of mediocre quality and more speculative than based on facts. But he is a coder, he has a history of developing an emulator running on the Xbox 360 I believe.
Is it accurate to call an inflation-adjusted yearly payment of ~$2000 UBI, though? I know nothing about housing and living expenses in Alaska, but I'd guess that isn't exactly enough to make work completely optional.
It sounds like you're conflating a few things. UBI is as it says, an income that is given universally. UBI doesn't imply a certain amount of income. Other phrases may be used for what you seem to be describing: full basic income, guaranteed minimum income (which implies means testing).
This is why I'm glad in practice politicians, economists, etc., tend to study these things in order figure out how to structure social services in a way that actually helps people and not to make "Reductio ad absurdum" style arguments.
Honestly, I'm not sure the frequency needs to be extraordinarily high. The ability to get rid of the "but think of all the jobs that will be lost" argument lets us get rid of swaths of bullshit jobs that don't need to exist, or even actually harmful jobs. It's been a constant roadblock to greater automation.
Shut down by whom? For what reason? What's usually illegal in these cases is distributing games and BIOS roms. Making and distributing things like emulators seems to be OK legally. I'm pretty sure this was tested in court via Sony's lawsuits against Bleem, but I understand there are always finer points that may not be apparent.
Also interesting and only tangentially related is that MAME used to have a rule about not supporting games within 2 years of release.
Since the PS4 is more or less an x86 computer, I imagine most of the hard work would be implementing the system/graphics APIs of the PS4. Or are there major hardware differences between an x86 PC and the PS4 that also need to be handled?