Repurposing petit modem, somehow make a game server?
#1✎ 173CoinzReturnsAlright guys.. this is really complicated of an idea.
First, We have this utility called petit modem and it CAN receive files
through a primitive sound stream similiar to dial up modems back in the early days of the internet.
What if there was a way to implement the soundstream listener from petit modem into smilebasic, then send the same sound stream from one universal server to all clients through a skype call, and while this is happening, all the clients send a sync sound packet every so often (an ACK), which helps keep everything in sync.
The 3ds would have to be sending ACk packets simultaneously while it receives.
This method seems possible..
So basically one person would be running the game on their 3ds.
It would be plugged into a dual mic plug, and sending a sound stream through a skype call.
The sound stream would then be picked up by others in the call, and they would have their 3ds's hooked up to their pc's through similiar jacks.
Seeing as all 3ds's would be running the same software the dropped packet policy would need to be tight.
If it's reliable or if we could get it to a reliable point we may be able to create our own "virtualized" multiplayer games inside SB which allow connectivity.
If not for constant connectivity then for something cool like the mystery gift feature in pokemon or for a feature similiar to the GTS in pokemon.
Something neat like that but probably a lot simpler.
If the data could check out (I know nothing about signal processing)
Then we could actually use it for OTHER game features and extend SB's capabilities ALOT.
(interesting idea would be to have a program send web packets to SB and then have it interprete those, and send back relevent packets. basically enabling SB to work on higher level platforms or within them as a client )
Alot seems possible when you add in a soundstream.. of course you'd have to have a special audio out or just have a computer reserved with a cord that you can't hear or it could get pretty annoying.
Alternatively... IF YOU HAVE two 3ds's
You could run one 3ds as a client/server to a laptop which gets it's data from the web in real time , and then uses the multiplayer library to send THAT data to another 3ds, which it's connected to through the actual multiplayer feature in SB.
I sure wish I had more than one 3ds so I could set something up like this and test it.
#2✎ 129jamieyelloFirst DayJoined on the very first day of SmileBASIC SourceWebsiteNight PersonI like the quiet night and sleep late.Express YourselfDrawingI like to draw!HobbiesYeah it'd be possible. The question is do you know how to work with a programming language that can handle all the data?
That's the only thing limiting you.
#3✎ 129jamieyelloFirst DayJoined on the very first day of SmileBASIC SourceWebsiteNight PersonI like the quiet night and sleep late.Express YourselfDrawingI like to draw!HobbiesHey here's a crazy idea, what if you just had one cable connecting directly to one 3ds to the other and flip the mic/audio so it's just a direct data connection?
Oh wait that's just 3ds wireless without the wireless nevermind
#4✎ 940Y_ackI've discussed this before and it might have some potential if PC-SB sync could be worked out. Your implementation has some problems though.
Mostly, Petitmodem isn't the only modem software we can use here. Better would be to write an original one. Second that you actually suggested Skype. The goal is to not lose the little information we can send quickly, not mangle it completely.
Probably more feasible is a js/web implementation. SB->JSClient->Other Client->Message Buffer->SB when ready to handle incoming.
#5✎ 61ninjagnuC would be pretty low level for a project like this. Though if speed is a concern it would probably be a good candidate.
C would be pretty low level for a project like this. Though if speed is a concern it would probably be a good candidate.
I am aiming for 56k, but that of course would only work with a cable.
I'm glad that I was able to figure out analog output through the audio jack, since that is what enables me to do the analog transfer, rather than FSK. Theoretically I could even get slightly higher than 56k!
I'm not sure how cross platform C would be either. Depending on the type of OS your code would be running on direct access to the audio input device would be harder or easier.