Loadstar 210/210.d81/t.bits

Text File | 2001-01-01 | 6.2 KB | 254 lines

u
          BITS: STATE TABLES

           by Scott E. Resh


    Your first question may be "What
exactly ARE state tables?" Well, state
tables are a method of QUICKLY
changing data from one state to
another, by replacing numerous
calculations with indexed addressing.

    The Run It file for this article
demonstrates just how fast a whole
screen's worth of color bytes can be
changed -- in a predetermined pattern
-- by using state tables. Pay close
attention to the SEQUENCE of colors
as they move.

    The colors are not in NUMERICAL
sequence, i.e. white does not follow
black, red does not follow white,
etc.... Sometimes the traditional
numerical pattern isn't what is
wanted. With state tables, the
pattern is up to the programmer.
Using a custom pattern would be quite
a bit slower than using the Black-
White-Red-Cyan- etc. pattern if you
didn't use the state table technique.

    Note that in the Run It file
screen memory isn't changing at all --
only color memory is being changed.

    Because there are 256 possible
color combinations for a hi-res color
byte, we need a state table consisting
of 256 bytes.

    For example, let's take a color
byte that says we have a RED
foreground and a WHITE background. We
want to change that to a PURPLE
foreground and YELLOW background. This
means going from 33 ($21) to 71 ($47).

    Where do these numbers come from?
Look at the hex numbers. Red is $2,
right? White is $1.  Red on white is
therefore $21. Purple ($4) on yellow
($7) is $47. This is the way color
memory is stored in your computer.

    After the PURPLE/YELLOW we want to
go to a LIGHT GRAY on DARK GRAY
combination, 71 ($47) to 251 ($FB).
We can't add a constant to the color
byte because the numeric difference
between the color bytes is not the
same! We could use a whole bunch of
CMP and BNE commands, but that's a
lousy idea for TWO reasons --

  (1) it could be VERY slow and

  (2) it would take at least 2560
bytes of memory for the program!  Why
2560 bytes?

    Imagine --

     CMP #COLOR1 ; Is it color #1?
     BNE N1      ; No, try next color
     LDA #COLOR2 ; Yes, load new color
     JMP PCOLOR  ; Jump to Put COLOR
 N1: CMP #xx     ; Is it color #xx?

    Each color byte (all 256 of them!)
would require 10 bytes of code.

    Now the fun stuff begins. Let's
imagine that we have a state table
consisting of 256 color bytes. Let's
take our FIRST color byte RED/WHITE --
33 ($21), and use it as an INDEX into
our state table. We want to change
the state of our color byte from 33
to 71. This means that position #33
of our state table must hold a 71.

    Our color byte now holds PURPLE/
YELLOW byte. Next we want to change
to LIGHT GRAY/DARK GRAY as mentioned
above. Numerically speaking, 71
($47) to 251 ($FB).

    This means that position #71 of
our state table must hold a value of
251. Here is a part of the code --

      LDX #0           ; Init index

 LOOP:LDY COLORMEM,X   ; Get OLD color
                       ;  byte

      LDA StateTable,Y ; Use as index
                       ;  into states

      STA COLORMEM,X   ; Store NEW
                       ;  color value

      INX              ; Loop back 256
      BNE LOOP         ;  times


    That simple little loop will
replace 256 bytes of color memory
with NEW values from our state table.

    If changing colors isn't your
thing, then don't worry. This simple
technique can be used for all kinds
of data handling. Adventure games
often use state tables to indicate
where you will go when you leave a
room in a particular direction.

    Or suppose that you wanted to make
a mirror image (for whatever reason)
of a hi-res screen. Keep in mind that
a hi-res screen is made up of 8000
bytes.  We need to do it FAST.

    Most people would do it by using a
little ROtate loop for every byte --

      LDA Data ; Get byte to 'mirror'
      STA Temp ; Put in z-page buffer
      LDX #8   ; Init count register
 LOOP:ROL Temp ; Rotate buffer LEFT
      ROR A    ; Rotate Acc RIGHT
      DEX      ; Loop back 8 times
      BNE LOOP ;
      STA Data ; Store mirrored byte

    A sequence of 8 ROL/ROR pairs
instead of the loop, would speed
things up. But it still wouldn't be
as fast as state table substitution.

    While the above loop would have
to be performed 8000 times, the
following loop would only need 32
iterations.

      LDX #0   ; Init index register
 LOOP:LDY Screen,X ; Perform the
      LDA TABLE,Y  ;  actual
      STA Screen,X ;  substitution

      INX      ; Loop back 256 times
      BNE LOOP ;

    The speedup is due to the fact
that the state table would already
contain the 256 rotated bytes.

    Don't let my little examples
limit your creativity.  Take the
concept of state tables and run with
it.

    After you've taken the time to
create a state table, they can be
incredible time and space savers.

 SR


 [Dave's Note:] Right you are, Scott.
A zillion situations can be controlled
by state tables. And here is the rule
in a nut-shell:

 Your data becomes the pointer to the
next data.

 This can be done in Basic by using
arrays. Tables and arrays are
conceptually identical. Let me write a
bit of code and see what it does:

  10 a(0)=4
  20 a(4)=1
  30 a(1)=22
  40 a(22)=5
  50 a(5)=0

  60 i=0:        rem set pointer
  70 ?chr$(64+a(i));: rem print char.
  80 i=a(i): make data become pointer
  90 if i>0 then 70 :if not 0, loop
 100 print

 I have organized the array as a state
table. If the state is 0, then the
data is 4, which produces a printed
"D" in line 70.

 In line 80, the data becomes the
pointer, in the first case, 4. Loop to
70, and an "A" is printed.

 I hope you get the idea. Combine
state table thinking with a random
number and a bunch of sprites, and you
can create "randomation". A sprite of
a little guy faces forward. From that
state, he can do one of three things:

 1) Turn Right

 2) Turn Left

 3) Not Change.

 Use a random of 1 - 3 to choose. Then
from each other option, devise three
possibilities. For example, from Face
Left, you can

 1) Turn Front

 2) Not Change

 3) Not Change.

 Someone once told me, when I had a
TRS-80 Model I, that "your imagination
is your only limitation." I have since
hedged on this blanket statement. The
TRS-80 did not have color, sound, or
even lower case characters.

 But these are only hardware
limitations. Imagination can reach
far beyond such minor considerations!

 DMM