http://blog.us.playstation.com/2008/06/06/playstation-edu/

It is a program to get development hardware into the classrooms of universities and colleges.

I am giving a talk about it at the Game Education Summit next week in Dallas.

[update]

Made slashdot!

In general, I find Cg more straightforward than HLSL. However, once I finished, it does not really make any difference to my app code because I have abstracted the shader layer away. Considering that I plan to stick with very straightforward shader files (and not even bother with .fx files), it probably does not matter in the end.

My next step is to create a job management system which runs on multiple threads…

I finally hooked up a screenshot function to the app as well as a mode to capture at 30fps. All of those images create a movie. It is not perfect, because the D3D function GetBackBuffer() stalls like crazy. I am still trying to figure out how to capture at a decent framerate without having to use a video capture card.

For the movie, it shows the brushes moving around the images, turning the cube, and a few other effects. Right now, there are very few rules for the brushes, so I need to add some more to see what happens.

The movie.

It is really nice that you can play PixelJunk Monsters via RemotePlay. I can sit on my couch and play the game on my PSP with headphones on, instead of taking over my main TV. The game works just fine and the music is even more addictive with headphones on.

The interesting thing when running in real time is that the brushes fade out and move around. It means that often, it is much harder to understand what the underlying picture is (not that the fish or crabs in the previous videos were easy to understand).

The entire engine is a multithreaded render which builds a command buffer in the simulation thread, while drawing the previous frame’s command buffer in the render thread. The synchronization is always tricky, but I have a number of debugging rendering modes which make it easier to figure out what is going on. At compile time, I can select:

• Multithreaded double-buffer
• Single threaded double-buffer
• Single threaded single-buffer
• Single threaded immediate

When I am adding a new feature, I start at the “easiest” level (single threaded immediate) and work my way up from there. Usually, if the single threaded double-buffer is working fine, then the multithreaded one is okay as well.

I am using Direct3D for all of the rendering. Along with the command buffer, I have a vertex buffer. Since it is created with a FVF (vertex description), I can use it with the offset command to just fill it with vertices. Since I am used to the PS2 and PS3 ways of rendering, this feels very natural. I don’t have many fixed vertex buffers with the brushes…everything is dynamic and generated per frame.

Currently, I have flower pictures as the background. I create a cube with a flower per panel. The panel which is facing the user is the drawing panel, although I have a number of buttons which cause other things to happen to the image (spawn a 1,000 brushes, collapse all brushes to the center, etc). I sort the panels based on the middle of the panel and get some rendering back to front. It is not perfect, but it does the trick for most angles.

The next step is to add the scripting back into the engine. With my previous Peduncle work, it was all non-realtime and I just rendered out a movie. I need to get some level of control over the input to the system…relying on my joystick movements in realtime won’t cut it.

The other thing is to add some more job/task management code. While I have the simulation and rendering in different threads, there is a lot which can be spawned off to other threads. For example, all of the panels are distinct at the moment…they don’t depend on other panels. I am planning to spawn a number of threads at the start of the app. Then they can be woken up by tasks which need to run and then go back to sleep when the task finishes. The goal is to not spawn/kill threads every frame, which is very expensive to do, but rather reuse the threads.

After wandering around for a while, I went to get breakfast. The best breakfast around the fish market?  Sushi!  At 7am, I was eating maguro, saba, uni, and other wonderful raw food.  Got to love Tokyo!

The basic architecture for the renderer is to build a render queue (a command list), then execute all of those commands. In fact, this is almost identical to a PS2 rendering DMA list. Xgkick the data and let the GS render.

My renderer has four modes:

• Immediate
• Single threaded, single buffer
• Single threaded, double buffer
• Multithreaded, double buffer

Immediate is useful for debugging, although it is extremely slow. Whenever a command is inserted into the render queue, it is immediately executed. Great for stepping through code, since the rendering happens when it is coded from the simulation thread. Very bad performance.

Single threaded, single buffer puts all of the commands into a buffer. At the end of the frame, it goes through those commands and renders them. There is only one buffer, which is cleared at the end of the frame. This is good for making sure that your commands are executing properly, without having to worry about threading issues.

Single threaded, double buffer is almost the same as the “single threaded, single buffer” except when the rendering happens at the end of the frame, it renders the data from the previous simulation frame. This is because there are two buffers. Again, easier to debug since it is a single thread, but more difficult to understand the rendering queue because it is the previous frames data.

Multithreaded, double buffer is the normal rendering mode. At the start of the frame, the simulation thread begins to fill a render buffer with commands. At the same time, the render thread is processing the render buffer from the previous simulation frame. At the end of the frame, both threads synchronize and the buffers switch. This is the fastest mode, but very hard to debug.

People have asked why I don’t have explicit code running in the render thread, such as object->draw(). In reality, one of the commands is a callback, which could do something like that. However, that tends to make thread synchronization and mutex hell. By explicitly dealing with commands, there is very little synchronization between the simulation and render threads. It also makes it much better for systems like the PS3, where the SPUs are doing a lot of the work and you have to DMA data to them anyways.

Hopefully, I will have some cool movies soon now that the basics are in place.

Previous to my game career, I used to do high end medical VR. Many, many years ago, I had an SGI Onyx as my “desktop” computer. With all of the extra hardware like dual graphics pipes, Polhemus sensors, gloves, and head displays, I probably had around a million dollars of hardware for my personal use. However, even though I was on a quad-processor Onyx, there were exactly the same problems which I am dealing with today…and my computing and graphics power is probably much greater now.

I have seen people write code to mask the differences between the various threading systems, like pthreads, win32 threads, SPU tasks, etc., but it never feels right. I guess that most of what I have looked at feels like a hack. In the PS3 model, you want a ton of little tasks. In the XBox360/quad-core model, you want monolithic threads which use each core fully. Thankfully, the little task model works fine on the XBox360 (as developers are beginning to figure out). It is still up to the developer to understand what of their data is read-only vs read/write, since that can make a huge difference in a non-unified memory environment. At home, with my brush work, I am looking at how to parallelize the brushes across multiple cores to try and get to interactive rates.

In the end, this post is more musings and rants about the current state of things. In general, most game developers are beginning to realize that the raw performance of their code is much less important to the memory model and data traversal. And with most CS students out of college learning C# and Java, they really do not understand what is happening at the raw RAM level…