Changes

Jump to: navigation, search

Jim Dramis

894 bytes added, 04:43, 24 July 2018
Questions and Answers
'''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.
 
'''GMK:''' We understand that [[Parsec]] is the first TI game to be released that used the high-resolution graphics mode of the video processor chip in the TI-99/4A. Can you tell us something about how sprites work in this mode?
 
'''JD:''' The problem with using the high-resolution graphics mode is not only being unfamiliar with it, but also understanding the constraints. First, it uses up so much of the VDP RAM that there's only 2,000 bytes of RAM free for the programmer to use. Also, at the time, we felt we could not use sprite automotion in this mode. The problem we had was that the scroll used up so much processor time that in order for me to move sprites on the screen, I had to use automotion. If I were to move the sprites pixel by pixel as I did in [[Munch Man]] and [[Car Wars]], it would be way too slow. I had to go to automotion or else the project would have been killed.
==References==

Navigation menu

MediaWiki spam blocked by CleanTalk.