## standard gzipped-tarball distribution.
## the makefile calls dc-tool, which is assumed to be in your path.
## dont forget your dependencies:
##  kos-1.1.5
##  the standard dc toolchain (check the sites,BooB,etc.)
tar xvzf dcfighting-WHATEVERVERSION.tar.gz
cd dcfighting
make

##  File format is elf32-little, start address is 0x8c010000
##  Section .text, lma 0x8c010000, size 79328
##  Section .rodata, lma 0x8c0235e0, size 83240
##  Section .data, lma 0x8c037ba0, size 11628

sh-elf-objcopy -O binary dcf_animate.elf dcf_animate.bin

scramble dcf_animate.bin 1ST_READ.BIN

dd if=/dev/zero bs=2352 count=300 of=audio.raw
cdrecord dev=0,0,0 -multi -audio audio.raw

# get the x,y 0,11702
cdrecord dev=0,0,0 -msinfo

mkisofs -l -C 0,11702 -o tmp.iso 1ST_READ.BIN
( cat IP.BIN ; dd if=tmp.iso bs=2048 skip=16 ) > data.raw
cdrecord dev=0,0,0 -multi -xa1 data.raw




if you could tell me anything about usb drivers, character devices, mknod, 
kudzu, /proc/bus/usb/devices, /dev/input/mice, ...talk to me.  id like to have a chat.

v0.1.5: relative rotation(dodging)
        this version introduces the concepts of rotation to the game.  some might call it 
	 a hack at this point:
	  three rotations describe the fighting situation: the global rotation of the center 
	   line(b/w the 2 fighters), and each fighter's individual rotation about his own
	    center.  using this notation, a strafe counter-clockwise(from above) is
	     equivalent to a clockwise rotation of the opponent.  this rotation is reduced
	      instantly to 0.0 upon input from the player; maybe that should me more smooth.
	       the effect is that it is possible to sidestep completely around a player who
	        does not turn to face you.
                 additionally, a float is kept to track the fighting_distance b/w fighters, 
                  and a float[2] to keep track of global displacement, which both players 
		   can modify by strafing(dpad).

	the illusion is pretty good; check it out for yourself.


v0.1.4: fighting state
        refined the notion of fighting state to be more like a power level...
	 denotes stamina when below 100 (a la hit points) and attack power when
	  above 130; in between lie the parry,counter,block,move,stand states.
	   each timestep changes fighting_state by 1 in the direction of their
	    default state, which is set at the anchor time of each move executed.
	     so player will spring back to default.
	      fighting state is also changed by move logic; i.e.attack/block, etc.
^
|
140 throw
130 attack
115 counter
110 block
105 parry
100 standing
95  moving
90  hit
80  stunned
70  staggering
30  falling
20  kneeling
10  down

        also, counters seem to work now, although the timing intervals are going to need
	 much tweaking.  an attack duration of 0.1 timestep units(currently set at 0.02: 
	  possible aliasing) is difficult to match with counter with a 0.15 timestep
           (with the same 0.07 latency as the jab), but possible.  requires more
	    experimentation.

	oh, and no reverses or kicks this time; the logic is being rewritten to an else-if
	 block of form if (  (A) && (X)  ).  so it will check every possibility in 
	  sequence; i thought there might be a way to reduce that.  maybe later.
           besides, it looks like this chip can handle it; and this code could go a long 
	    way toward optimization.
   	     also, switch stance is now A+X.

v0.1.3: touched up interaction
        the logic for interaction has been cleaned up; now all conditionals
	 are compounds (player1==ATTACK && player2==COUNTER).  much easier to read.
	  still needs tweaking for playability; now a stunned player (just hit by
	   an attack) will have no chance to block if the opponent can
	    continuously release a flurry of short jabs(B button).
	     parry and counter should still be possible in a stagger; maybe to
	      a varying degree (you get your ass kicked harder, you have less
	       chance/opportunity to pull off a counter).

v0.1.2: interaction paradigm
        a new block of code has been added after the interpolation loop:
         right now it's a block of if s corresponding to the table below.
          using the table's logic, that loop can add and remove anchors of
	   player1 and player2 according to their states.
	    add_anchor(fighter_t,double,double*,int) now takes a state as well
	     (final parameter) and dcf_animate has a list of #define
	      enumerated possible states.

v0.1.1: fighter structs
        each player==fighter now has his own struct(2 of them currently).
         now we have 2 players in space (thanks a bunch to Dan Potter for the hint).
          there's a loop that goes through the bus and checks each against 
	   MAPLE_FUNC_CONTROLLER.  i was neglecting to call maple_create_addr(p,u) 
	   on the unit,port pairs and hence  getting unusable addresses.

             remember to call :
              c = maple_create_addr( players[0][0] , players[0][1] ); 
               before :
                if (cont_get_cond(c, &cond) < 0) 

only one type of attack and one range now:
if youre within range, the following rules apply.

p1       p2         result
-------------------------------
attack   --         p2 hit;
attack   block      --
attack   counter    p1 hit; 

B button: jab

X button: punches
----------------
X - reverse punch
RightX - hook
DownX - two hand push
LeftX - elbow

Y button: kicks
----------------
Y - short kick
RightY - round house
DownY - knee
LeftY - side kick

A button: defense
----------------
A - block(hold/release)
DownA - counter

A + X Buttons - reverse stance