I was just thinking about how I could accomplish this (through CalcNET 2.2 of course.) What I was thinking was that I could only send/recieve the X and Y coordinates of each person's cursor two bits: Clicked and On/Off (color). I'll start working on it when I get home if I have enough motivation. Also, general questions about CalcNET and what I can do with it will go here later. Suggestions / questions welcomed.
I think this is a great idea; I'm glad that we both came up with the idea of updates independently. Another idea I had is that it might be even more optimal to send 16x16 chunks that can just be ANDed to the screen, since a player/user is likely to be drawing in one place at a time. I have a bunch of standard code for calculator coordination and enumeration from NetPong that I'd be happy to clean up and contribute to you, so that all you'd need to do is build the actual interface plus the marshalling/unmarshalling code.
I'm afraid I don't quite get what you were saying about the 16x16 chunks :/ I'll ask some friends at school about it and if they understand it. (or if I get it by tonight). One idea I thought would be cool is to be able to have greyscale. Although, that requires I chain with the CalcNET 2.2 interrupt (whether that's possible or not, no idea)
_player1537 wrote:
I'm afraid I don't quite get what you were saying about the 16x16 chunks :/ I'll ask some friends at school about it and if they understand it. (or if I get it by tonight). One idea I thought would be cool is to be able to have greyscale. Although, that requires I chain with the CalcNET 2.2 interrupt (whether that's possible or not, no idea)
Instead of passing a list of (X,Y,color) triples, which are three bytes each, you could send every half-second or so one or more XOR- or AND-able 16 pixel by 16-pixel chunk along with the (X,Y) location of its top-left pixel, a total of 32+2 = 34 frame bytes for each 16x16-pixel chunk. Pixels changed (erased or drawn) since the last time that area of the screen was shared with the other calculators could all be represented by 1 bits, and pixels changed an even number of times (ie, nothing, drawn and erased, erased and drawn) could be 0 bits, then that 16x16 chunk could just be directly XORed onto the receivers' screens.
Err, necropost >.<
I think I want to pick this back up, but I am being a little bit less strict on how I want to do it. No pixel drawing yet, I'll save that for a day when .. no idea. Anyways, the idea this time is just to get a pixel moving around the screen, one for each person. I might eventually add something where you can have names and such, but that won't be for a while. Below are the design specs I had in mind:
Code:
I think I will be using the code from here to send it to each calculator. I'm not sure yet if I want to do a server<->client model or if I want to make each calculator handle talking to all the other calculators. If I do that, everything will work like the server, and it will send packets to every other calculator using the above routine. Ideas?
I think I want to pick this back up, but I am being a little bit less strict on how I want to do it. No pixel drawing yet, I'll save that for a day when .. no idea. Anyways, the idea this time is just to get a pixel moving around the screen, one for each person. I might eventually add something where you can have names and such, but that won't be for a while. Below are the design specs I had in mind:
Code:
ID_ARRAY: | Array Size{1 byte} | ID{5 bytes} | X{1 byte} | Y{1 byte} |
SERVER: The server will keep track of every calculator's ID and position, the server will send out a broadcast packet with the data formatted like: | Array Size{1 byte} | X{1 byte} | Y{1 byte} | etc. The server will receive packets that look like: | X{1 byte} | Y{1 byte} | and it will receive the calc's ID as well through Cn2_Int_RecvBuf+0. It will then search through it's <<ID_ARRAY>> until it finds a match. If it doesn't find a match it will add another element to the array and increase Array Size by 1.
CLIENT: The client keeps track of who is the server, and will send data only to that server calculator. When it gets a broadcast packet, it will download it, save it to it's array, and go on with it's task. It will draw the array onto the screen by checking the size, looping through the size * 2 bytes in the array and displaying a dot at each (X,Y) location.
I would prefer a decentralized format, personally, although it might be harder for something like this. I was going to quote something like Chat, where everyone is a peer, and simply discovers the others' presence eventually thanks to the power of broadcasts. However, Chat can tolerate some lack of sync when the calculators are finding each other, in other words, if they miss a line or two of text, no biggie. A paint program would be less robust against this, so perhaps a server (which would have to be simultaneously useable as a regular painting calculator) would be a good idea.
KermMartian wrote:
I would prefer a decentralized format, personally, although it might be harder for something like this. I was going to quote something like Chat, where everyone is a peer, and simply discovers the others' presence eventually thanks to the power of broadcasts. However, Chat can tolerate some lack of sync when the calculators are finding each other, in other words, if they miss a line or two of text, no biggie. A paint program would be less robust against this, so perhaps a server (which would have to be simultaneously useable as a regular painting calculator) would be a good idea.
Oh yes, of course
The displaying would be the only difficult part imo. I'd have to rewrite it for that one server calculator, and also have to find a way to tell the other calculators "Hey! I'm a server". If someone else agrees with the having a server idea, or if no one else posts, I'll use it
I think the best things would be to have each calculator first listen for a second or so, then send a few "HELLO? HELLO?" broadcasts. If nothing, it then calls itself the server, and starts sending broadcasts that it's the server every once in a while. If it gets any "HELLO? HELLO?"s, it should respond with a directed "I am the server" message.
0rac343 wrote:
Is this still in progress?
I absolutely hope so! This would / will / must be an awesome CALCnet project!
As soon as the CALCnet protocol starts making sense to me, I can start on it <.< For whatever reason, I seem to be having the same block about CALCnet as I had with ASM. But I eventually was able to understand ASM, and it just "clicked." Hopefully the same will happen with CALCnet, too, and soon.
CALCnet should be even easier to learn than ASM, since it works by referencing memory locations and doing nothing special. One thing you could do to simulate a decentralized format is to make sure that someone else becomes the server the moment the server disconnects, either by the server sending an "I'm leaving" message or other calcs assuming the role as soon as he quits.
hehe, perhaps we can also implement the etch-a-sktch device Kerm worked on with happybob 
just an idea
just an idea
Compynerd255 wrote:
CALCnet should be even easier to learn than ASM, since it works by referencing memory locations and doing nothing special. One thing you could do to simulate a decentralized format is to make sure that someone else becomes the server the moment the server disconnects, either by the server sending an "I'm leaving" message or other calcs assuming the role as soon as he quits.
Welcome to Cemetech, Compynerd! Its great to have you with us. That could definitely work; good thinking. By the way, Compynerd, might I recommend that you Introduce Yourself? Register to Join the Conversation
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Advertisement