Developing for PS3 – Part 3 – Programing

January 5, 2011

Writing code is obviously the primary (along with creating art assets) thing that’s involved in game making. But I’m also not sure what exactly your all expecting me to say about it. There isn’t much that is legitimately specific to PS3. If your familiar with C++ and OpenGL then you are pretty much good to go. If there is something you would like to to write about then let me know. Would you be interested in reading a sort of walk through of building a simple game? If so then what kind of game? Platformer? Until then here is… something.

Step 1

Get a copy of Visual Studio and install it. Microsoft Visual C++ 2010 Express is completely free and just as usable as the full retail package.

People hate on Visual Studio but its a perfectly likable IDE and there is nothing wrong with using it. With the benefit of little things like syntax highlighting it is at the least preferable over writing in a simple text editor like notepad.

Plus it will enable you to compile Windows builds of the stuff you make which will save you a ton of time when it comes to testing anything that isn’t PS3 specific (like collision detection or jump heights). You wont even need to make your own Visual Studio Project files. The testapp along with most if not all of the other samples included with the PS3 1.92 SDK come with their own pre made vcproj and related files.

Step 2

Developing with the official SDK leaves you with two APIs to choose from in terms of rendering. GCM and PSGL. GCM is specific to the hardware and is as low level as it gets and as a result what you make with it will (or should) preform somewhat better then if you use Sony’s implementation of OpenGL. But that being said PSGL is pure awesome. Its all that I use and its what I highly recommend using.

PSGL is OpenGL ES 1.0 complaint meaning that if your noobish there are tons of resources available online with information about writing for it. It also means that you wont be teathering yourself to PS3 for ever. OpenGL exists in some form or another on effectively every platform in existence so its a good idea to become familiar with it and it will make it a lot easier to port anything you write. It also supports a lot of stuff that isn’t a standard part of OpenGL ES 1.0 like vertex buffer objects and NVIDIA Cg shaders.

If your using PSGL then there is no need to start completely from scratch. That testapp you compiled uses a really great frame work that is included with the SDK and there isn’t any reason to not continue using it. So make a copy of the testapp folder and lets begin editing it.

Step 3

Open up the contained and pre made Visual Studio project.
Agree to all the update/configuration junk.

Now under “build” select “Configuration Manager” and in the window that pops up set the “Active solution configuration” to “Win32Release” and click close.

Under “Build” again select “Build Solution” and it should now compile a version of the program to run on Windows (you should still be using MSYS when compiling for PS3).

Unfortunately your likely to get some errors that you will need to correct.

If when attempting to compile you are informed that “LINK : fatal error LNK1181: cannot open input file ‘dinput8.lib'” then download and install this. Then under “Project” select “TestApp Properties…”, then “Configuration Properties”, then “Linker”, then “general”, then “Additional Library Directories” and add the address “C:\Program Files\Microsoft DirectX SDK (November 2008)\Lib\x86”. That address may differ if you get a different version of the DirectX SDK. You should probably run a search on your computer for “dinput8.lib”. You might already have it.

If you run into any other compiler errors then post them in the comments and I’ll try to help. Be sure to also check CoachLDE’s comments bellow for some additional guidance.

There should now be a “Win32Release” folder containing an windows executable of your program.

Step 4

Remember how I said that the frame work the testapp used was worth reusing? It is. But the testapp uses more of it then your going to want. Your going to want to take control over the camera system and create your own so you might as well remove the camera system that is in place now and with it strip out a few unnecessary layers of that frame work. Well we are at it we can cut out that wire frame grid.

and at the moment I don’t really feel like writing out every line that should be changed to accomplish this. I’m not even sure that anybody cares. So I’m not going to for now. Yay I’m a horrible tutorial writer.

You can download an edited version of the testapp here or here.

Along with striping out the old camera system and the grid I also made some other slight changes including adding binding for sixaxis controls and all keyboard keys (instead of only the space key as it is in the original testapp) so your setup to use them. Additionally I removed the use of debug text which admittedly is something you may have found useful.

Both the original testapp and my lightly edited copy are short enough for you to be reasonably expected to read so you should read them. Once you’ve read them then start editing them. Make small edits of your own, recompile, see what changes when running the final executable, lather, rinse, repeat. Trial and error is often the best way to learn.

