MaxCoderz

After my long talk with Ben in #TCPA yesterday and some research, I'm now pretty much convinced that the Ti-OS checks for silent transfers in the getkey routine, and not in the im 1 routine. So I updated the bit in the WikiTi about Ti-OS interference that I wrote a very long time ago. I'm slightly surprised that nobody has edited it earlier. I had written "it's unknown if this is checked in the interrupt or in the homescreen input" or something like that, and kinda expected and hoped that someone would correct me on it

Aha! This is good to know.

It is indeed.

I uploaded a new zip on the CLAP website, with the networking routines included. Still without timeouts though, and obviously not finished yet. The read routine isn't very practical in a non-server-client-based situation (or without a known number of clients), but remember that it's supposed to become an interrupt routine.

I also uploaded the Bouncy source (which is now compile time scalable, you can define any number of calculators in the source between 1 and... I don't know, 254 probably ), new binaries and a video showing the bouncy demo running on my three linked calculators.

You can find the networking routines in the asm library under "Software" > "CLAP library" and the Bouncy stuff under "Software" > "Example software".

And don't forget Kerm, no peeking at my networking routines

Enjoy

To get us a bit more in the direction of easy multiplayer game programming, I wrote another little example. It took me about half an hour to make this, using the CLAP library and the API (two player only):



Full source here:
http://timendus.student.utwente.nl/~cla ... s/Move.txt
(Will look better if you open it in Latenite)

A funny thing is that this demo doesn't synchronize or set up a connection. I intended to do that, but I skipped the synchronization so I could test one calc stand alone, and forgot to put it back in. Then I finished the program, tested it, saw that everything worked properly, and didn't realize that it wasn't synchronizing untill I was about to post it here

Anyway, this makes the code shorter and easier, and it works just as well (slightly to my surprise), so whatever


---
Edit: For the interested reader; this synchronizes as follows: The main game loop first tries to swap a byte with the other calc before it shows the sprites. The swapping is done by first sending a few bytes, then waiting for a few bytes. So the first calc runs the program, displays the waiting message, gets to the main program loop, which tries to swap. It sends out it's coordinates, which the other calc ignores because it's not running the program (the Ti-OS doesn't mess up because the transfer is too fast to trigger the silent link shit, and even if it gets triggered it doesn't generate a proper clock signal so the other calc will just ignore it). Then it starts waiting for the other calc to send it's coordinates.

When the second calc enters the program, it does the same thing; it gets to the main loop, sends out it's coordinates, and starts to wait for the coordinates of the other. The first calc picks this up, displays the sprites, and loops again, so it sends out it's coords again, which the second calc picks up, so that calc also displays the sprites. From then on, they keep each other's program from deadlocking by unlocking each other in turn.

This is probably not the fastest way to do this, because both calcs are just waiting to be unlocked half the time. Properly synchronizing would have been faster, but it's late and I'm lazy, so I'll leave you to figure that out on your own, or wait untill I either write another demo or write a library with an interrupt routine so you don't have to wait at all

Timendus wrote:...and a video showing the bouncy demo running on my three linked calculators....

I see four PTI calcs, not three HW calcs...

Timendus wrote:And don't forget Kerm, no peeking at my networking routines

Don't worry, I won't, I want to see what I can come up with on my own.

Very good work, have you tested it with moving on each calc? Like moving at the same time. Have you tested this on other models yet?

kerm_martian wrote:

Timendus wrote:...and a video showing the bouncy demo running on my three linked calculators....

I see four PTI calcs, not three HW calcs...

Under the four PTI calcs:

"Networking on the hardware:
(Download if the plugin doesn't work for you)"

I guess the plugin doesn't work for you and you missed those lines?

kalan_vod wrote:have you tested it with moving on each calc? Like moving at the same time.

Not yet, I can't press the buttons at the same time in PTI But I'll send it to my hardware to see how it works.

Have you tested this on other models yet?

Yup; Ti-83 and Ti-83+ are cross compatible, I can't test with anything else.

Featured
I had to remove 'calc' from your original title to fit [Featured] in, you might want to adjust it.

Cool, thanks!

Definitely deserves this feature!

@Timendus: Ok, I understand that. I just want to see if it could be used in real time multiple player games using basic

Ah, Basic multiplayer games... that's another story It should be possible with the tool I made, but I think I should leave that to the Basic gurus here, because I'm no good with Basic

(Not anymore at least, I haven't really coded in Basic for years )

Tsk tsk. Just to make sure, you don't particularly mind if I try to code a set of competing routines on my own, right?

Timendus wrote:Ah, Basic multiplayer games... that's another story It should be possible with the tool I made, but I think I should leave that to the Basic gurus here, because I'm no good with Basic

(Not anymore at least, I haven't really coded in Basic for years )

Once this is finished would it be ok to add it to xLIB (with tr1p1eas permission), due to the nature of TI-Basic it would be to slow to use Asm() on a "real time" game. But with the hook it would quite speedy!

Hopefully it doesn't make xlib too big. I don't think so though.

Liazon wrote:Hopefully it doesn't make xlib too big. I don't think so though.

Tr1p1ea wont make a two page app, just keep it one page which remains the same size.