I looked at the FTDI drivers and the virtual COM port driver seems the easiest way to go. Anyone know about a cross-platform serial port C library? I googled a bit and could not find anything interesting.
-Uze
Uzebox Live
Re: Uzebox Live
I know there's QextSerialPort for Qt. I'm not sure how difficult it is to call c++ libraries from c, but I imagine it's quite doable if no other options are available. It may be possible to bind to a library written in some interpreted language (although I would imagine they typically bind to c for performance).uze6666 wrote:I looked at the FTDI drivers and the virtual COM port driver seems the easiest way to go. Anyone know about a cross-platform serial port C library? I googled a bit and could not find anything interesting.
-Uze
Re: Uzebox Live
Avrdude has a small and nice serial API too. It is just 3 files:
- serial.h
- ser_posix.c
- ser_win32.c
Re: Uzebox Live
Ahh, filipe; the voice of reason.
Re: Uzebox Live
I've only skimmed through this topic a bit, but I could not find the solution I had in mind when I first read the post topic.
I've been playing on and off with the ENC28J60 chip, which is an SPI ethernet chip that handles everything up to the MAC layer and costs around 4 euro (in the Netherlands). In conjunction with uIP (http://www.sics.se/~adam/uip/index.php/Main_Page) and various ATMega's, people have built web servers and small clients for all kinds of purposes. The sources and schematics are out there and not hard to find.
Considering the Uzebox kernel and all handling the atmega644 has to do, I realize we can't hope to put uIP and the ENC28J60 driver into the same chip. We could, however, put it into a small attiny (pick any, it should work) and interface that to the atmega644 via serial or SPI or even parallel. The attiny could handle the TCP/IP stack and perhaps even some specific connection code and expose a much simpler API to the Uzebox via any chosen interface. This could give us a "network adapter" for the Uzebox that won't cost much more than 10 euros total.
Just a thought.
- Fahr
I've been playing on and off with the ENC28J60 chip, which is an SPI ethernet chip that handles everything up to the MAC layer and costs around 4 euro (in the Netherlands). In conjunction with uIP (http://www.sics.se/~adam/uip/index.php/Main_Page) and various ATMega's, people have built web servers and small clients for all kinds of purposes. The sources and schematics are out there and not hard to find.
Considering the Uzebox kernel and all handling the atmega644 has to do, I realize we can't hope to put uIP and the ENC28J60 driver into the same chip. We could, however, put it into a small attiny (pick any, it should work) and interface that to the atmega644 via serial or SPI or even parallel. The attiny could handle the TCP/IP stack and perhaps even some specific connection code and expose a much simpler API to the Uzebox via any chosen interface. This could give us a "network adapter" for the Uzebox that won't cost much more than 10 euros total.
Just a thought.
- Fahr
Re: Uzebox Live
hey Fahr,
There's a bunch of good ideas on how to go about this Uzenet feature. I bet the first one to have something working reliably will win out. I think Tony might be leading the race atm, but you have to keep an eye on Filipe, especially when he's been quiet for a while
There's a bunch of good ideas on how to go about this Uzenet feature. I bet the first one to have something working reliably will win out. I think Tony might be leading the race atm, but you have to keep an eye on Filipe, especially when he's been quiet for a while
Re: Uzebox Live
We'd likely get an influx of new members with this feature. I think we should aim for the very simplest approach if we want it in reasonable time(I like where filipe is going). Uzers are speckled across the globe, many will see > 500ms of latency to anyone else. Hardware is only half the issue, and not too much progress has been made(as far as I know). Imagine playing Zombienator with 1/2 second delay and packet loss. The second battle will be client prediction; at least some compensation method. If it takes a year developing something with huge capabilities, we'd still have no internet games besides Megatris. Realistically, games will end up client-client lock step networking anyway. Just a virtual game pad. No data this vblank? Remote players follows it's last vector until data is available, then resync. John Carmack did not do that much back in the day. First hardware to get 8bits/vblank/player wins my vote.
Re: Uzebox Live
The 500ms latency might be a real issue, but one that can be solved as well using a master server of some sort. Not only would that fix some latency issues by giving everyone access to/from a gigabit line server, it would also make configuration considerably easier, as you only need to code 1 destination into the config and not have users set it.
Providing this shouldn't be much of an issue either. I have some semi-dormant servers just idling away in various clusters I maintain around the globe. Adding Uzenet to any of those should not cause a lot of extra traffic, this is all very low traffic stuff I imagine.
Just an idea, we wouldn't need all kinds of prediction and blanking if there's little to no latency.
- Fahr
Providing this shouldn't be much of an issue either. I have some semi-dormant servers just idling away in various clusters I maintain around the globe. Adding Uzenet to any of those should not cause a lot of extra traffic, this is all very low traffic stuff I imagine.
Just an idea, we wouldn't need all kinds of prediction and blanking if there's little to no latency.
- Fahr
Re: Uzebox Live
@60 packets per second each player would should upstream ~480 bytes(+manual ordering) of UDP overhead or >960 bytes if we used TCP(better choice IMO). And then whatever the payload is, 120 bytes if we send all 16bits for the padstate. I recall some/most operating systems will queue up small payloads like that(for a pretty long delay), so we'd have to send more than 2 bytes. ~1.2k upstream per player sounds about right. If you have that kind of setup available and no one would notice, probably a good solution.
Re: Uzebox Live
I have gigabit servers in various locations in Europe and Canada. And the only one who would notice would be me
But that's beside the point; I doubt we'd need anything of that magnitude. Instead of looking at synchronizing a game between 2 clients, perhaps we should look at making one client the master and the other one the slave, with all the game logic happening on the master and the slave merely sending button presses and receiving status updates. Doesn't that solve the whole syncing issue? On that note, I've played games like Neverwinter Nights via my normal ADSL connection with me hosting in NL and my friend in Canada joining in, we never noticed any lag. We both have normal ADSL home connections, so how hard can it be?
Setting up a "master server" would mainly be interesting to find people to play with and perhaps bypass some firewall issues. I doubt it's actually required to enable net play.
- Fahr
But that's beside the point; I doubt we'd need anything of that magnitude. Instead of looking at synchronizing a game between 2 clients, perhaps we should look at making one client the master and the other one the slave, with all the game logic happening on the master and the slave merely sending button presses and receiving status updates. Doesn't that solve the whole syncing issue? On that note, I've played games like Neverwinter Nights via my normal ADSL connection with me hosting in NL and my friend in Canada joining in, we never noticed any lag. We both have normal ADSL home connections, so how hard can it be?
Setting up a "master server" would mainly be interesting to find people to play with and perhaps bypass some firewall issues. I doubt it's actually required to enable net play.
- Fahr