Developing for PS3 – Part 2 – Packaging

January 4, 2011

Disclaimer: As with any guide there is the risk of information becoming outdated and tools deprecated. This is a perfect example of it. The text bellow explains the process I used for packaging homebrew when I was still using a jailbreak device. But since then CFW has become the predominant method for enabling homebrew and at the time of writing this disclaimer no CFW will support the use of the eboot.bin files generated using the executable mentioned bellow in Step 2. At the moment it is my understanding that geohots tools are a necessity if you wish to play your homebrew on CFW.

Another mildly boring but necessary thing that you are going to need to be able to do is package that newly compiled testapp and anything else you make.

You can temporarily get around the need for making installable PKGs by using programs like PS3Load. It didn’t seem to work for me the few times I tried it but I assume it must work in some conditions. Its certainly worth looking into. I had found its Wii counterparts helpful. But in any case your often still going to want or need to package your PS3 homebrew.

As usual I’m sure there are better ways to go about this but this is what I have been doing.

Step 1

Grab a copy of CFWProphet’s PS3 PKG Tool. The latest release of it has been renamed ACID v1.0 and can be found here.

Despite having the same name it should not be confused with CFWProphet’s PS3 Acid CFW. When actually running them both ACID v1.0 and PS3 PKG Tool v0.6 still refer to themselves as PS3 PKG Tool v0.5. I don’t know why it is the way it is.

If you don’t already have and don’t want to make a forum account you can alternatively get the older 0.5 version here.

Step 2

Copy or move “testapp.elf” into the PKG Tool’s folder.

create a shortcut to “make_fself_npdrm.exe”.

Its included with all versions of the PS3 PKG Tool. With “ACID v1.0” it sits in the folder at all times but with “PS3 PKG Tool v0.5” it is only accessible when the tool is running. I assume “make_fself_npdrm.exe” is contained in PS3_PKG_Tool_v0.5.exe and gets extracted when the program runs and then deleted when its shut down. I don’t know why. Similarly I’m unsure why several other files that come with the tool including the MSYS related installers are set to be hidden. There seem to have been a lot of odd choices made in creating the tool. Maybe it was intended to make it seem more organized in some way.

In any case “make_fself_npdrm.exe” is also included with the SDK and should now be located at “C:\usr\local\cell\host-win32\bin”.

Edit the shortcut to add ” testapp.elf EBOOT.BIN” to the end of its target address. Then run the shortcut.

The “EBOOT.BIN” file that should have just been generated is the actual software that will run on your PS3. Inside of the PKG Tool folder create a new folder called “USRDIR” and move “EBOOT.BIN” into it. Any media that your program will use (like 3D meshes or textures) should go into that “USRDIR” folder. Everything in that folder gets included in the final PKG.

Step 3

Start up the PKG Tool and enter 7 to launch the SFO Editor. The editor is fairly self explanatory.

Under “Catagory/Patch” set its category to “HDD Boot Game”.

Under “general Parameters” enter a four letter word first part of the “Title ID” and enter five numbers for the second half. This text will dictate where on the hard drive the package will be installed to. If for example you entered “CUBE” and “66666” then everything in your “USRDIR” folder will show up at “/dev_hdd0/game/CUBE66666/USRDIR/”. This also means that its important that you pick a name that’s unique to the program your packaging. You obviously cant have two programs installed at the same address.

You can enter whatever you want for the “Title (default)”. That is the text that will appear next to the icon in the XMB.

You can use whatever you like as your programs version number but it will cause problems generating the PKG if your inconsistent about what version number your labeling it as.

Don’t forget to tick any/all resolutions and audio formats that you will be supporting.

Save your SFO in the PKG Tool folder as “PARAM.SFO”.

Step 4

Return to the PKG Tool and enter 8 to make the necessary “package.conf” file.

type in 6 random characters
followed by a dash
then enter both parts of the Title ID you used in your SFO (no dash or space between the two parts)
followed by an underscore
followed by two zeros
followed by a dash
followed by 16 random characters.

Hit enter.
It will generate some random numbers.
Hit enter again.

Enter “Free”.

Enter “GameExec”.

