On Fri, 11 Apr 1997, Glenn Saunders wrote:
> A distribution amp for joystick signals, essentially. Good idea.
Thanks. If synchronization is really not a problem after the initial
sync-ing of vblanks, then this could work, and be easier than my first
proposition using the CPU to do the networking.
> No, I think the double button press sync idea is a good one, and should
> result in solid sync. I mean, both units will be running at the same
> exact clock speed so they shouldn't fall out of sync.
Sure, I realize the clock speeds are the same, I was wondering more about
code length -- what if player #1 is in a situation where (for example)
only 100 instructions need to be executed before he's back to vblank,
while player #2 is in a situation that requires 150? Would everything
still stay in sync, as long as you know the delta is not enough to cause
one console to "skip" a frame?
> One problem, though. The CPU still has to track the status of the 2nd
> player. That means if player 2 (offscreen) dies, it has to know it. But
> the CPU with the player offscreen isn't likely going to calculate player
> missile collisions offscreen, so we get back to the problem of actual data
> communication between machines. You can't simply track basic screen
> location of the offscreen player. You have to know exactly what he's
> doing, and that will steal CPU cycles.
and Matt Pritchard wrote:
> Been considered extensively. Syncronization problems rear
> their ugly head. If both players are in the same room, which sprites
> do you use to draw them? Who collided with what on which frame?
Both of the latter comments are valid, but nothing new, I think. Yes,
both games would have to track both players regardles of whether they're
on screen or not. That "steals" CPU cycles whether you're talking about
Combat or Warlords or some new, 2-console game.
As for which sprites to use, again, it's just like every other game.
Sprites are already shared, whether by alternating frames, re-use during
the same scanline, etc. Pitfall already has to know when the player has
picked up treasures or not, such that if they return to the screen later,
the treasure is gone, so off-screen data is definitely tracked in many
games.
The hardest part I see in all this is making a game that tracks
_everything_ all the time (and maybe this is what Glenn meant). Pitfall,
for example, would have to do twice the work in game logic (display logic
would be mostly unchanged) to track what each player is doing. And, while
I've always thought a 2-console 2600 Enduro would be cool, I also know
that all those cars are not being "tracked" as they rush towards you --
they're just randomly generated. It would be messy at best to keep track
of every single opponent's car, such that the screen would look the same
for both players. Unless the pseudo-random numbers happen to all work out
the same, after the sync at vblank.
But there would be simpler applications -- a football game, where each
player would have their own "play select" screen. Or linked Tetris
(Edtris?), where you only need to transmit data occasionally, to cause a
line to be inserted on your opponent's playfield when you clear one or
more lines. Or a single-screen game, like Dark Caverns, where two players
move around a Ms. Pac-man styled maze, and your opponent is invisible
except when he fires at you or if you get really close to each other. =)
Some of these ideas sound almost fun enough that I want to learn 2600
programming... ;-) but the Lynx is keeping my plenty busy these days, and
I often find myself contemplating the exact same networking ideas and
problems.
Carl Forhan <><
Vindicator Online: http://www.millcomm.com/~forhan/vindicator.html
--
Archives available at http://www.biglist.com/lists/stella/archives/
E-mail UNSUBSCRIBE in the body to stella-request@xxxxxxxxxxx to be removed.
