Uzenet

Topics regarding the Uzebox hardware/AVCore/BaseBoard (i.e: PCB, resistors, connectors, part list, schematics, hardware issues, etc.) should go here.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzenet

Post by D3thAdd3r »

Uzenet with ESP8266 emulation has been ported to the 2.0 codebase. Compiles on Linux for me, so we should be good there. Of course, there is a problem that shows up!

For some reason the ESP8266 clock is running out of sync with Uzebox side so programs working on the older version and hardware do not work. It is way out of sync actually, so I am hoping I will be able to find why that is more easily than I tracked down the minute race conditions before. More to come on that front.
User avatar
L4rry
Posts: 242
Joined: Sun Dec 28, 2014 7:19 am
Location: Cape Town, South Africa

Re: Uzenet

Post by L4rry »

With the uzebox portable on the horizon, the idea of doing some peer-to-peer netcode for Tank Fu that will allow 'local' multiplayer across two portables has got my juices flowing a bit :) I've always wanted to try real-time netcode and this seems like an ideal time to get started on that. I'm imagining using the ESP8266's ability to to set itself up as an access point to achieve peer-to-peer local networking and then using the UART interface for setup and data exchange. Using Tank Fu as an example, I imagine having two menu options. 'Host 2 player game' and 'Join 2 player game'. The first will setup an access point with SSID and randomized access credentials. The second option will then require to enter those credentials for a pairing. Anyway, I've still got a lot to learn about ESP8266 and UART before I get any plans finalized.

To that end, what would be the best way to start developing for ESP8266? Has it been emulated somewhere successfully or (if I go by the above comment) is this still something that's buggy? I'm hoping for a way to launch two emulator instances on two machines (virtual machines) and test that way but I've got a feeling it's not going to be that easy.

Can someone recommend a development setup that worked for them?

If I understand Uzenet correctly, it's a collection of standardized services and API's to provide a unified networking experience for the uzebox community. Not anything directly related to ESP8266? I'm assuming my intended approach here is not compatible, but I feel it's a good starting point for me and local peer-to-peer could still be a desirable functionality to add to such an endeavor as Uzenet if I can get it right. Especially with portables becoming available.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzenet

Post by D3thAdd3r »

I need to finish it which will take some work, but ESP8266 emulation is realistic....just not usable right now. I have done some testing with networked stuff using it, and the same software worked on hardware and emulation the same. The approach is a high level emulation of the commands, timing, and state, not the actual module hardware. UART emulation on the 644' needs cycle perfect. It will require a standardized firmware to be decided as official on the mode to ensure timings are realistic in emulation. Right now I can only suggest 2 x Uzebox+Uzenet modules for development. You could probably network by doing a UART crossover between the machines without the ESP8266 too.

Right now my testing has revolved around a setup utility which saves settings to flash and creates and automatic connection to WiFi then auto connection to the uzenet server via TCP. The idea is that no game needs to anything except wait a bit then send a login with no error checking. Then send an echo command, if the response is not correct than something is not right and the setup program needs to be ran. There really is a lot of code necessary to string parse and error check all the possible wifi and internet issues, thus a dedicated in depth utility that saves settings on the ml odule allows simple game side setup logic. It is almost certainly the best way for internet games at least. Direct client<->client over the internet has a whole slew of issues with NAT punchthrough, so users would probably need to manually port forward in that case. NAT punchthrough is possible I guess, but it is a lot of code and timing Uzebox side and still requires an initial connection to the server.

Now for local play that could be different I suppose if you intend to do direct connection. I think the newer firmwares do have a DHCP server maybe but never tested. Otherwise each machine would need a static non-conflicting assignment if you skip the router which normally does DHCP. The ESP8266 will not do any routing, but as long as they are in the same subnet(say 192.168.1.0/24) and not looking to hit outside, I should think it "switches" fine, just haven't tried it like this.

One thing to keep in mind is that the ESP8266 is never going to be as good as ethernet, let alone a controller port or a direct serial connection. There is quite a bit of jitter in latency, and existing firmwares allow only 50hz packets maximum. So realistically you can expect roughly 30-130ms delay without even hitting the internet. That is partially why I started aiming for ideas that tolerated that well. Still though I think a reflex game could still be fun and work reasonably with good coding, prediction, "catch up", etc. It would probably be an interesting problem to work on.

I have ran maybe 6 instances of the old Uzem+ESP8266(beyond slow!) in the now defunct chatroom(moving over to IRC protocol maybe). There are no NAT issues with the central server approach! Nor would there be for local only play. The server I have is all stream based. You send a byte which is a command, which can have arguments, and it causes state changes and actions on the server(including joining a channel and forwarding data to others). Variable length arguments are prefixed with a length, and almost no commands are time based. Actually quite simple since you can send 1 concatenated string of all commands, they get used in order, and error check the final state later. The server is designed to make Uzebox side easier, but there is a lot of refactoring I want to do after trying to make the simplest possible networked game using Pong and seeing simplifications.

If you are interested in local only that is perfect. I could then focus just on the subset of integrating emulation instead of also the server side. More or less it was about time shortages, but even more I guess is someone else being interested to develop such a game. It is definitely the time for this and it is pretty far along. I have no hope of finishing a UCC game, but this could be done in less time to a useful state.
User avatar
L4rry
Posts: 242
Joined: Sun Dec 28, 2014 7:19 am
Location: Cape Town, South Africa

