8,732
edits
Changes
no edit summary
==Interview==
The following is from an interview done by Gary M. Kaplan that appeared in the January 1983 issue of 99'er Magazine, page 26 - 27<ref>An Interview with Jim Dramis - Game Designer and Programmer Extraordinaire - ''99'er Magazine: January 1983, pgs. 26-27, and 38-39''</ref>:
[[image:Jim Dramis - Designer's Spotlight.jpg|600px|thumb|left|An Interview with Jim Dramis - Game Designer and Programmer Extraordinaire]]
'''JD:''' Well, like I said earlier, I get more enjoyment from programming than actually playing the games. Because of this, I really haven't tried to get high scores. In [[Car Wars]] my top score is about 33,000; [[Munch Man]] is about 122,000; and [[Parsec]], about 77,000. So I haven't even broken 100,000 on [[Parsec]] yet! They're good scores, but not even close to the top scores. One of the problems is that we have a debugger here, and I can easily cheat my way through the games. And you get so used to boosting yourself up to the higher levels...you've already been there, and it's so easy to do that you don't really want to take the time to get there legitimately.
'''GMK:''' Can you give us a little background on how [[Parsec]] eveolvedevolved? '''JD:''' We started [[Parsec]] in the middle of February and completed it in the middle of July, so that was five months. But that was with two of us working on it. Paul Urbanus, my partner, was a summer student here; he worked on [[Parsec]] for two months. The game therefore really took a total of seven man-months to complete. Paul certainly did help tremendously in getting it done; he wrote several of the major subroutines such as the speech interrupt-driven part of it, and helped speed up the scroll subroutine. Paul also modified the line-drawing subroutines that he had already been through [the LINES demonstration program that comes with Mini Memory-Ed.] for use with [[Parsec]]. '''GMK:''' What was the major technical problem you had to overcome? '''JD:''' Well that would have to be the scrolling routine. There was heavy access of VDP RAM. And any time you do that, you run the real risk of slowing the whole thing down tremendously. Paul used the trick of loading some of the program code into the fast CPU RAM on the 16-bit bus. This gave us about a 20% boost in speed of the scroll routine.
==References==
