Well this is pretty exciting. This opens up the door for PS4 games to be written in any language that uses LLVM as a backend, right? So in the future, PS4 games could be written in D, Rust, Ada, ActionScript...
Especially with the indie focus Sony has had, this could make it much much easier for people used to creating games with ActionScript to get their game on a console.
Is there something I'm missing? This seems too good.
Retail consoles only run code signed by Sony. When you become a licensed developer you get special consoles called devkits that can (among other things) run unsigned code.
Not only that but devkits also come with the SDKs and tools and access to the developer network. Plus they cost thousands of dollars. They also usually have double the specs of the retail console to run debug code and tools. Even USB connectivity and plugins for VS to debug code running on the devkit remotely.
Also on our Vita devkits there is no battery to make space for the extra ram.
Even with the open sourced compiler you're still missing most of the toolchain.
>> Not sure I follow - what is stopping non-licensed developers from developing and testing games on their own PS4s now that this has happened?
I don't want to come across as being mean or anything but...
How charmingly naive!!
Sony (and the other console makers, to be fair) go to absolutely incredible lengths to make sure that people absolutely do not get to run their own code on these machines. And then they sue anyone that finds a way to do so.
>Sony (and the other console makers, to be fair) go to absolutely incredible lengths to make sure that people absolutely do not get to run their own code on these machines. And then they sue anyone that finds a way to do so.
Also, to be fair, PS4 is the first Sony's home console that does not run user's code. All the previous Playstations had such an ability in one way or another:
I don't see a reason to buy a console unless it has a large number of exclusive titles that are worth playing. (Which in itself is anti-consumer. I want the games not the hardware)
PC gaming is currently the best choice. All the freedom combined with better hardware. The only disadvantage is the high cost of entry but you can easily save money by buying games during the big sales on steam.
Handhelds are a different story though. The games are often a lot better than mobile games.
Well....I have both a beefy gaming pc and a next-gen console. Yeah, my PC is more powerful and can run anything you throw at it. But most of the time I simply enjoy just sitting on the sofa with a controller in hand, one click the console is on(and it turns my TV and amp on as well), another click and the game is launching. The system is quiet and uses less energy - my £1200 gaming machine sure has an overclocked CPU and a custom cooling system,but it doesn't change the fact that it has a total of 7 fans and uses 400W while running games - I had it in my living room for a while but didn't enjoy the whiz of air. In fact, I bought Dragon Age Inquisition on PC to enjoy better graphics, but after the latest Nvidia Driver broke the game(huge FPS spikes, artifacts everywhere) I just bought a console version. Pop the disc in, go. No drivers, no config, it just works. Sure the graphics are slightly worse,but not enough for me to care. And the price of games was literally never an issue for me - just the lack of time to actually play them.
The retail versions of modern consoles enforce cryptographic signatures on everything, so nothing will run on them without going though MS/Sony/Nintendo first.
Officially licenced developers have special devkit systems with more lax security.
Sometimes fancy extra features too- I believe I've heard of (and seen photos of) devkit systems that interface to a PC for uploading code and/or debugging.
I have a PS4 devkit on my desk. Basically you develop in Visual Studio like you would normally, press run and the application gets deployed to the PS4 over lan - debugger also attaches remotely. So from the programmers point of view you don't even care that your code is running over the network. In fact, I have worked with Wii/WiiU/PS3/PS4/X360/XOne devkits and you can always deploy remotely through lan - with the only exception being the Wii, which used 3 USB cables at once for deployment and debugging.
That's pretty sweet! No wonder with the Wii, I understand it was the last holdout of the older group of consoles, what with the double-clocked GameCube CPU and all.
Don't think that Wii U is much better....it has a lan port, but literally every tool is command line based and their debugger looks like notepad from Windows 95 with few extra buttons tacked on. There is a plugin for Visual Studio integration, but it's super slow, when you hit a breakpoint in code it takes over a minute to trigger in the IDE, so everyone uses their horrible outdated debugger instead. Nintendo hardware is very weird to develop for.
I don't seem to have access to the VS plugin, but when I place a breakpoint in the Green Hills IDE it is indeed about 30 seconds for it to catch up. It works, but I do find it frustrating.
Is there anything interesting about this? It's not like end users will get any utility from this, do development studios? Or is this just a way to ease Sony's maintenance burden?
Yeah, it's probably a good idea in the grand scheme of things to get their patches back upstream. But is it worth reporting on? Worth posting/upvoting on social media? It doesn't actually mean anything does it?
I find it interesting in light of the licensing debates between GCC and Clang. GNU goes to great lengths to ensure that anyone modifying or extending GCC is legally obliged to release their changes -- including technical design decisions that actually make GCC's code difficult to reuse even in GPL-compatible projects. Clang is under a permissive license, so Sony has no obligation to release their changes, but apparently they are anyway.
I realize that GCC's policies were actually important for getting Next to release their Objective C code in the 90's, but it seems like times have changed. Companies have learned that keeping their code a secret actually isn't a huge competitive advantage whereas releasing it has a lot of real benefits (such as reduced maintenance cost). It's always better to have people doing the right thing because it's in their interests rather than because you forced them to.
It's useful to Sony to reduce their maintenance burden. It's useful to everybody else because there are probably pieces of their code which can be reused or adapted for non-PS4 platforms.
Heck, even if the code is just used as a reference by people saying "gee, I wonder how Sony solved this problem" it's still very useful.
People upvote what they find interesting. I don't own a PS4 and I'm never going to write code for it. I find this interesting because it is a good example of the value of upstreaming patches. The next time I give a talk about open source, maybe this is one of the examples I cite because the PS4 is something everyone knows.
It could potentially be interesting if they worked on the Fusion platform code generation much. The little AMD SoCs are pretty awesome, and if Sony has a few tricks up their sleeve for making things like OpenCL nicer, we could see some use elsewhere. Dev studios will get the advantage that because the Sony code's not in llvm mainline, it's a lot easier for Sony to give them more recent, faster compilers.
Not really. The only hurdle is the developer agreements. Even game engines that are able to run on consoles (Godot, for instance), generally won't give you the export templates unless you're an official developer.
While this is exciting, so far technically this seems fairly straightforward stuff, some defines and defaults (enable avx, disable exceptions) set for the ps4.
I bet the biggest upside is that sony has easier time keeping up with the current llvm, and so devs get recent compiler versions.
If the PS4 really runs FreeBSD, wouldn't it be possible to provide a compatible userspace on real FreeBSD/maybe even Linux and run PS4 binaries on a PC?
You'd need to reverse-engineer the PS4 libraries. I have no idea what libraries Sony provide for the PS4, but I'd assume the UI, audio and graphics libraries are all custom. There's also probably some sort of DRM library required to load games off disk.
The PlayStation 4 features two graphics APIs, a low level API named GNM and a high level API named GNMX. Sony's own PlayStation Shader Language (PSSL) was introduced on the PlayStation 4
Unlikely. Game developers make assumptions based on the consistent hardware; it's a lot of why they can eke competitive performance out of old hardware. You might eventually, with much work and thrashing, get something to start, but that doesn't mean that all of the little tweaks and tricks based on the PS4's hardware itself are going work on your PC. "It's all x86" doesn't take into account the unified memory architecture between CPU and GPU, for example.
We're getting HUMA soon (or we already have it, I forget) on PCs. But there are still going to be important differences vs. the consoles. We use DDR3, the PS4 uses GDDR5 (yes, for system memory). The Xbox One SoC has eDRAM.
It doesn't run on FreeBSD, its kernel is based off FreeBSD. Really it just saves them having to re-implement TCP/IP, VFS, etc. The userland is all entirely different.
It also uses different (custom) hardware and makes assumptions about it; no OpenGL/DirectX layer of abstraction, for example, since the hardware is fixed for the next 10 years your API call doesn't have to do different things on different hardware. You'd have to provide abstractions for all of that.
Likewise for the CPU; it's possible there are CPU/GPU extensions in the PS4 that don't exist in standard commercial hardware.
On top of all that, the binaries are all signed/encrypted, so without the ability to decrypt them it doesn't do us much good.
Especially with the indie focus Sony has had, this could make it much much easier for people used to creating games with ActionScript to get their game on a console.
Is there something I'm missing? This seems too good.