JUCE & PS4 Support?


#1

Because of my close proximity to the Sony Crackle/console team (10 steps away, tbh), I decided to start looking up console development. There's some interesting public information out there about the PS4:

http://www.extremetech.com/gaming/159476-ps4-runs-orbis-os-a-modified-version-of-freebsd-thats-similar-to-linux

http://www.phoronix.com/scan.php?page=news_item&px=MTU1MTY

I haven't had the chance to mess around with FreeBSD, but IIRC Vinnie had JUCE running on there (hence the JUCE_BSD macro kicking around). I'm wondering how much more difficult it would be to port JUCE to this platform, and if it's even on the road map?

Understandibly, development for the PS4 requires a ridiculously expensive dev kit (no idea about what kind of hoops you have to jump through to get one):
http://www.polygon.com/2013/7/24/4553842/so-how-much-does-it-cost-to-develop-for-playstation-4

I'm not sure what the PS4 application market is like, and I hear there is a strict set of standards that a project has to meet to get an app in there, but seems like it would be really cool to get JUCE apps hit Sony's console app market!


#2

Would love to see something like this - it's not on our immediate roadmap and none of us here have experience with the PS development tools, but would be interested if anyone out there can say how feasible it is. Certainly FreeBSD isn't a problem - that's essentially what OSX is under the hood.


#3

Wow, just happened across this old post. There’s no “A few moments (aeons) later” macro on this forum? Oh well…

Over the last couple years I had pretty serious exposure to writing and maintaining PS3 and PS4 apps; suffice to say the tools are ugly and very involved, and must say that porting JUCE to these systems would be one helluva job.

Effectively, every single OS feature you require needs special integration with unorthodox Sony APIs - different ones for PS3 and PS4. Also, the Sony Playstation Store requirement lists are downright massive (especially if you want internet connectivity, and any kind of local and cloud storage).

Other pain points:

  • High license costs
  • High devkit and test kit costs (++$)
  • And yes, there are separate developer and test consoles
  • Video playback requires special licensing (++$)
  • App store certification is tough as hell, and costs per iteration (++$)
    • If you crash during a cert test, you’re immediately sent back to the drawing board and scheduling a new cert test!
  • APIs must stay secret/private (it’s all proprietary!)
  • Gamepad support is required.
    • This means UX is typically handled via a focus management system of your own design
    • Also means you have to use various native dialogues for user text input (or roll your own if you’re hardcore enough)
    • Good spit-shine is detecting low gamepad battery power, loss of gamepad connection, and no gamepads being connected
  • Unable to use a MAC address for tracking (goes against the store requirements)
  • Both systems can make a max of 8 simultaneous network requests at once in an application (games have different requirements, in case you’re wondering)
    • You would need a network request queuing system
  • No native audio codecs (in case you wanted something JUCE doesn’t provide for whatever reason)
  • Renderers have slightly different pipelines than OpenGL or DirectX (ie: PSGL and GNM/GNMX)
  • Obviously no separate heavyweight windows allowed (I hope you don’t feel too attached to that TopLevelWindow!)
    • You get one fullscreen surface to draw onto.
  • No MIDI support
  • Apps must be able to handle app suspend/resume at any given point
  • Did I mention their APIs are all proprietary and must stay hidden?

Probably lots and lots of other fun things I’m forgetting right now…

On the milder side, both systems are developed using Visual Studio with proprietary extensions that generate their own compiler and linker properties. So it would be a relatively simple extension of all the vcxproj and sln data in the Projucer (like a new arch, with extra stuff and things).


#4

The only JUCE features I could see (from my zero actual experience with PS4, but wishing I could and reading a lot about it) being useful for console development without extensively programming an entirely new OS backend for JUCE’s interfaces are the data structures found in juce_core, which are generally just abstractions of STL structures or basic data structures written in plain, portable C++ (Like String). Doing anything involving graphics, audio, input, etc. would need to have an abstraction built on top of Sony’s APIs the same way JUCE does for Windows, macOS, Android, etc. (like you basically said)

That said, are PS4 developers allowed to make any sort of POSIX calls or are those all wrapped and enforced by the Sony API? I know they’re available to some capacity because jailbreakers are always targeting BSD syscalls, but I’d imagine Sony is pretty strict on it. If they are, that’s another avenue where JUCE stuff should work ok so long as it takes the POSIX codepath (i.e. sockets).


#5

Funny you mention that type of stuff as you reminded of something very important: the PS3 and PS4 compilers are butchered/customised derivatives of GCC 3.4 and Clang 3.2 respectively, and most of the C++11 (and up) STL features are not available.

For example, there’s no implementation of std::move on the PS4 compiler (named Orbis), although it supports move semantics via the &&. Really bizarre stuff. This is aside from various compiler bugs with lambdas and auto on that compiler. And PS3 supports none of these features…


I believe this was possible with the app SDKs to some extent (like for threads and other fundamental things like FILE). I think both processes and sockets required special APIs, but the apps I worked on (streaming video players) didn’t use that type of functionality so can’t confirm or deny.