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).