gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Coding > what exactly does "dropping a frame" mean - multip

#15446 - johnny_north - Thu Jan 22, 2004 9:17 pm

I'm trying to work out some kinks in multiplayer code and was doing some googling on the subject of syncing problems with multiplayer gba. I was hoping someone could narrow down my experiments a bit with an answer.

I was already under the impression that two or more connected gbas must be syncing up so that they all are hitting the vblank (for instance) at the same time. I'm experiencing occasional bad transfers and corrupt data.

Could someone share with me what to expect as far as timing issues (problems) are concerned? I believe that the vblank on one of my connected gbas is getting cut short occasionally to deal with timing issues. Is this what is meant by "dropping a frame"?I suppose if this is the case, I might expect at some point to loose a whole vblank-? and have to prepare for this as well.

#15474 - Miked0801 - Thu Jan 22, 2004 11:16 pm

You can NEVER assume that 2 GBAs will run at the exact same frequency. You must have code in place to detect when both hit the end of a gameloop, transfer, then run next loop.

Interrupts will never occur at the same instance on both systems due to minor differences in hardware, temperature, phases of the moon, etc. This is a fundemental rule of any multiplayer coding.

#15530 - dagamer34 - Sat Jan 24, 2004 2:36 am

Doesn't the SGADE use timers to sync the data transfer? I think the slave GBA's use the master GBA to signal when data is sent or received (or that's what I think).

Otherwise, I have no clue. I'm actually worse off than you, only because I have one GBA available at any one time. (borrowing...)
_________________
Little kids and Playstation 2's don't mix. :(

#15684 - ScottLininger - Tue Jan 27, 2004 10:22 pm

One solution to the whole multiplayer synching problem is to have the gameboys append every byte of information they are attempting to send with a sequence number, and to keep sending that byte until ALL of the other gameboys sent back that they got it.

In other words, the first 8 bits of the IODATA register are reserved for a sequence number (i.e. "Packet #8") and the last 8 bits contain a byte of data. If it's gameboy A's turn to send its eighth byte of data, it would continue to do so until the exact contents of what it sent are echoed back by everyone else.

Otherwise, it gets very hard to know whether your data got through. I've used this approach with success so far, but it's relatively slow. If anyone can help me with optimization, I'd be greatful.

http://www.thingker.com/gba/MultiplayerV1.zip

#15704 - Miked0801 - Wed Jan 28, 2004 5:04 am

Even with a sequence number, it still possible to get GBAs out of sync as when the number rolls around to FF, a bad send will destroy you (yes, I 've seen this happen quite regularly.)

Combine a packet number with a checksum system (or just a checksum/crc if you want) and send larger packets of data to offset the fact that 1-2 bytes are book keeping.

Mike