Supported Platform Related Questions===

  • Will Playstation Suite come out on the PS3? And if it doesnt why not?

Sony has stated that they are currently having internal disccusions regarding whether the PS3 will be a future Playstation Suite supported device. Some of you may be wondering why is this even a debateable point right now and the answer is because long story short, its going to require a huge commitment of porting the Mono Runtime to the Cell architecture. There is a page on the Mono Projects website regarding the PS3 .

According to that page there is a version currently being developed and therefore we can assume that its very likely to see the PS3 supporting PSS in the future if it satisfies SCE's market expectation and the port is fully functional.

  • Why am I running out of memory so fast? Whats the deal, doesnt the the Vita have alot of RAM?
  • Can I use all four of Vitas cores? Im confused why cant I use all of its GPU power?

To provide the program once for cross platform functionality that the SDK provides, this comes at the sacrifice that our applications and games can only be as powerful as the weakest device can handle. Some developers are creating libraries that they claim will be able to optimize according to which hardware is being run. However there is no information if Playstation Suite will move out of Beta still providing this functionality, if it is in fact possible as of right now.

  • So how much memory am I able to use?

As of now the amount of RAM provided for a Playstation Suite program is 96 Mb. 32 Mb reserved for the stack (objects, variables, ect) and 64 Mb reserved for the heap (MP3s, PNG, MP4 ect). The app.cfg located in your project's folder contains varibles where you can change the values however you like as long as the sum of the allocations doesnt exceed 96 Mb. One important aspect about programming for Playstation Suite is to remember that if you are loading art assets into RAM you have to make sure you destroy them using Dispose(); when you are done with object using the art resource. Otherwise the reference to the file in RAM falls out of scope and you cause a memory leak.

In my personal experience, if you are running into segfaults and your game doesnt have 3D models with 10,000 polygons (sarcasm) chances are you have a memory leak somewhere.

Programming Language QuestionsEdit

  • Can I use any other language than C#? You say you will support other languages in the future, does this mean support for C/C++? Can I make a wrapper for this C library for codecs and then use it in my game?

The answer to all these questions is at the moment No. The reason is because the actual programming language we are programming in is called CIL(Common Intermediate Language). This is compiled in the runtime during program execution and transformed into Machine code. C# is one of many languages that can be designed to build into CIL. What this allows is for you to create a portion of your program in C# and a portion of your program with the CLR implementation of Python called IronPython. And run them inside the same program. When Sony says in the future they would like to support more languages. Its not because the Mono Runtime isnt capable of compiling those languages right now. Its just the SDK has only been written in C# at this point. Its not that PSS doesnt already support languages like Visual C++ (managed C++ very different), IronPython, F# ect. Its just there are no libraries for them. (I havent personally comfirmed whether or not this works in practice, but theoretically it should work as the mono runtime only sees byte code, however sony may be explicitly preventing these languages form being compiled on monodevelops side. If somebody can test this and confirm it let me know).

  • Why did Sony choose C# over a native language like C or C++. Isnt native language faster and better than C#. C# should be called C Flat because C++ is better, blah blah blah.

Sony chose to take the managed code approach for several very interesting reasons. The concept of programming in managed code is that we are ultimately taking the power of unlimited freedom away from the programmer to gain the benefit of simplicity in the way which we code. What does that mean?

The only way I can describe it to you is by giving you a few examples of what you can and cant do in a language like C and a language like C#.

In C we consider it an abstract high level language designed with the capabilities to directly talk to the hardware. C was designed in the high level abstract sense to be elegant to the reader and make sense more to the programmer in how we as humans logically think in our every day lives. For example we dont tell our brains to store the number 7 at that spot in our brain, and then to move it from one spot to the other. Or tell it to store it in a special adder part in our brain to do calculations with it. We just think of two numbers and create the concept of a new number out of it.

In C we actually do that very much like how we do it in the real world. Int a = 1; int b = 2; int c = a + b;

When we say a language is more and more abstract, we mean abstract to the computers point of view on how it thinks. C# is considered a very abstract language for reasons ill explain in a moment.

C while being a high level language, it does have features of directly talking to the machine at the same time. What I mean by saying that is we can do things like program operating systems, and manipulate memory almost entirely in C alone. We create an operating system out of C and Assembly Language, ect. The point is we have alot of freedom to optimize and tweak our programs at the hardware level. The idea of native code being "faster" than managed code comes from this idea of being able to make tweaks here and there around say for instance an algorithm that repeats over and over again thousands of times. Little tweaks can realistically make signfigent performance enhancements.

However, The reason Sony doesnt want us using native code to communicate with the hardware is because with great power comes great responsibility. And there are people out there who feel its their personal responsibility to free the computer slaves that they believe companies like Sony and Apple close to oppress their consumers. Okay in reality, these people are called hackers. Some are ethical and have a convincing point against things like DRM and the fact that they should be able to execute their own Code on a machine. However they are equally unethical because they will knowingly hack a console and RELEASE the exploit to inspire others to do the same. (Some even profit from it which is also unethical of their own principles they say they believe in)

The problem with native code is that nobody is a perfect programmer. Operating systems are literally millions of lines of code and somebody somewhere can find a way to break the system. Unlike God, we do not create systems of logic like the universe that cant be broken by somebody else perhaps more clever than we are. With native code we can possibly break systems that prevent piracy. With managed code I personally think its highly unlikely thats possible unless you were extremely motivated.

Managed Code is contained and isolated from seeing anything beyond what its allowed to see and interact with. In that sense we are putting our programs in a box with some toys and telling it to play in there. We the operating system can see whats going on and can describe it. We can also put more toys in and take them out. However the program can only ever play with what toys we give it. Another interesting trait about managed code, is that we can move the box to different enviroments and its still a program in the box. The only thing that needs to change is how I describe whats going on in the box to the new enviroment.

This is how we can code once for many different hardware environments and get the same results *with minor inconsistencies occasionally because of bugs in the runtime*.