#22544 - sgeos - Thu Jun 24, 2004 12:56 am
Does anybody know if the the DS will be able to link to GBA units via the standard GBA link cable?
-Brendan
#22545 - PhoenixSoft - Thu Jun 24, 2004 12:57 am
As far as I know, the DS has no GBA link port on it so only wireless-enabled games can be used with it.
#22546 - sgeos - Thu Jun 24, 2004 1:00 am
In that case, perhaps it's a good thing that I spent my time learning things other than details of GBA SIO. =P
-Brendan
#22550 - ampz - Thu Jun 24, 2004 1:36 am
GBA UART mode is straight forward and similar to any standard UART.
#22552 - tepples - Thu Jun 24, 2004 1:38 am
Last time I checked, GBA UART mode can't multiboot the clients in a single-pak situation. And can GBA UART mode be used with more than one GBA?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#22580 - ampz - Thu Jun 24, 2004 4:30 pm
| tepples wrote: |
| Last time I checked, GBA UART mode can't multiboot the clients in a single-pak situation. And can GBA UART mode be used with more than one GBA? |
Yes, it can be used with two GBAs ;-)
#22602 - sgeos - Fri Jun 25, 2004 2:32 am
Is it feasible to do a SIO Multiplayer transfer once a frame?
-Brendan
#22628 - Miked0801 - Fri Jun 25, 2004 7:10 pm
Yes. You can do this if you have really tight game code. Keep in mind that the transfer code will take a signifigant portion of your CPU time. We went every other frame to make it a bit easier.
#22631 - sgeos - Fri Jun 25, 2004 7:42 pm
| Miked0801 wrote: |
| You can do this if you have really tight game code. Keep in mind that the transfer code will take a signifigant portion of your CPU time. |
What percentage are we looking at?
| Miked0801 wrote: |
| We went every other frame to make it a bit easier. |
What is the best way to sync a game to 30 FPS?
-Brendan
#22635 - Miked0801 - Fri Jun 25, 2004 9:27 pm
Check out the SGade stuff. It has sutff built in for doing copying at about any rate you want. It's the best resource out there for Multi SIO code. As to percentage - I'd guess roughly 5-15% overhead depending on how big your packets are and if transfering to 2 or more players. Keep in mind that this stuff is very error prone and resends are somewhat common so you need to checksum/error check each packet or watch things go out of sync in a hurry.
#22646 - ampz - Sat Jun 26, 2004 3:26 am
| Miked0801 wrote: |
| You can do this if you have really tight game code. Keep in mind that the transfer code will take a signifigant portion of your CPU time. |
Use interrupts and no polling, should not consume much CPU time. DMA would be even better, but I guess the GBA do not support it.
#22652 - Miked0801 - Sat Jun 26, 2004 5:33 am
This is assuming interrupts and no polling. It takes a lot of time to send data across the link and verify it...
#22674 - ampz - Sat Jun 26, 2004 6:52 pm
Well, yes, it takes time (real time) to send data due to the modest bandwidth, but not CPU time.
Of course, CRC allways takes its toll.
#22693 - Miked0801 - Sun Jun 27, 2004 6:09 am
A normal packet 12 bytes
1 send for all is ready
6 16-bit sends
1+ for slave(s) got ok
1 for master tell slaves to go to next loop
1+ resend till master is sure slaves are on next loop
So about a minimum of 10 (realistically, syncing eats a ton more) interrupts to get this to occur.
Each interrupt has both crt0.s and bios cycles to go through (for us, this is roughly 150 cycles in and 100 out)
Each call has to go through all the state check code and get to the point where it wants to send. I'll guess an average of 100 cycles.
So best case is (100+100)x10 cycles or 2,000. You get roughly 280,000 cycles in a 1/60th sync period. So cycle overhead isn't killing too bad.
But, you can't call the SIO interrupt too often or the hardware won't recognize it and it will return an error state (bit 6 or 7 depending on timing). I'd guess (no stats in front of me) that you could call the SIO roughly 15 times in a 1/60th period without too many hardware errors. That means that you'd better have your data ready to send in 1/3 of 1/60 of a second. Even with input buffering and playing with 1 tic of lag (what I do) it's very difficult to keep the game at 60Hz - and because of the induced lag, it will feel like a 30Hz game anyways.
BTW, if you miss a packet or get corruption (which happens quite often), you have to wait for the check to occur on the final send and then resend the whole packet (at at least 10 sends) which guarentees you will drop a frame if running at 60Hz and also means that 30Hz games get a bit tight.
This is what I mean about 60Hz having to run really tight to pull it off. Other people with experience, I'll gladly take your opinion as well. Also since I am not at work, my 15 times a tick number might be a touch off - though not too much (perhaps as high as 20 but not much more)
Mike
#22694 - sgeos - Sun Jun 27, 2004 6:23 am
After the initial setup, would it be too dangerous to try to keep the games synced only sending KEYINPUT, the frame number and parity bits (to up to four GBAs)? Obviously "All OK" sends would be needed.
I'm looking at a scheme consisting of 10 bits for the buttons, 3 bits parity, 2 bits frame counter, and one control bit.
-Brendan
#22697 - tepples - Sun Jun 27, 2004 7:10 am
If you just use KEYINPUT reflection, then after 20 minutes, all machines may fall out of sync because their crystals will have got out of sync. It's best to use at least some universe reflection every once in a while, even if not all at once.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#22728 - Miked0801 - Mon Jun 28, 2004 5:09 am
Actually, we never need to do this. We just don't assume that a packet is sent because the master send it (hence the ending sequence I mentioned earlier). Universe reflection is just too expensive. Key-button presses with an initial random seed and minimal starting state vars are enough.
#22729 - sgeos - Mon Jun 28, 2004 5:17 am
| tepples wrote: |
| If you just use KEYINPUT reflection, then after 20 minutes, all machines may fall out of sync because their crystals will have got out of sync. It's best to use at least some universe reflection every once in a while, even if not all at once. |
That is what the 2 bit frame counter is for. If it does not match for all units, then the units that are ahead a frame go into stall state and do not update the universe (and frame counter) until the frame counters match again.
What are the chances of a unit becoming more than one frame out of sync assuming (near) identical initial setups?
-Brendan
#22733 - tepples - Mon Jun 28, 2004 7:15 am
| sgeos wrote: |
| What are the chances of a unit becoming more than one frame out of sync assuming (near) identical initial setups? |
What are the chances of bit errors?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#22752 - Miked0801 - Mon Jun 28, 2004 7:20 pm
Lol :)
Pretty low, but it will happen. Thus, you need a strong checksumming system (or CRC, but input interchanging isn't likely so checksum does about as well and is faster.)
What Tepples is saying is that you can't just set 2 (or more) systems syncing with their interal timers and assume they will stay in sync. You need a more robust solution (like what you and I are talking about.) BTW, is this just a curiousity, or do you have the means to debug this sort of thing? You need no$gba at the least and hardware debuggers are better do to the complexity of multiplayer code. Also, you need to be really, really careful in your game code making sure that you aren't doing something that is hardware specific and will thus throw you out of sync (likme using an internal timer as a random number seed or reading off the end of an array on accident.)
#22771 - sgeos - Tue Jun 29, 2004 5:51 am
| tepples wrote: |
| What are the chances of bit errors? |
100%, given enough time.
| Miked0801 wrote: |
| Pretty low, but it will happen. |
At this point I think a better question is how long will it take for at least one of four GBAs to drop one frame out of sync? How long will it take for at least a unit to fall two frames out of sync all at once?
| Miked0801 wrote: |
| What Tepples is saying is that you can't just set 2 (or more) systems syncing with their interal timers and assume they will stay in sync. You need a more robust solution (like what you and I are talking about.) |
Right. I'm trying to determine what kind of assumptions the robust solution can operate on. If I know that two systems will never fall more than one frame out of sync at a time, then I can give the lagging system(s) a chance to catch up. If a bit error happens about every second (found by parity), and two bit errors in one block happen about every fifteen minutes (not found by parity), I'd take two bit errors fairly seriously depending on the type of information being exchanged.
Do you have any idea how many bits are in error? (Expressed in terms of a fraction.) This could easily be calculated by seeding an RNG (probably a LCG) on both ends and comparing the data as it hits the remote system.
If one GBA receives erroneous data, that may not be the case for the other units, correct?
| Miked0801 wrote: |
| BTW, is this just a curiousity, or... |
It's more a question of how difficult integrating multiplayer capabilities into a game are. If I can read KEYINPUT for four GBA units in a more or less reliable fashion, then adding multiplayer support certain types of multi-player games will be easy.
| Miked0801 wrote: |
| ...or do you have the means to debug this sort of thing? You need no$gba at the least and hardware debuggers are better do to the complexity of multiplayer code. |
I only have one GBA at the moment. If I really need to implement multiplayer on my own I'd pick up a second unit (and/or petition friends to get GBAs =) How painful would it be to hash out multiplayer issues using only hardware?
| Quote: |
| Also, you need to be really, really careful in your game code making sure that you aren't doing something that is hardware specific and will thus throw you out of sync (likme using an internal timer as a random number seed or reading off the end of an array on accident.) |
For a single player game, I think that adding the results of a LCG with a timer would be a fantastic way of getting random numbers. Having remote units that have to stay in tune with one another changes things. (The master unit may want to generate the initial seed using some hardware specific method.)
It seems to me that all units would want to (try to) keep and operate on identical models of the game universe and only differ in how those models are displayed. (This is why all units need to be able to read eachother's KEYINPUT.) The different views (one per GBA) of the game universe alone will be enough to mess up parallel timing.
-Brendan
#22774 - Zero - Tue Jun 29, 2004 7:03 am
holy post of hugeness!
#22777 - sgeos - Tue Jun 29, 2004 8:11 am
| Zero wrote: |
| holy post of hugeness! |
Bah! =)
#22814 - dagamer34 - Tue Jun 29, 2004 10:17 pm
| sgeos wrote: |
| Miked0801 wrote: | | ...or do you have the means to debug this sort of thing? You need no$gba at the least and hardware debuggers are better do to the complexity of multiplayer code. |
I only have one GBA at the moment. If I really need to implement multiplayer on my own I'd pick up a second unit (and/or petition friends to get GBAs =) How painful would it be to hash out multiplayer issues using only hardware?
|
Like finding a needle in a haystack the size of Texas. It's really difficult. I eventually just gave up that part to focus on other things. If only I had no$GBA...
_________________
Little kids and Playstation 2's don't mix. :(
Last edited by dagamer34 on Wed Jun 30, 2004 1:03 am; edited 1 time in total
#22825 - Miked0801 - Wed Jun 30, 2004 12:09 am
Lol - Sounds like you entered the "I hate GBA mulitplayer" club as well. A select few of us who have ripped out much hair to try to get it at all working. Yes, you can get it working. We spent about 6 man months to get the base engine there. Then more per project to make sure that game code is behaving in a multiplayer safe manner. I'm sorry, but GBA multiplayer just isn't something that I feel is a GBA hobbiest thing to get working. Someone else, please prove me wrong and get a STABLE (as in a game that stays in sync for weeks, not hours or minutes) game connection with the standard cable.
#22832 - dagamer34 - Wed Jun 30, 2004 1:09 am
| Miked0801 wrote: |
| Lol - Sounds like you entered the "I hate GBA mulitplayer" club as well. A select few of us who have ripped out much hair to try to get it at all working. Yes, you can get it working. We spent about 6 man months to get the base engine there. Then more per project to make sure that game code is behaving in a multiplayer safe manner. I'm sorry, but GBA multiplayer just isn't something that I feel is a GBA hobbiest thing to get working. Someone else, please prove me wrong and get a STABLE (as in a game that stays in sync for weeks, not hours or minutes) game connection with the standard cable. |
I STRONGLY doubt it. With no emulator to see what is happening, it's all guess work. I'm surprised I got the SGADE code working in the first place.
_________________
Little kids and Playstation 2's don't mix. :(
#22871 - ampz - Wed Jun 30, 2004 6:06 pm
The standard cable cannot do UART comms?
#22888 - Miked0801 - Wed Jun 30, 2004 8:25 pm
Correct - at least that is what I've been told. Someone else want to confirm that? Even if it does work, it won't support 4 player which is what Nintendo wants...
#22895 - ampz - Wed Jun 30, 2004 9:55 pm
Well, not all of us care about what Nintendo want :)
I just checked the cable schematics. A GBC cable should work fine with GBA UART comms.
#22930 - sgeos - Thu Jul 01, 2004 2:23 pm
Nintendo want 4 player games to be made? It sounds plausible. Have they been telling this to developers? (As opposed to 2 or 3 player games.)
-Brendan
#22947 - Miked0801 - Thu Jul 01, 2004 7:09 pm
Can't really answer that one without sticking a foot in my mouth. I will say that having a good 4 player engine in place has been nice marketing tool.