[Coco] Using DriveWire to write network software

[Mark D. Overholser]

On 26-Mar-17 11:11, David Ladd wrote:
> Thinking about it over night.  Since the CoCo's normal game play is based
> on the 0 to 63 that would give us 6 bits for the analog.  2 buttons would
> be two bits.  So basically could have 2 bytes right there.  Could send one
> of the joystick buttons bits with one of the analog 6 bits and then use the
> last bit to tell which analog stick/button byte we are dealing with.
>
> What do you think?
>
> +-----------------------------------------------------------------------+
> | David Ladd a.k.a. PacoOtaktay a.k.a. Drencor                          |
> | YouTube: http://www.youtube.com/user/PacoOtaktay                      |
> | YouTube Gaming Live: https://gaming.youtube.com/user/PacoOtaktay/live |
> | Websites: http://dwladd.com     &     http://www.theterrorzone.com    |
> | G+:  https://plus.google.com/113262444659438038657                    |
> | G+:  https://plus.google.com/+DavidLaddPacoOtaktay                    |
> |                                                                       |
> | Do you have your CoCo 3 yet?                                          |
> +-----------------------------------------------------------------------+


With 6 Bit for Analog Position and Two Switches, it sounds like this 
could be accomplished with 8 Bit, or 1 Byte..

But more data than just the JoyStick position needs to be exchanged.. 
It is a given that whatever Data is sent from One machine will most 
likely need to be used by the other machine..


For Simplicity, lets imagine a Two Player Pong Game...

Player One on the Left, Player Two on the Right..

Each Player on their Own CoCo, maybe in the same room, or maybe One in 
Australia and the Other in Denmark..

Each Game, on each Computer must start with the exact same "State"..
The Ball Must start in the Same Position, the Paddles must be in the 
Same Positions.
If the Game Code on each Machine Is Identical and makes identical 
calculations on the Ball Velocity and Angle, each Machine could "keep 
track" of the Ball's State, Independently, but more than likely, there 
eventual would be some sort of Rounding Error, and the Two Machines 
would have a Different "Ball State"..  This means that beside the Paddle 
State of each Machine, the Ball State must be shared too, ( as well as 
the Score and whose turn it is to serve )

It would make sense that the Machine that is Serving the Ball, be in 
charge of the Ball State, until the Machine that is Hosting the 
Opponents Paddle has Struck the Ball, at which Point it becomes in 
charge of the Ball State, until being Struck by the Server, at which 
point that Machine takes over the Ball State..

So if Player One is Serving, Player One's Machine needs to send to 
Player Two's Machine, Player One's Paddle and Switch State ( Its 
Position ) and the State of the Ball, ( Its Position ) and will do 
continually, until Player Two has Struck the Ball, at which Point Player 
One's Machine will Only send Paddle State Data, and start Receiving from 
Player Two's Machine, Player Two's Paddle and Switch State ( Its 
Position ) and the State of the Ball, ( Its Position ) and will do 
continually, until Player One has Struck the Ball, at which Point we go 
Back to the Top of this Paragraph, and Continue until one of the Players 
misses the Ball...

With just the Delta of the JoyStick Data ( 6 bits plus 2 bits ), if 
there was ever any loss, the State of the Two machines might get out of 
Sync.  So a periodic Re-Sync might need to be performed..  Since the 
Ball State will need to be something like X,Y coordinates, every so 
often, Paddle One and Paddle Two could send their X,Y Coordinates too...

As well as The Score, The Server, possibly the Number of Balls Left and 
any "snide remarks" the players might be Throwing at Each other..


I have spent a little bit of time thinking about this kind of "stuff"...


MarkO