- Sun, 2014-01-19 05:44
- 1 Comment
Today using motion to control games is all the rage, Kinect, Move, Wii, Wii U et al but the PS2 was where it started, Eyetoy was Ground Zero. Deep into the 6th Gen with the 7th Gen licking our heals came the 11th Eyetoy game. I was faced with a seeming impossible task, tight deadlines and the need to push the PS2's pedal to the floor, I needed an edge, something to give me a boost, I found it - a Commodore 128.
During the development of Eyetoy : Kinetic Combat, which is a martial arts fitness game that utilises the Playstation 2 eye camera (of which the core systems were developed by Dan Phillips ( and some other people ), yes that Dan Phillips, of Armalyte and Last Ninja 3 fame ) for Sony’s Soho Studio. I was tasked with making a faceless ball with no real features, move randomly around a screen and show emotion. It had to mope, be happy, move excitedly etc. It needed to have ‘levels’ of happiness/sadness etc. It would spit out a challenge for the player, and then if they passed it, the ball would dance happily , fly around the screen and give you another. Fail and it got disappointed in you, and would let you try again, fail too many times and it gave up on you and moped arround before it gave you another.
Normally you would just get artists to make curves for you with splines in something like Maya and use them. Random movement, 10 levels of happy<->sad, way too much work, a real mess, it would seem to fixed, to predictable like the robot it looked like. Plus opening a file and trying to tweak and work with 400 splines all the same colour would be like finding that wrong patch cable in the ‘organic growth’ network room of doom or the wire wrap breadboard that needs to be tilted 3 degrees for it to work just right.
So I had to do it in code, ALL in code. Here is a video of how it looks, no this is not me, and no we didn’t play ‘Eye of the Tiger’ in the game ;)
Step 1. The method
First of all I had to figure out how I was even going to tackle the problem. In my youth I spent a fair amount of time playing with Lissajous curves on my C64 ( this was before I got a 128D ). They are basically a sin function on the X and the Y to form a continuous curve with a frequency setting. I know from watching them render in basic at 1Mhz that they have slow bits, where they curve, and fast bits where they shoot along straight-ish lines. That you can make them such they start and end at the same point. Making this same point 0,0 I then had a delta curve. This is handy as I could make a straight heading vector in 3D that is the start and end point then add the curve to two of the axes ( the Lissajous I made and know of are only 2D not 3D ) and still know that it will get to the destination and exactly the destination.
Step 2. The Tool
So a quick wish list of what the tool needs
- To render the curves in real time so that I can see them draw and move
- Show me and let me scale curves to be “right” in 320x240 ( the PS2 was running in this res)
- Have a scratch pad where I could keep “good” values
- Not take me a long time to make and debug Harharhar...
- Export values to the build or PS2 for easy real life testing.
Now what do I develop it in...
Well it is the default choice. I had the dev tools to make for it. But getting it to make and display 320x240 such I can see it, and draw slow enough would be “work” we are talking Win32 GDI WM_TIMER stuff here. I would also need to have multiple copies of VS open to run it and edit it, not a good idea.
The Commodore 64...
320x200 - perfect res, the top and bottom borders of the playfield are out of bounds for the ball to be usable. Also the Z movement needs some space in the Y to be shown. It is slow enough already. But writing the bitmap plot logic( BASIC 2.0 ) and finding screen room for the scratch pad and editor, would need raster interrupts.
The Commodore 128...
Basic 7.0 to handle the bitmap logic ✔
80 column 2nd screen that I can hold the program , the edit commands and a scratch pad on ✔
Send data to the PS2 or my C++ code. ✘Oh well hand read, type job just had to do, it was only about 30 numbers tops.
The whole editor would be about 20 lines of BASIC. Perfect! .
25~30mins later and the tool was done, with all bar one thing from my wish list. I'm fairly sure this wins the fastest build with highest percentage of features of any tool build at SONY.
Here is a BASIC program to get started with, it is not the one I used, as that is now owned by Sony Computer Entertainment World Wide Studios and it had an editor and extra features in it.
10 GRAPHIC 2,1
60 DRAW 1,PX,PY
70 X=X+ZX:IF X>360 THEN X=X-360
80 Y=Y+ZY:IF Y>360 THEN Y=Y-360
90 GOTO 40
ZX and ZY are the magic variables to change.
|SAD : ZX = 8, ZY = 2|
|VERY HAPPY : ZX = 2, ZY = 12|
|WELL DONE FLOURISH : ZX = 3, ZY = 4|
So should anybody need to read the C++ code they will find at the top in the comments, a Commodore 128 basic program and instructions to download x128. If only I could have added code that would use the camera to take a photo of their faces and send it to me when it happens.
Which brings me to another neat fact of the 128. Each game is archived all that is need to make it is collected, burned and stored somewhere, such that should we need it again it can be accessed for HD remakes or something. If I made a separate program the Windows code would have need to be put in, lots of code, vs projects etc. Will it still compile in the future, will the Win32 GDI still be there? Will they still be on a Windows pc? A Commodore 128 will always be a Commodore 128 and BASIC is simple enough that any programmer should be able to look at it and see what it does to replicate it in whatever dev environment they are in.