Enter the version number of whatever it is your packaging.

If you would like to you could really just do this step in notepad or some other similarly simple text editor. The contents of the “package.conf” file should end up looking something like this.


Step 5

Load up your favorite image editor and make a 320×176 PNG and name it “ICON0.PNG”. Place it into the PS3 PKG Tool folder (NOT the “USRDIR” subfolder). This image will be used as the icon in the XMB.

You can also add the following images but they aren’t really necessary.

“PIC0.PNG” 100×560 this image is best suited for a larger title or logo. It fits on screen bellow the horizontal cross media bar and to the right of the vertical one. Unlike with the background you shouldn’t need to worry about parts of this one getting cropped off screen for people with 4:3 TVs. If you include one of these then when its loaded and being drawn on screen the text that says the programs name is turned off.

“PIC1.PNG” 1920×1080 This image is used as the background. Keep in mind when making this one that a non trivial amount of the left and right sides will be cropped off in 4:3 mode.

“PIC2.png” 310×250 I don’t actually know what this image is for and haven’t bothered checking yet. The few games that have one just leave them blank. Feel free to use one and post the results in the comments.

Although retail games tend to use 24bit images for “PIC1.PNG” it supports the use of 32bit PNG files for all of them. This means that you can use alpha channels for all of them. So you can layer the images and leave peoples background themes partially visible.

Its my understanding that “PS3LOGO.DAT” and “SND0.AT3” relate to adding audio and using video in place of the icon. But I haven’t looked into that yet.

Step 6

Return to the PKG Tool one last time and enter 9. If all goes well it should generate an installable PKG for you. Copy it to a USB mass storage device, install it and have some fun toying around with it on your PS3.

Developing for PS3 – Part 1 – setup

January 1, 2011

I got an email requesting a tutorial on how to develop for PS3. Its something that other people have previously asked me for assistance with which leads me to believe that there are probably more people lurking around here that want to get into homebrew development but need a little help doing it. So I figured I would write up a series of short tutorial and post them here for public consumption.

This initial tutorial covers how to first get everything setup. Its something that’s already been covered repeatedly but regardless its still something that you obviously cant begin developing without doing.

Step 1

The first thing you need to do is decide what software development kit you are going to use. I use the leaked official PS3 SDK v1.92 so that is what this tutorial will focus on. But its worth noting that PSL1GHT is definitely more appealing for ideological and legal reasons, is catching up with the official SDK in terms of functionality and is what most other developers in the PS3 homebrew community are either already using or moving towards using. There have also been more recent versions leaked then 1.92 of the official SDK which may differ slightly.

Also worth noting is that I use Windows. Things may vary depending on your OS of choice but unless I’m mistaken it should be possible to get any of the available SDKs working on almost any major platform.

You can find still active links for the 1.92 PS3 SDK at the address bellow. Its not where I got my copy (I don’t remember where I got it) and the image included in the post is of community made software that isnt actually included with the SDK which makes me think that the person who posted it didn’t actually know what they where posting. But I’m fairly certain the files linked to are correct.

If anyone requests it I’ll upload the SDK elsewhere. Sony seems to have made some amount of effort to purge the SDK from the internet. There are a lot of dead links floating around to hosting services that have removed it for copyright reasons.

Step 2

At the root of your C drive create a folder named “usr”. Within that create another folder named “local” and within that one make a folder named “cell”.

Extract the contents of the rar file you just downloaded and copy it all to “C:\usr\local\cell”.

Step 3

The following two (inclusive of this one) steps can be found in PS3_SDKDoc_e.chm which should now be located at C:\usr\local\cell\doc\SDK_doc\en\chm. If you get stuck on anything then try consulting that document.

Download and install

You might as well download CFWProphet’s PS3 PKG Tool now as it includes the three installers and your going to want it later anyways.

Step 4

Edit your environment variable (Right-click on “My Computer”, select “Properties”, open the “Advanced” tab and click the “Environment Variables” button) to include the following.

name: CELL_SDK
value: /c/usr/local/cell

name: LANG
value: C

name: DTNETM
value: hostname or IP address of the Reference Tool

name: PATH
value: c:\msys\1.0\bin;

Step 5

