LoginLogin
Nintendo shutting down 3DS + Wii U online services, see our post

Trying to make a Pictochat like program, but I'm stumped.

Root / Programming Questions / [.]

mystman12Created:
So I thought making a Pictochat kind of program would be pretty simple to make, and I dived right in, but then I realized that the only kind of data you can send through local wireless is strings. I just can't seem to figure out a good, fast way to transfer the image data. You can check out the program so far: 4KSKYDAS What I have so far is a system where, when you tap send (The upper right corner of the bottom scree, this is where SEND would be), it converts the image into an array, tries to send the array through strings, and then uses the array to recreate the image on the upper screen. (You can see this last behavior in action if you notate lines 57 and 58) I've got it so you can connect two or more systems together, and the receiving system will print the incoming data, but after a few moments it crashes with an error because it tried sending to much information too fast. I mean, maybe I could get it to work, but I want it to work fast, and I'm not sure how to do that. I'm probably not going to mess with it any time soon, since there are other projects I'd much rather work on, but feel free to mess around with it, or even finish it if you like. (Although finishing it would probably basically be restarting from scratch. :P)

I am working on a system to transfer large amounts of data between two consoles, too. I have a simple protocol. The sender sends a signal with MPSET whenever it has new data it wants the receiver to see, and the receiver sends a signal with MPSET whenever it has finished receiving that piece and wants the sender to send more. They each see the others' signal using MPGET, which never causes a buffer overflow. Details, chronologically: For sender and receiver, I set MPSET 0,0 before MPSTART. The sender does MPSEND, then MPSET 0,1. The receiver is watching MPGET(sender,0) until it changes. Once the receiver sees this change, it knows it can MPRECV. Then, the receiver does MPSET 0,1. The sender, after sending the first string, is watching MPGET(receiver,0), and when this value changes, the sender knows it can send the next string without causing an overflow at the receiver. It does MPSEND, then MPSET 0,0. The receiver is waiting for MPGET(sender,0) to change back, and so on. Details, by system: Sender: MPSET 0,0, MPSTART, MPSEND, MPSET 0,(something different from the last value it had), wait for MPGET(receiver,0) to change, then MPSEND again, etc. Receiver: MPSET 0,0, MPSTART, wait for MPGET(sender,0) to change, MPRECV, MPSET 0,(something different from the last value it had), then wait on MPGET again, etc. In my implementation, I flip the MPSET value between 0 and 1 while there is still more data to transmit, and MPSET 0,2 for the very last piece of data. EDIT: In my tests, I can send four strings for each iteration of this protocol, and each iteration is typically 6 frames. I'm getting throughput of 9900bytes/second. EDIT 2:I just ran a test for 10 minutes; no errors, approx 6GB transferred. It seems quite stable.

@SquareFingers This is very nice! It's like frame sequencing with a 1 bit sequence number. When your implementation is set, would you mind making a resource page about it? It'd be great to have; you can categorize it as a tutorial.

Don't believe what I wrote earlier; it was not a good test and I was unaware at the time of bugs in SmileBasic such as http://smilebasicsource.com/forum?ftid=171