PlayStation Suite Status...

Topics: PlayStation Mobile
May 12, 2012 at 10:45 AM
Edited May 12, 2012 at 2:57 PM

As we had a Metro status thread, I thought others may be interested in the progress of the PlayStation Suite integration.

Well Dave Leaver has been working diligently on it and made some excellent progress...


This code is available in the develop3d branch. Apart from showing SpriteBatch working, the above was also using Farseer Physics under the hood.



May 12, 2012 at 11:51 AM

Excellent.  Nice work, Dave.

May 15, 2012 at 5:43 PM

I played with it last night and got the xTile library working almost as-is from its latest source, the only change being that I had to load map files as filestreams due to the lack of Pipeline support. Everything behaved as it would in XNA, with the exception of some unwanted texture filtering. I might not be using the right branch, but I'm still impressed.

Does it run on actual devices yet? I still got a blank screen when I tried deploying my map test project to my Vita, but I didn't get a chance to try deploying something simpler yet.

May 23, 2012 at 7:56 AM

Well, looks like I'm going to be contributing to this project! I need this to run on my Vita as well.

May 23, 2012 at 8:39 AM

Excellent.  We look forward to your contributions.

May 24, 2012 at 12:26 AM

I have questions about the current state of development, and things that need to be done to aid development. Who should I ask about this?

May 24, 2012 at 12:42 AM

Asking here is fine and has the most coverage.

May 24, 2012 at 1:06 AM

Alright, well to start


I made the suite compile, set up an extremely simple project that consisted of just drawing a sprite to the screen and then debugged it on the Vita. Worked perfectly, takes a second to load if you run with the debugger but nevertheless works. Load times may be slow F8_Sean, so I suggest you give it a minute to see if it loads for you (literally, give it a minute or two! My project loaded in about a second but like I said, it was extremely simple.)

Next I'm going to try to link this to a much more complicated project, and see what it takes for me to get it all running.


My question however is the SpriteBatcher, what is this? Is it a different implementation of SpriteBatch, and should it be called rather than calling SpriteBatch?

May 24, 2012 at 8:40 AM

the SpriteBatcher is an internal classused by the SpriteBatch to do the work, the SpriteBatch is the public XNA API.

May 24, 2012 at 10:13 PM

Hey Guys!

SpriteBatch should be all good and working. It might not be as fast as it could be, will need some more bright ideas here for improvement as I've hit the low hanging fruit.


Areas that need looking in to:

Sound / Music - These should work but I haven't actually tested them yet!

SpriteFont - dlouis said this isn't working, haven't had time to test it yet.

XNA VertexBuffer / IndexBuffer - PSS has a VertexBuffer object that is both a Vertex and Index buffer. We'll need to work around this somehow, perhaps copy the data that is passed in to XNA Vertex/Index Buffer objects then when they are actually used create a Pss.VertexBuffer and set the data? I haven't actually used the XNA Vertex/Index Buffer objects myself so I'm probably not the best to look at this. (This is why almost none of the draw calls on GraphicsDevice are implemented)