Start MSYS and enter “$ cd /c/usr/local/cell/samples/fw/testapp/” (without the quotation marks). That will change MSYS’s current working directory to that of a simple test program that is included with the 1.92 SDK. Next enter “make”. That will make it compile the test program.

Now just wait for it to finish compiling.

If all has gone well you should have a newly generated “testapp.elf” file and a “testapp.self” file located at “C:\usr\local\cell\samples\fw\testapp”.

Tutorial: Making a game with DarkGDK part two

October 8, 2009

Part 2: Media

I’m not going to go into detail about making 3d meshes or textures right now but I will supply you with some to use.


Now lets get back to working on the game and use those art assets. Open up the project again and here’s what you’ve got to do in Main.cpp to load up everything and get your character moving round. I commented the hell out of it so even if you just copy and paste it all at once hopefully it will make sense. It will be easier to read from within the IDE.

//include DarkGDK and Sparky's collission detection which well be needing for later
#include "DarkGDK.h"
#include "SC_Collision.h"

//now declare the variables that we are going to need to use.
//I want to play in fullscreen without changing the resoltution and GetSystemMetrics is a good way to find out what the current desktop resolution is.
int screenx=GetSystemMetrics(SM_CXSCREEN);
int screeny=GetSystemMetrics(SM_CYSCREEN);
//dark gdk identafies 3d objects by a number and you cant assign multiple objects to the same number so I number them by the order there created in so you can check what the next available number is by keeping track of how many objects already exist.
int objcount=1;
//your going to want to remember what the object number is for your charecter since your going to be moving it around.
int youobj;
//isnt really neccessary but I like to record keypresses as variables
int up;int down;int left;int right;
//keep track of your movement speed and what angle your heading in.
//using double rather then int essentially means that it can deal with decimals rather then only whole numbers.
double movespeed;double moveangle=0;
//you will want to have a few multi purpose variables
double x;double y;double z;

