| Name: | Yaroid |
|---|---|
| Version: | 0.2 |
| Authors: | Dennis Payne |
| License: | GPL |
| Operating System: | Net Yaroze |
| Website: | http://www.identicalsoftware.com/yaroid/ |
Important Note: The Net Yaroze license agreement restricts what information can be provided. Descriptions of the various library functions will have to be limited to a high-level discussion.
Yaroid is a simple asteroid-like game for the Net Yaroze. It has none of the "advanced" features of typical Asteroid clones. Some enhanced graphics are available but you can optionally run with images similar to those found on the Atari 2600. The gameplay hasn't been tweaked sufficiently to make the game challenging.
Although computer penetration has grown phenomenally with the advent of graphical user interfaces, they haven't matched the simplicity of a console game system. There are no questions about hardware compatibility or software versions. Just put in the CD or cartridge and play. Life for the game developer isn't as picturesque I'm afraid.
Development for a console machine poses some interesting challenges. The machines are typically much less powerful than a desktop computer. Memory is scarce. Cartridges have fast access speeds but limited space available while CDs reverse the restrictions. The development kits are expensive and restricted by the console manufacturers. As the hardware becomes more powerful, many of the restrictions aren't as big a concern as in the past. However, the cost and availability of development kits have remained problematic for hobbyist and learning game developers.
Sony developed the Net Yaroze specifically to address the aspiring developer. It plays all the regular Playstation games, plus it can be programmed from a personal computer. Yaroze means "let's do it together" or "let's work together" in Japanese. Sony wanted to develop a community spirit that supports each other similar to the Linux community. Unfortunately they are no longer accepting new members. Hopefully this article will provide some insight useful for any console project.
The Playstation has two megabytes of main memory. There is no hard drive on the Net Yaroze and reading recordable CDs is not possible. Some developers have created file servers over the serial link or other devices. In general they aren't heavily used because the servers are limited to a single operating system which reduces the number of players who can try the game. A large portion of active designers still feel that the full potential of the Net Yaroze has yet to be demonstrated.
Designing a game that fits on a floppy is the first step, but not the
last. In the Makefile for Yaroid, the linker flags are defined as
"-Xlinker -Ttext -Xlinker 80100000". The 80100000 is the
hexadecimal memory address where the program is loaded. Additional hard
coded memory addresses are found in images.c. The programmer
needs to ensure that no object overlaps another. A similar problem
occurs with video memory.
Some users have written little utilities to determine placement
automatically but there are advantages to doing manual placement. For
example, Yaroid has a couple of images: the ship, asteroids, explosions,
and the title. In YInitialize, the program loads each image
into video memory with LoadImage. Afterwards the images are
never accessed again. Instead of wasting the memory, it can be used for
variables that are only used after the images are loaded like
GpuPacketArea. Another possibility is using it to store
screenshots.
Demonstrating Net Yaroze games is a difficult prospect since most people don't own the system. Screenshot are often the only visibility to the outside world. Developers with a tv tuner card for their computer can simply screen grab the game. Unfortunately those without such hardware are required to do a little more work.
One possibility is to simply use printf to output the image to the serial
console. Although I haven't tried such a method, other users have
commented on the unreliability of printf so I looked for another solution.
The serial console program includes a command to download memory from
the Net Yaroze. Since the Net Yaroze memory is not reset after execution
of your game completes, a screenshot can be stored in memory for later
recovery. The Yaroid patch is
relatively simple. Unfortunately I discovered that siocons can
only download memory at 9600 baud for some reason making the solution less
than optimal.
The raw screen images still needs conversion to a usable form. Linux has many conversion utilities but none seem to handle 16-bit color raw images. Ideally a 16-bit color mode should be added to rawtoppm. To do a quick test, however, I modified the tim2tga program to process raw image files. Here are the results:
The third screenshot clearly shows an irregularity that deserves explanation. There are three asteroids near the bottom of the screen. If you look at the top of screen you'll notice that a portion of the two lowest asteroids is duplicated at the top. Television displays don't display screen borders well. The first fifteen pixels out from all edges may or may not be visible to the player. Sony even requires that commercial games not put any crucial details in those borders. For example on my television the score and lives appears at the top of screen. I purposely duplicated the asteroids before reaching the exact edge so that they would always be visible.
Yaroid has some other design oddities that likely go unnoticed by the
player. Although the Playstation's central processor may be fast enough
for a simple asteroids clone, it does not have the speed for the 3D
graphics common in commercial games. Instead a separate graphics unit
offloads the task from the main processor. Ideally a game should keep
both processors running continuously.
In Yaroid, the draw_screen function draws the main ship, shots,
and asteroids. It loops through the various objects calling
draw_apic or draw_epic. These two functions in turn use
the Net Yaroze function GsSortFastSprite. After drawings all the
game objects, draw_screen waits for the next synchronization period and switches to
the new screen.
Between the drawing functions and synchronization, no collision detection
or object movement is performed, so it appears that Yaroid fails to keep the
two processors busy. A more persistent observer, however, would notice the
GsDrawOt call at the bottom of draw_screen. The
GsOT argument to the function can also be found as a parameter
to all the GsSortFastSprite calls. The graphics processor
doesn't go into action until the GsDrawOt procedure. The
other functions simply bundle up the display instructions.
So what is the oddity I referred to earlier? Think about the drawing sequence. Let's say you just pressed thrusters to escape the path of an oncoming asteroid. While you're deciding what to do, the graphic unit is painting the results of your previous turn. So that means the image on screen does not reflect the current game state. If the player and asteroids moved every refresh the latency might be visible, but currently the player moves once every four display cycles making the discrepancy extremely difficult to spot.
The Net Yaroze has such a vast array of capabilities that no single article could cover the system. Yaroid was never even designed to exploit its abilities. It does provide a good starting point with only limited use of the system library. There are still many improvements that could be made in Yaroid. Sound and music are obvious areas of improvement. If there are specific areas of interest let me know.