[thechat] School Science Project about video games

[Luther, Ron]

Terry said:

>>My 12yod has decided to do her science project on
>>video games
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>


Hi Terry,

Neat project.  ;-)

I didn't actually work on any games ... but I used to have the office
telephone number of <scans memory /> Chris? at Atari -- used to call and
bug him about playability features once or twice. (IIRC he was the guy who
built the Castle Wolfenstein game --- this was back when one person could
be responsible for a complete game. e.g. the ooooold days - when you could
actually call one of the developers and talk him out of beta releases!)

I do remember some of the early "technical" stuff, though:

I do remember some of the techniques used to construct some of those early
8-bit games ... character set remapping [the logs in the Frogger game were
actually the word "LOOOOOOOOG" scrolling across the screen using a remapped
character set].  {I disassembled the assembler and checked it out once.} Here
is how it worked: You loaded your graphic character set in "high" memory,
(like maybe you made the letter "A" look like a peace symbol), then reset
the memory limit to protect that memory, {remember "peek" and "poke"?},
then you poked a value into the register that identified the location for
the start of the character set data. Viola! Remapped characters.

Fast and slow - otherwise known as smooth and coarse scrolling.

HBI & VBI (Horizontal and Vertical Blank Interrupt processing) --- early
machines like the Atari 800 output to a normal TV set ... the screen was drawn
in bands from right to left and top to bottom -- there was a tiny piece of
time between the drawing of one line and the next (HBI) and a bigger slice
of time between the completion of one screen and the start of the next,
(VBI) - the time for the raster scanner to get from the lower left of the
screen back up to the upper right to start 'drawing' again.  During these
tiny slices of time you could get the processor to do "other" things -- like
play the music, check for player/missile graphic collisions, etc.

For example, the Atari 800 only supported 4 colors on screen, (in certain
graphic modes/resolutions), ... however, if you got the timing down you could
change the color register values halfway through the screen painting,
i.e. during an HBI, and with that technique have four colors for use on the
top half of the screen and a different four colors for use on the bottom
half of the screen.  HBI and VBI processing was a technique all game developers
had to have down cold.

Old game machines (Atari 800, Commodore 64) had special memory locations
(registers) for sound channels as well as for [Atari-speak] player-missile
graphics | [Commodore-speak] sprites.  In a shoot-em-up game you would shoot
something and it would explode ... what the game designer actually did was
assign graphics to these 'sprites' and then check the collision register --
if you shot something, the 'sprites' would overlap on screen - this would
set a bit in the collision register ... your game program would check the
collision register (during an HBI for example) and if there was a collision,
trigger a subroutine to display the explosion graphics and sound ... usually
done during a VBI.


Oooops ... off to a meeting -- HTH!

RonL.