void DarkGDK ( void ){
//now to start with the rest of the pre game setup.
//set the game resolution to the current desktop resolution which we found out before.
//since the games in full screen people probable wotn see this but its good to label things.
//set it to full screen.
//set what color will be shown on screen where there arent any visisble objects.
//throutle the frame rate to a predetermend rate (in this case 30)
//keep DarkGDK for doing anything anoying with the camera.
//turn off the mouse cursore.
//start up Sparky's collission detection.

//now we start loading those objects.
//load the room.
//load the texture.
//apply the texture.
//update the object count so we know not to assign that number to anymore objects.

//load your charecter model.
//keep track of its oject number.
//update the object count so we know not to assign that number to anymore objects.

//now we run the loop that the actual game occures in.
while ( LoopGDK ( ) ){

//update the charecter object and camera rotation based on mouse movements so you can turn and aim.

//check what keys are down.
//now if more then one key is down we need to change your movement direction and speed based on what combenation of keys are being used.
if (up+down+left+right==0){
if (up==1)if(down==0)if(left==0)if(right==0)moveangle=0;
if (up==0)if(down==1)if(left==0)if(right==0)moveangle=180;
if (up==0)if(down==0)if(left==1)if(right==0)moveangle=270;
if (up==0)if(down==0)if(left==0)if(right==1)moveangle=90;
if (up==1)if(down==0)if(left==1)if(right==0)moveangle=315;
if (up==1)if(down==0)if(left==0)if(right==1)moveangle=45;
if (up==0)if(down==1)if(left==1)if(right==0)moveangle=225;
if (up==0)if(down==1)if(left==0)if(right==1)moveangle=135;

//update your position and reposition the camera just behind you.

//update the screen.
dbSync ( );
//complete the loop.
//exit the game (by default DarkGDK automatically does this when the esc key is hit).

You might have noticed there seemingly random numbers being used when checking what keys where being pressed. It isn’t actually at all arbitrary. Each key on a keyboard is assigned a scan code and the dbKeyState() command returns a one if the specified key is being pressed down and zero if it isn’t. Here’s a nice little diagram to check anytime you want to know what the scan code is for a key.

Tutorial: Making a game with DarkGDK

October 7, 2009

I’m stuck getting something working in They DoNotDie (I can read the file names of everything contained in a folder one by one and I can load map data from a pre determined specified file but I cant get the freaken thing to load from one of those files that I just read the name of which means unless I’m going to cap how many levels you can have and use predetermined names for all of them then I have no idea how to go about having multiple maps in the game) and getting kinda frustrated. Anyways I’ll go back and work it out later but right its got me feeling like starting something new so I figured I would make a basic shooter with some time controls (I always felt like Time Shift was cooler then people gave it credit for being) and I figured I would in the process write a game making tutorial showing how I did it to help anyone interested in making games get started. Basically everything here is based on the assumption that you want to make a 3D game and you want to make it with DarkGDK and I doubt there will be much that you can learn here that would translate to anything else. Also I should point out that this is how I do things which isn’t necessarily ever the ideal way to do things. Anyways lets proceed.

Part 1: The setup

First up if you don’t already have it then you should download and install Microsoft Visual C++. You can get the express edition free at the address bellow. You can use DarkGDK with other IDEs/compilers but I seriously recommend you get Microsoft Visual C++ 2008 Express.

next up download and install the DirectX SDK

Apparently there are problems with Using DarkGDK if you install it before compiling something so first open up visual c++ express and click file/new/project at the menu bar. Then under Visual C++/Win32 select Win32 Project and enter whatever you want for a name and select ok and just hit finish for the next window the pops up. then go to build/build solution (or hit F7) and it will compile the project that was just generated. Now you can exit out of Visual C++ express and if you want even delete that project.

Then go download and install DarkGDK.

Open up Microsoft Visual C++ 2008 Express again. Hit file/new/project. This time select wizard then Dark GDK – 3D Game and name it whatever you want to name your game (I’m going with Time Frack). Then go to build/configuration manger and set it to release. Now open up Main.cpp (it should be listed in the sidebar so just double click on it) so you can start making changes and your also probably going to want to read through it once to get a basic understanding of how to do things (anything with // before it which shows up as green will be ignored by the compiler and in this case that ignored text very well describes what everything is).

Now since DarkGDK’s built in collision detection is terrible if you want to check for collisions with 3d objects then your going to want to use Sparky’s collision detection which is pure awesome. So just slap #include “SC_Collision.h” right bellow #include “DarkGDK.h” near the top of into main.cpp.

Unfortunately it wont work now because SC_Collision.h doesn’t actually exist or at least not on your computer. So go get it. Remember you want the DarkGDK version. I think your also going to need to make an account at the Game Creators Forum to get the download but if anyone wants me to I’ll upload it here.

Once you have gotten the download and extracted everything from the rar file your going to want to put the SC_Collision.h file (found in the include subfolder) and SC_Collision.lib (found in the lib\VS8 subfolder) somewhere and leave them there undisturbed. Personally I just took the include and lib folders and dropped em into my Time Frack project folder (which in my case is at C:\Documents and Settings\Owner\My Documents\Visual Studio 2008\Projects\Time Frack\Time Frack\). Next up your going to want to tell your game where it can find those important files. So hit project/Time Frack properties. Then under Configuration Properties/ C/C++ / General your going to need to add the folder that SC_Collision.h is in (in my case “C:\Documents and Settings\Owner\My Documents\Visual Studio 2008\Projects\Time Frack\Time Frack\include”) to Additional Include Directories. Next you need to do the same for SC_Collision.lib only this time under Configuration Properties/ Linker / General and add the address to Additional Library Directories. Then hit ok and then file/save all.

For now I suggest just leaving everything else as is and first hit build/build solution so we can compile the game and see if everything is working. In my case the compiled and ready to use executable was generated at C:\Documents and Settings\Owner\My Documents\Visual Studio 2008\Projects\Time Frack\Time Frack\Release but that might be somewhat different for you.

If that newly compiled executable works and when you run it some round polygonal shapes spin on screen then do a little celebratory dance and be happy knowing that your at least as smart as the average modern day child and can successfully install pre made software. If that executable doesn’t work or wasn’t generated or you got stuck on anything I said to do then feel free to vent your rage in the comments and I’ll do my best to calmly apologize for my mistakes or poorly phrased instructions and try to rectify the situation. This is getting a bit long so I’ll stop for now and continue tomorrow.