Shaders - Currently we hack around BasicEffect, but we need to do it much better than now! One option would be to implement a Pss Shader for each different technique that BasicEffect has, which would get BasicEffect working. Other thoughts here are appreciated (I've hardly done shaders before)


The Touch and Controller Input work correctly. Accelerometer might too, I need to test that at some stage.

May 26, 2012 at 2:37 AM

Do you have a TestBed type project with Farseer working?

May 27, 2012 at 4:52 AM

Nope, I've just made it work in my current game. It performs really really badly on the vita. I'm still not sure if I'll ever get a playable framerate out of it.

To make it work just grab the csproj from here: (I've just made a PSS lib project and added all the files)

And open Collision/DynamicTreeBroadPhase.cs

Change "internal struct Pair" to be "public struct Pair" and you are done.

May 27, 2012 at 5:08 AM

> It performs really really badly on the vita. I'm still not
> sure if I'll ever get a playable framerate out of it.

Do you have any clue why?  Is your scene very complex?


May 27, 2012 at 10:03 PM

About 84 sprites over around 10 textures, nothing I'd expect any system would have a problem with.

I plan on making a proper test case some time this week so I can figure out how to improve it, the code base I'm working in is a bit too big.
Most of the time is taken up in uploading the vertex buffer, I'm hoping a slightly different format will improve it.

There are complaints around the CPU performance of the pss forums here, but most people are happy with the graphics performance:

May 28, 2012 at 11:25 AM

Sigh, I went to work on this this evening and my Vita is dead. No idea what is wrong with it :-( Will take it back later this week.

In the mean time, I've knocked up some bits to get a start on working out how to get SpriteBatch faster.

Repo is here:

ATM it has a few marginally different simple SpriteBatch implementations (mainly around what the VertexBuffer is populated with).

May 29, 2012 at 1:56 AM

Vita Replaced :) And I ran my game on it (straight off the memory stick, haven't plugged it in to my dev pc yet) and I'm getting an AWESOME framerate.

I'm now wondering if my old vita was just totally stuffed. Will do some more investigation tonight.

May 29, 2012 at 4:04 AM

I can imagine the support requests.

Customer: "This game is running slow."

Sony: "Here's a new Vita."

Customer: "Uhh, ok.  Oh wow.  Problem fixed. Thanks Sony."

May 29, 2012 at 9:52 AM

Looks like my old Vita was just stuffed. However I found out some bits that will be useful for other people bringing things over to PSS.

The PSS VertexBuffer is very not-dynamic. Setting it more than once per frame will kill performance as it looks like it waits for the renderer to finish (It takes 1/60th of a second) before it can set the VertexBuffer. As such using the same SpriteBatch multiple times per frame is a big no no. If you need to do multiple Begin/End calls then you will need to use multiple SpriteBatch objects.

If you use a single VertexBuffer and set it once per frame the SetVertices call will take 1/60th of a second, but GraphicsContext.SwapBuffers will take no time.

If you use 3 VertexBuffer objects and rotate them each frame then SetVertices will take no time and GraphicsContext.SwapBuffers will take 1/60th of a second.

(2 gave inconsistent results, sometimes a frame would take almost no time, sometimes 1/60th, sometimes 2/60th of a second).


We could make the MonoGame PSS specific SpriteBatcher have 3 VertexBuffers that it rotates as this will make performance measurement on the Vita much better (You won't think SpriteBatch.End is taking up all of your time). However this will make each SpriteBatch take 3x more gfx memory, so probably not a good thing.


I now have a highly fluctuating framerate in my game, with farseer being the culprit. When there isn't much physics going on everything is smooth! :)

May 29, 2012 at 9:34 PM
Edited May 29, 2012 at 9:39 PM


> Looks like my old Vita was just stuffed.

Great, but i suspect the slower CPU performance others are reporting is still there...  just much improved.

> If you use 3 VertexBuffer objects and rotate them each frame then SetVertices will take no time

This is the reason for the discard/nooverwrite flags when calling SetData on a dynamic VB... it is there to hint to the driver how it should respond to the change in the buffer data.

IMO you should hide this detail under DynamicVertexBuffer and DrawUserPrimitive() and use these from SpriteBatcher.

This pattern is similar to one you use for VBs on Xbox and other predicated tiling rasterizers... in fact since the Vita has a PVR chip in it I suspect it uses predicated tiling as well.  Read this for background on predicated tiling...

... since a resource like a VB is reused for each tile... you cannot change it while it is being used for rendering.  I assume what is happening on PSS is that when you try to reuse the VB it stalls the CPU waiting for all rendering with that buffer to finish.

The XNA team added "discard" support to Xbox in 4.0 which allows you to reuse a dynamic VB within a frame... under the hood they are replacing your VB with a new one.  Read this...

If the graphics driver doesn't support discard natively then you need to implement it yourself under the XNA API just like with Xbox.  I would do it like so....

  1. Keep a pool of VBs under GraphicsDevice.
  2. DynamicVertexBuffer is implemented as plain system memory.
  3. When GraphicsDevice.DrawPrimitive() is called with a DynamicVertexBuffer or DrawUserPrimitive() is called… find a VB from the pool which best matches the size you need... copy the data once into the VB.
  4. If a large enough VB is not found allocate one and stick it in the pool.
  5. At the end of a frame (or frames) mark all the VBs in the pool as being available for rendering again.

Fixing it like this all XNA projects should be portable to PSS without needing to redesign how they render dynamic geometry... you've hidden the complexity and fixed performance for everyone.

> this will make each SpriteBatch take 3x more gfx memory, so probably not a good thing.

This isn't that bad of a problem...  vb data is pretty small compared to textures in a game.

  - Tom

Jun 4, 2012 at 12:45 AM


Take a look at this...

... Game.Tick() internally calls both Game.Update() and Game.Draw().  From the looks of OnRenderFrame above that you seem to assume you have to call draw yourself.  This means you're rendering the same frame twice... causing further performance problems.

 I suggest you remove both those methods and instead in PSSGamePlatform.RunLoop()...

 ... you just call Game.Tick() which does everything.  This is similar to how the Windows 8 code works...

 - Tom




Jun 4, 2012 at 10:14 AM

Agreed on all of the vertex buffer bits. Will look at doing that when I've some time.

Will look at the Game.Tick issue now, as you said on PR 494 we probably inherited the bug from the Android code!

Jun 4, 2012 at 11:50 AM

Bug was as described, easy fix. Thanks for that! :-)

Jun 4, 2012 at 12:18 PM

No prob... hope it helped with your performance issues.


Jun 5, 2012 at 7:17 AM

Appears it is now PlayStation Mobile, and HTC will be making a PSM handset.

Jun 5, 2012 at 10:04 AM

Yea... this is good in that it makes the PSS port more viable.

But by renaming it "Mobile" that signals that this will never be allowed on Playstation3/4 itself which sort of sucks.  I was hoping to see this allow XNA like development on PS3/4.

Jun 5, 2012 at 9:31 PM

@Tom, I've had confirmation from PSMDev that PS3 is still being considered.



Jun 5, 2012 at 10:02 PM

@Dom - Well that's good...  renaming it to Playstation Mobile seem confusing then.

Jun 6, 2012 at 12:56 AM

Maybe they're looking at something like this.

Jun 6, 2012 at 1:32 AM

Hah... I haven't seen that in years!


Jun 20, 2012 at 2:43 PM

Hello, can any tell me if DrawIndexedPrimitives works on the Vita at this point?

Jun 21, 2012 at 9:51 PM

@ananth - Nope not yet. Currently only DrawPrimitives and SpriteBatch work.

I've been hacking on other projects (and monsters in Diablo 3) lately, but should be getting some work done on this this weekend. Need to do the VertexBuffer refactor as talked about above first, then most of the other GraphicsDevice functions should be easy enough.

Jun 23, 2012 at 4:31 AM

Alright, DrawIndexedPrimitives is now implemented in my fork

The new Vertex/Index buffer set up is probably quite inefficient with regards to reusing PssVertexBuffer contents, but it is a step in the right direction. More work to come tomorrow making SpriteBatcher use the same bits.

Jun 25, 2012 at 9:19 AM

Screenshots or it never happened ;).

Great stuff Danzel. Look forward to seeing the PR.


Jun 25, 2012 at 9:15 PM
Edited Jun 25, 2012 at 9:16 PM

Hello, I'm getting this error while trying to run a sample (Aiming Game from CartBlanche samples fork) using danzel monogame pssuite fork:


C# Assembly Loading [ \\MonoSamples\\MonoGame-Samples\\Aiming\\bin\\Debug\\MonoGame.Samples.Aiming.PSSuite-unsigned\\Application\\pssapp.exe ]
NVIDIA Corporation
GeForce GT 630M/PCIe/SSE2
4.20 NVIDIA via Cg compiler

Unhandled Exception: System.ArgumentOutOfRangeException: native function returned error.
  at Sce.Pss.Core.Error.ThrowNativeException (Int32 error) [0x00000] in :0 
  at Sce.Pss.Core.Graphics.Texture2D.SetPixels (Int32 level, System.Array pixels, PixelFormat format, Int32 offset, Int32 pitch, Int32 dx, Int32 dy, Int32 dw, Int32 dh) [0x00000] in :0 
  at Microsoft.Xna.Framework.Graphics.Texture2D.SetData[Byte] (Int32 level, Nullable`1 rect, System.Byte[] data, Int32 startIndex, Int32 elementCount) [0x00000] in :0 
  at Microsoft.Xna.Framework.Content.Texture2DReader.Read (Microsoft.Xna.Framework.Content.ContentReader reader, Microsoft.Xna.Framework.Graphics.Texture2D existingInstance) [0x00000] in :0 
  at Microsoft.Xna.Framework.Content.ContentTypeReader`1[Microsoft.Xna.Framework.Graphics.Texture2D].Read (Microsoft.Xna.Framework.Content.ContentReader input, System.Object existingInstance) [0x00000] in :0 
  at Microsoft.Xna.Framework.Content.ContentReader.ReadObject[Texture2D] (Microsoft.Xna.Framework.Content.ContentTypeReader typeReader) [0x00000] in :0 
  at Microsoft.Xna.Framework.Content.ContentReader.ReadAsset[Texture2D] () [0x00000] in :0
  at Microsoft.Xna.Framework.Content.ContentManager.ReadAsset[Texture2D] (System.String assetName, System.Action`1 recordDisposableObject) [0x00000] in :0 
  at Microsoft.Xna.Framework.Content.ContentManager.Load[Texture2D] (System.String assetName) [0x00000] in :0 
  at Aiming.AimingGame.LoadContent () [0x00000] in :0 
  at Microsoft.Xna.Framework.Game.Initialize () [0x00000] in :0 
  at Aiming.AimingGame.Initialize () [0x00000] in :0 
  at Microsoft.Xna.Framework.Game.DoInitialize () [0x00000] in :0 
  at Microsoft.Xna.Framework.Game.Run (GameRunBehavior runBehavior) [0x00000] in :0 
  at Microsoft.Xna.Framework.Game.Run () [0x00000] in :0 
  at Aiming.Program.Main () [0x00000] in :0 


Anyone have a clue what this may be?! I copied the XNB files from the original project into Content folder (... bin\\Debug\\MonoGame.Samples.Aiming.PSSuite-unsigned\\Application\\Content)

Thanks in advance

Jun 26, 2012 at 3:38 PM

Hey, guys. I'm new to Monogame, but not to XNA and I'd really like to help this awesome project. What needs to be done and where can I get started helping out?

Jun 26, 2012 at 7:31 PM


Well danzel would know what he could use help with on the PSS port specifically.

If your interested in helping in a more general capacity you can see we've started porting the XNA content pipeline over...

 ... that could use a bunch of help.  If your interested in that post a new thread on the subject and the leads will join in.

Aside from that there are issue posted that could use fixes...

  - Tom


Jun 26, 2012 at 10:35 PM

@CartBlanche - My screenshot would just be a rhombus ;) Nothing exciting to look at from me.

@xesf - I'll take a look at that tonight.


On the PSS port specifically shaders (Effects) would be a good one to look at.

At the moment we hack around the Effect system as PSS has its own shader files. We should be able to spit these out as part of the monogame shader build process which would fix this up.

I'm on top of the GraphicsDevice Vertex/IndexBuffer fixups (Discussion with TomSpilman on how to implement it Everything else I've implemented and tested has worked afaik.

Porting samples would be another good one to look at to help find bugs! (As it looks like xesf has!)


@All - Please go +Kudo my request for split vertex/index buffers here: Thanks :)

Jun 26, 2012 at 11:09 PM

Thanks danzel.

As a side note, I've commented that texture.SetPixel from PSSuite and the code gives me error at Sce.Pss.Core.Input.Touch.GetData (Int32 deviceIndex). Its seams its something related with the PSSuite SDK itself, but I have the samples from PSSuite SDK working in the suite emulator.

Jun 28, 2012 at 12:49 AM

@xesf That is weird indeed. I haven't ever had trouble with Touch.GetData!

Could you zip up your ported project and upload it somewhere for me? Will make investigating easier.


Jun 28, 2012 at 8:44 AM

Its weird indeed. Maybe is a missing configuration or something. I will zip the projects later this evening when got home. 

Jun 28, 2012 at 5:53 PM
Edited Jun 28, 2012 at 5:53 PM

danzel, I zipped my projects at

Thanks for your time.

Jun 30, 2012 at 11:33 PM

@xesf Your Aiming.PSSuite project has a 'app.cfg' files which disables all of the input methods. If you do this, trying to use them (Which monogame does) will throw an exception. Change them all to true and aiming sample will work.

I've pushed a fix for ChaseAndEvade to my MonoGame branch. I was using the PSS Texture2D SetData wrong and not handling Dxt compressed textures. Sorted now!

Jul 1, 2012 at 1:17 AM

The input issue was indeed because of that flags, and the Texture issue you solved by handling the compressed textures ;).

Many thanks for your help. It seams I can now try to get my game running for PS Vita :). Lets see how difficult this can be.

Jul 1, 2012 at 5:38 PM

There is an issue with the BeforeUpdate game event. The _initialized flag is not turned true when the Game Initialize Method is called on DoInitialize, so this makes the Engine to call 2 times the Initialize method.

Both Aiming and ChaseAndEvade samples can be tested for this issue.

Get my game compiling and now I'm having some runtime issues like Blank Textures.

Jul 10, 2012 at 11:06 AM

Screen shot by @crank_gaming from this tweet!


Jul 10, 2012 at 3:39 PM

Very cool!

Jul 11, 2012 at 4:12 PM
Edited Jul 11, 2012 at 4:15 PM

Now i'm registered to codeplex.

I also made a short video clip showing Platformer XNA on Vita.

It's only a Test to get into it.

Jul 12, 2012 at 2:14 AM

Oh man that is awesome SiENce :-)

Jul 12, 2012 at 5:57 AM

Now if only more people actually played on dedicated consoles these days. :(

Jul 12, 2012 at 12:43 PM
Edited Jul 12, 2012 at 2:57 PM

I wish is that Playstation@Mobile (PSSuite SDK) goes live one day ;-).

One more note: I try to create a pack to share the XNA Platformer project for PSSuite.

cheers and thx for your hard work on Monogame!

Jul 13, 2012 at 5:18 AM

Quick question~

I'm planning on developing a pretty big 2D Game for ps mobile, and I had a quick question (couldn't find answer via search or google)


My programming skills are mainly focused around robotics, and ranges around basic to moderate.

and from what I can tell already, I would go nuts from using the ps suite sdk to manually program all my 2D stages (matrices.... uhhg)


So what I've been trying to find out is if i could use a XNA based game engine (one that integrates with  xna game studio4/visual studio)

to make a windows game(or xbox), then port it over via monogame in the future~


the main game engine I'm looking at  is FlatRedBall ( 

and from what i can tell it has it's own libraries that goes works with XNA (flatredball.dll)

(closest thing I found on this information: too bad he didn't try it will the dll yet...)


Would I Be able to make a game use XNA game studio +XNA Based game engine (IE: FlatredBall) then easily port it to mono?


If no (or not yet) do you have an idea of any monogame compatible game engines I could use? (Preferably with Stage/tile editor, paths, AI, contact Physics, etc)


(quick question, if it would need work to port over, how much work would be needed?)

thanks~ (If this is the wrong place to ask this, any suggestions of a place to ask?)





Jul 13, 2012 at 5:36 AM

Best way to find out is swap the DLL, recompile and try it out for yourself. :)

Jul 13, 2012 at 5:42 AM

aw dang i don't understand ;-;

(my robots never dealt with stuff like this >.<)

Jul 13, 2012 at 5:46 AM

You know FlatBallRed requires you to do a lot of C# coding, right? ^^

Jul 13, 2012 at 6:01 AM

I'm fine with the a lot of the base coding (math, variables, sub functions etc)

I just don't really under stand most of the concepts behind stuff like adding libraries, dlls?, etc. (I'm pretty much clueless)


my robots already had all the libraries I need built in, then I just programmed the robot to to what ever(follow people, beg for monies, shoot people, make sandwhich, robot [penguin, cat, chicken].


the only game making experience i have is via gamemaker (long time ago), visual basic (space invaders) and random flash based games back in 2004-2005ish


never got into bigger story of game programming :X (basically this will be my bigger step into non-robotics based programming)


mainly I Just wanted to easier way to make games :P (basically tools (especially guis/what you see is what you get) to make it easier xD )

Jul 13, 2012 at 6:04 AM

FlatRedBall involves a lot of coding on your part. None the less, XNA is a good starting point if you want to learn.

IF not, your best bet as I said is to recompile some engines. If you private message me independently of some that you had in mind, I can provide instrctions or quickly test for you. As for porting complexity, from what I gather that depends on how much it was designed for mobile in mind. =)

Jul 13, 2012 at 6:35 AM

long PM sent <P

Jul 13, 2012 at 9:27 AM

I've just sent a PR with my latest few fixups for PSS:

Thanks to xesf and SiENcE for finding and telling me how to fix the bugs :)

Jul 13, 2012 at 11:26 AM

v0.99 of the PlayStation Mobile SDK was released today. 

Hopefully not much within this port will break.



Jul 13, 2012 at 11:31 AM

Btw, Dean and I spoke to the PlayStation Mobile lead developer and his boss at develop-brighton yesterday. If you want PlayStation Mobile to support PS3, which I most certainly hope it will, please go to the PSM forums and make your voice heard. The more developers that let them know they want it, the more chance we'll get to see MonoGame on PS3. 

The guys we spoke to certain gave the impression that they understand indies and more importantly are passionate about good, interesting games.

Also it may be worth thinking about release on PSM, as that market place will be less crowded when v1.0 eventually sees the light of day. Something to think about.



Jul 13, 2012 at 11:37 AM

Will test the new SDK together with the new pulled fixes and see if I can get the game run better.

Jul 13, 2012 at 3:35 PM

@danzel - I noticed this in your pull request...

"Handle Dxt compressed textures (by unpacking them like Android)"

... what texture compression does PSS support then? PVRTC? 

PS3 by the way supports DXT.

  - Tom


Jul 13, 2012 at 4:33 PM

Btw. todays news is

Jul 13, 2012 at 4:42 PM

I find this quote from that article extremely dumb...

"The interesting challenge is how do you put a touch interface on the PS3, because it doesn't have one,"

... DUH... you don't.  It shows the difference in the priorities between developers and Sony. 

Developers want an open platform for developing PS3 games.

Sony thinks of PSS on PS3 as an Android/Vita emulator.

 - Tom


Jul 13, 2012 at 10:42 PM
Edited Jul 13, 2012 at 11:23 PM

Damn Sony.

The new SDK version has changes in all namespaces and project target files. What a bunch of work to fix this. How come so later in version after getting SDK public this guys makes such change.

Edit: Done with the changes, but the game still runs with blank textures and some crash due to memory.

Jul 14, 2012 at 10:48 AM
danzel wrote:

I've just sent a PR with my latest few fixups for PSS:

Thanks to xesf and SiENcE for finding and telling me how to fix the bugs :)

Sound does not work correct. It seems that 

 this.Rate = 1.0f; in function Sound does not apply.

When i Play() a sound  this.Rate is always 0 and so the playbackrate it too slow.

Jul 15, 2012 at 3:15 AM

@TomSpilman - Currently PSS supports.... No compressed textures!

@SiENcE - I'll take another look at playback rate now :(

Jul 15, 2012 at 3:26 AM

Okay, sound properly fixed:

I haven't updated the PSS SDK references as I don't have the new one yet. Will do it next weekend if no one beats me to it.

Jul 15, 2012 at 11:32 PM

hi danzel,

i already converted everything to 0.99. I already forked monogame and send a push request for develop3d for another issue. I try to push the 0.99 changes too.

Today got my own Game converted and run on Vita. But one problem is left. Farseer Physics seems to be really slow. I have to dig deeper :).


Jul 16, 2012 at 6:29 AM

Hey SiENcE, I'm also interesting in using that physics engine on Android and the Vita. I'm curious, could you provide a starting point to porting some of this stuff? And if you'd like, I'd be very interested in helping you profile and speed things up on the Vita, we both can benefit, and the MonoGame community as a whole. Let me know!

Jul 16, 2012 at 12:27 PM

Ok. I create a github repository for my libraries ports TileLib & Farseer Physics for PSSuite 0.99.

Jul 16, 2012 at 10:58 PM


It is a crime that PSS doesn't support compressed textures.  This is totally a failure of their SDK team... the hardware supports it just fine.  Texture compression gives you 4x to 16x more texture memory. 

Modern video games would look at the very least 4x less detailed without compressed textures.... you guys need to scream bloody murder at them for it.

  - Tom


Jul 16, 2012 at 11:23 PM

@SiENce - awesome, good to hear.

Yeah farseer is really slow on Vita. If you turn off TOI, reduce the iteration counts, reduce the amount of dynamic bodies in the scene and target 30fps you can probably get it to work okayish. (Maybe even at 60fps!)

Also the first time the JIT hits any function there is massive slow down while it is compiled, so you'll probably want something that warms up your engine and Farseer before the user starts playing. Things run faster when not running under the debugger too.

@TomSpilman - I know. Sony don't seem to be taking PSS seriously, its pretty disappointing.

Jul 17, 2012 at 5:42 AM

Where is the repository located SiENcE? I'd really like to get it up to speed - it's a shame if we can't have any physics based games. And I really only want to simulate a couple bodies but from what I'm hearing even that is asking a lot. 

Jul 17, 2012 at 9:34 PM
Edited Jul 17, 2012 at 9:36 PM

Here is my Farseer Physics repository.

Just note that i also added project files for Playstation(R)Mobile SDK, MonoAndroid, Mono on Windows, Mono on Linux. Not all problems are fixed. Search for "PSS" in the code and your will know what is on TODO (just take a look at the last 5 commits).

TiledLib follows soon. It seems, that TiledLib is the reason for the low fps (~5fps on Vita). But i use the same code on my Windows Phone 7 and it's blasting fast.

So it seems there is an issue with Monogame Spritebatch rendering on Vita.

Jul 17, 2012 at 11:15 PM

Is it an issue with multiple tilesets?

(Maybe GPU texture binding is really slow...) 

Jul 18, 2012 at 12:04 PM
Edited Jul 18, 2012 at 9:47 PM

I don't know. I have 5 Tilesets and 5 Layer (5fps). I reduced it to 1 Layer (uses also one tileset) and it's a bit faster but not that much (15fps).

I also use an older version of TiledLib. The current one does not have Maprendering. It's not done in the library anymore.

Here are some pics:



Jul 19, 2012 at 6:45 AM

Pretty certain slow spritebatch rendering is my fault.

I'm reusing the same VertexBuffer within a frame if you issue multiple begin/end calls to a single SpriteBatch. (This issue is mentioned way above in this thread).

I'll have a go at fixing it in my fork now.

Jul 19, 2012 at 7:15 AM

Try the latest patches from my fork/branch here:

If that improves it I'll submit a PR. In my testing this doubled my framerate when using a SpriteBatch multiple times in a frame.

Jul 19, 2012 at 4:52 PM

I had as well a very slow game it was mostly because the sprite batch.

Unfortunately I can't test this branch right now because I had issue with my new PC and its back to the warranty.

Jul 19, 2012 at 10:20 PM
danzel wrote:

Try the latest patches from my fork/branch here:

If that improves it I'll submit a PR. In my testing this doubled my framerate when using a SpriteBatch multiple times in a frame.

Thx danzel. I tested it on Vita and it improves the fps up to 29-30fps. If some action is on screen fps drop to ~15fps sometimes. Its def. an improvement, but i think we need to improve it further.

Here is a short gameplay video :-)

Jul 20, 2012 at 4:59 PM

Very cool! I had a chance just now to check out your Farseer port, but I see you added XNA classes to it which causes conflict? Is there any reason behind this? :(

Jul 20, 2012 at 8:03 PM

What do you mean? Who is conflicting what?

It works in my setup.

Jul 20, 2012 at 8:36 PM

There's a duplicate Vector2.cs, Vector3.cs etc in the "SourceFiles" directory. It produces a bunch of warning about hiding the MonoGame classes.

Jul 20, 2012 at 8:48 PM

I didn't put this in. I forked it from a direct copy of codeplex.

Jul 20, 2012 at 8:48 PM
Edited Jul 20, 2012 at 8:50 PM

I only outcommented some parts (ie. Explosion) and added a Hashset class for PSSuite compatibility.

Jul 20, 2012 at 9:43 PM

Correct me if im wrong but if I remember correctly, you have to specify "XNA" as a symbol in farseer to prevent it from defining it's own Vector2/3 types.

Jul 21, 2012 at 12:01 AM
Vaughands wrote:

There's a duplicate Vector2.cs, Vector3.cs etc in the "SourceFiles" directory. It produces a bunch of warning about hiding the MonoGame classes.

I think you only need to load the right project file :).

take and everything is fine.

farseerphysics\Branches\XNA\Farseer Physics [PSSuite].csproj

Vector2/3 are not included in this solution.

Jul 21, 2012 at 2:35 PM

Send a pull request with all 0.99 sdk compatibility fixes

Jul 21, 2012 at 2:55 PM

SiENCE PR Pulled. 

Does anyone know if Draw Primitives works in the PSS codebase.



Jul 21, 2012 at 3:36 PM

Doh! I didn't realize it was a branch! My bad, sorry SiENcE!

Jul 22, 2012 at 9:30 PM

@CartBlanche - Should work, I have implemented it. It's only been tested very basically though.

Oct 8, 2012 at 8:55 PM

Hi all,

What is the current status of Monogame implementation for Playstation Mobile? I saw that Sony released a new version of PSM SDK and i tried to run a Hello World game using the Monogame, but i got some compilation errors in the Monogame project. 

I'm using the develop3d branch and i tried to compile it using the Mono develop for Playstation Mobile.



Oct 8, 2012 at 8:59 PM

Due to the heavy in development nature of the develop3d branch, PSM port is currently broken and no one has had time to fix it and to make sure everything works with the new PSM SDK release. If you'd like to do that and send us a pull request with the fixes, we'd greatly appreciated that.



Oct 17, 2012 at 2:24 PM
Edited Oct 17, 2012 at 2:25 PM

Hi people

The PSM is a very importante platform to Monogame in our efforts to engage more people to the Project. But saddly the PSM still broken :( 

Somebody know was the latest valid branch? I want help to fix this.

Dominique, you have any clue what's wrong ?



Oct 17, 2012 at 2:34 PM
Unfortunately we have very few people who build for PSM. It would be good to get the latest develop3d working on PSM as that is what will be included in the 3.0 release.