Uzebox Live

[uze6666]

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

[paul]

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

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).

[filipe]

Avrdude has a small and nice serial API too. It is just 3 files:

• serial.h
• ser_posix.c
• ser_win32.c

-Filipe.

[paul]

Ahh, filipe; the voice of reason.

[Fahr]

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

[paul]

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

[D3thAdd3r]

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.

[Fahr]

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

[D3thAdd3r]

@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.

[Fahr]

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