PSM Development Assistant for Unity
|Version||PS VITA FW||Category SFO||Creation Date||Hash MD5||Hash SHA1||Links||Size||Notes|
|1.00||3.00||gd||November 26, 2013||md5:D207A1663E4778BE4CC8818506D05DE4||sha1:CD3A66939E2E4DBF698314921A49C13A66315C78||mega.co.nz||-||-|
|1.05||3.15||gp||July 12, 2014||md5:1FAA126521DFABFF9032EBB12F79D2CF||sha1:A78E54CE19D7E015AE8D6684EF8E7F8866CD94B6||mega.co.nz||-||-|
|1.06||3.30||gp||October 17, 2014||md5:1673FA51A732347C4B8319986DB79BA3||sha1:D73875D9FFC51F61AD55E0C16C756C8071703AE6||mega.co.nz||-||-|
|Version||PSM Development Assistant version||Hash MD5||Hash SHA1||Links||Size||Notes|
|4.3.4f1||1.05||md5:ae713bbdca0ecbcfbaf451d765cc0d20||sha1:5d0f96a3c5a060930f01a639b842a1ffa8e5b222||beta.unity3d.com||488 MB||There may also be another version which is 436 MB but the difference is unknown.|
The CPU has 3 hardware threads available to the application.
Unity uses at least 2 (main and rendering), so creating more than one additional worker thread from managed code is not likely to yield any additional benefit.
But this of course depends on how the application itself is behaving. For example, a GPU-limited application might have plenty of CPU time to spare.
The physical memory available in the PS Vita is 256MB of system memory, and 128MB of video memory.
Not all of this is available to a "Unity for PSM" application - below is a breakdown of how much is reserved, for what, and how much is available to the application.
|Physical Memory||256 MB|
|Available to "Unity for PSM"||Available to "Unity for PSM"|
|"Unity for PSM" executable||-32 MB|
|Buffers (sub-system allocations)||-32 MB|
|Available to App||184 MB|
|Physical Memory||128 MB|
|Available to "Unity for PSM"||112 MB|
|Buffers (screen and commands)||-25 MB|
|Available to App||87 MB|
- The numbers above are theoretical limits. It's good practice to allow for a few MB of unused buffer space, to not run out of memory while running the application.
- The memory listed as "Available to App" is used not only for scripts, but also for any kind of additional game data, such as meshes, physics/collision structures, etc.
Input / Output
The PS Vita has these input / sensor capabilities, all which are available from a "Unity for PSM" application:
- Directional input and × ○ □ △ buttons (digital)
- Left and right shoulder buttons (digital)
- Left and right analog sticks (x/y axis)
- On-screen touch input + rear touch pad
- Compass / Gyro / Accelerometer / Location
- Front and rear camera
- Speaker and microphone
Application code runs in a Mono 'sandboxed' environment where only managed (C# / UnityScript / Boo) code is allowed.
The Mono runtime uses Just-In-Time (JIT) compilation of application (user) scripts.
Unity for PSM reuses the same graphics driver used in the "Unity PS Vita"
This ensures that a high-performance rendering path is available also with Unity for PSM.
But the graphics driver behaves quite differently in one key aspect : A shader instance is only compiled when it's actually used, i.e. right before rendering the material from which it is referenced.
This means that the classic fallback shader mechanism provided in Unity is not available on PSM.
An unsupported shader (a shader with a programming error, or otherwise fails to compile) will simply be replaced with the Default Shader, which usually produce a pink color output (and the compilation error output written to the device log). Because this step can sometimes be computationally intensive, shaders already compiled are cached, and can be reused on subsequent application runs (provided the shader hasn't changed). One benefit of compiling shaders at runtime is that Unity for PSM also supports the older Unity "fixed function" shaders.