Re: Uzenet

Post by L4rry »

D3thAdd3r wrote: Tue Aug 14, 2018 8:41 pm Right now I can only suggest 2 x Uzebox+Uzenet modules for development. You could probably network by doing a UART crossover between the machines without the ESP8266 too.
Cool. I've ordered a pair of ESP8266-12f modules to mount on my boards (I've got the latest PCB version that allows that). Question, do they need to be accompanied by SPI RAM modules? I saw a photo somewhere of a separate Uzenet 'dongle' and it seemed to have an extra chip apart from the ESP8266 module.
D3thAdd3r wrote: Tue Aug 14, 2018 8:41 pm If you are interested in local only that is perfect. I could then focus just on the subset of integrating emulation instead of also the server side.
Yeah local peer-to-peer will be my approach to start off with. The server side stuff I can do later if I get this bit right. First thing I need to do is do some re-factoring of the Tank-Fu code to make some flash space available and also some RAM. Looking back at my code now there is a lot of 'WHAT WAS I THINKING!?' going on in my head :lol:

Anyway, I hope I can make head way with this. We'll see. I also initially wanted to do a new game for UCC but simply can't find the sustained time and energy to see it through at this stage.

EDIT: This is the picture I'm referring to which was posted a page or two back on this thread. Can I use the UART API functions directly with the ESP8266-12f module or would I need that extra chip as pictured?
modulev2.jpg
modulev2.jpg (78.78 KiB) Viewed 7065 times
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzenet

Post by D3thAdd3r »

You don't need to have SPI ram, the ESP8266 will work fine without.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzenet

Post by D3thAdd3r »

I was thinking on this how you can minimize latency effects. Even local direct connect, though I have not tested like this, is still subject to possibly ~20ms of polling rate(you will most likely want to use the so called "unvarnished" 50hz packet mode) and I suppose too...my rough guess...of 30-60ms in WiFi framing/timing/etc. jitter. So in my mind it would be most effective to be able to decouple the simulations on both sides and be able to rapidly converge them. Something like updating with the last control state to predict tank movement up to the current local time. Same for shots, as soon as you are aware the other side did shoot, run 2 updates per frame on the projectile until the time stamp of that reaches the local frame. It should barely be noticeable with <100ms, and you would already have about as good as possible handling of internet gameplay.
User avatar
L4rry
Posts: 242
Joined: Sun Dec 28, 2014 7:19 am
Location: Cape Town, South Africa

Re: Uzenet

Post by L4rry »

I'm thinking along similar lines. The trick is going to be to only send across information whenever an important event occurs as apposed to syncing as much state as quickly as possible all the time. Then use interpolation and extrapolation as you suggested to smooth things out.

I'm going to be basing my initial work on the principles talked about in this article:

https://gamedevelopment.tutsplus.com/tu ... edev-10074

They call it non-authoritative networking. Essentially, peers keep track of their own state and only communicates across key events as they happen. Like movement changes, shots fired, dying etc. Then filling in the gaps caused by latency or lost packets by interpolation and extrapolation.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzenet

Post by D3thAdd3r »

I think that is exactly the approach since it leverages something Uzenet can have versus larger scale commercial games: trust. A lot of simplificatiins and optimizations come from that. Being open source it would be relatively easy to make a hacked version, but making even 1 person mad by cheating, this hypothetical cheater would probably be without anyone willing to play in short order. Local play is even easier to self regulate, since you can walk over and slug the guy in the shoulder :lol:
User avatar
L4rry
Posts: 242
Joined: Sun Dec 28, 2014 7:19 am
Location: Cape Town, South Africa

Re: Uzenet

Post by L4rry »

So I've soldered my esp-12f module on my v1.3.1 and coming as absolutely no surprise to myself, I can't get the UzenetDemo to talk to it. I never get hardware right the first time :lol: I've tried various baud rates. Double Speed and Single Speed.

I just want to confirm that I've got all the parts I need. Specifically, I'm curious about the c17 and c22 capacitors and IC3. Not sure if these are required for the esp-12f module, but thought I'd ask because of their geographic location right above the module. Here's a pic of my setup.
20180826_095249.jpg
20180826_095249.jpg (360.78 KiB) Viewed 6940 times
Any other advice will be much appreciated :) I guess a bad solder is also a possibility, but I don't think so. As ugly as that bit on the left of the module looks :mrgreen:
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Uzenet

Post by Jubatian »

L4rry wrote: Sun Aug 26, 2018 9:05 amI just want to confirm that I've got all the parts I need. Specifically, I'm curious about the c17 and c22 capacitors and IC3. Not sure if these are required for the esp-12f module, but thought I'd ask because of their geographic location right above the module. Here's a pic of my setup.
I believe you will need those. The SPI RAM, which is normally the other device on an Uzenet card, works fine without any extra parts. A bit of looking around revealed this: ESP8266 on the Wiki, they are responsible for the 3.3V the ESP8266 needs. So most likely in your current setup, the ESP8266 isn't even powered.

At least it isn't a bad solder then! :D
Post Reply