Page 21 of 25
Posted: Thu Sep 13, 2018 6:19 am
Small update on the Uzenet front. Still testing out the circuit by working on my telnet program. All works pretty good as you can see...compiling the uzenet demo via telnet from my Uzebox!
Obviously you need the uzebox ps/2 keyboard adapter for that...Also found a very cool telnet site with plenty of old retro stuff on it like games, tools, a basic interpreter and so much more! Check telehack.com
, really cool. Oh, and btw I will send the portable's new PCB design for manufacturing this week.
Posted: Wed Sep 19, 2018 3:49 pm
I need to try this out soon, I have wanted an Uzenet Telnet for years now. This comes when all my Uzebox stuff is buried in boxes at the new house of course!
Posted: Wed Sep 19, 2018 6:18 pm
Yes I can relate, all my Uzenet stuff was buried in my locker. I'll writeup on the wiki on how to update the esp12. I recall you had a uzebox keyboard right? Another cool thing to do via telnet is browse the web ...in all its text mode glory!
Btw, I've added a page to the wiki under Uzenet about installing and configuring cygwin and the xinetd deamon for a telnet server.
Posted: Wed Sep 26, 2018 3:47 pm
Wow! This new pass through mode sounds awesome! I remember when I was last working on my Uzenet code (*cough* years ago *cough*) I gave up in frustration because of how hard it was to deal with the firmware. This gives me hope, that's for sure. Between this, the upcoming portable, and pictures of that gorgeous 1702 monitor, I'm practically drooling
Posted: Wed Oct 10, 2018 12:32 pm
So I've finally got LAN based multiplayer running for Tank Fu
If you've got 2 Uzeboxes, with a pair of ESP8266s that support UART-Wi-Fi passthrough mode, give it a try!
On startup, the game will look for a Wifi module. And if found, will initialize it and present you with 'Host LAN Game' and 'Join LAN Game' options on the splash screen after several seconds. If no module is found or it could not be initialized, the normal playing options are still available.
The peer selecting 'Host LAN Game' will be presented with a unique game id that he/she needs to share with the peer selecting 'Join LAN Game'. After the latter peer enters and accepts the game id, pairing is established and you are good to go for 2 player LAN gaming.
So this is a peer-to-peer networking setup. One instance will host a LAN game by setting itself up as a WIFI access point with an SSID based on the NIC part of the ESP8266 module MAC address. A second instance can then join a LAN game by connecting to that access point using the SSID shared by the host (like shown in the screenshot above). Minimal game state changes are then shared between the two instances using UDP in passthrough mode. UART comms happen at a buad rate of 38400 (double speed).
It was quite the adventure initializing the WIFI module reliably as you have no idea what the current baud rate is set to, you don't know if the module is perhaps already in passthrough mode (Resetting the Uzebox does nothing to the state of the Wifi module it seems. So your game can boot up while the module is still in passthrough mode) nor do you know if it's even there! I essentially spam it with passthrough terminators (+++) and 'AT' commands cycled at various baud rates till I get an 'OK' response. That's why it takes a while for the splash screen to appear at initial bootup.
It's by no means perfect yet, but it's running quite nicely. It's quite reliable to setup and runs at a pretty low latency too. I'm happy with the results so far. Having said that, here are some known issues I want to address before making a formal release:
- I have an Rx buffer size of 256 bytes. That's 4 ram tiles I had to subtract from my allocation. So things are flickery. I had to do this because my game loop is too slow and this is the smallest buffer size (with the slowest reasonable baud rate) I can consume off without it filling up and then dropping data. I need to reduce my game loop cycles to guarantee no dropped packets with a smaller buffer size
- I'm still not 100% sure if zero Rx buffer data drops remain in all scenarios. Any corrupt data packet coming through will break the game. Only further testing will give me confidence here.
- The handle select screen might consist of different handles for different peers. So when a handle is selected on one peer, it might look different on the second. Not a train smash, but I want to send over absolute handle state as apposed to relative state changes.
- The spectating peer in the boss fight finale might get stuck once the boss fight is finished and will have to reset the uzebox. Should be a simple enough fix.
Let me know what you think or if you spot any bugs. Have fun!
Posted: Wed Oct 10, 2018 6:31 pm
Pretty awesome, congrats for the first Uzenet game!!
I will try that as soon as I can upgrade the esp12 firmware on my second uzebox.
While working on my telnet client I got some of your setup program and found that very annoying too. I gave it a lot thoughts and open another thread to discuss it. But roughly my idea would be to have a standardized Uzenet setup done by a separate rom. In there it would auto detect baud rates, restore the module to factory settings, set a default baud rate low enough (9600 baud?), Set the SSID and password, etc. Everything so that when you simply reset the module it is in a known state. This has the obvious advantage of not having all this overhead code and complexity to put in all games. I also started a wifi API for the kernel to ease the job of connecting, enter passthough mode etc.
Posted: Fri Oct 12, 2018 10:17 pm
So cool! Trying this out is on my long Uzebox "TO DO" list when I get back to it. Sounds like UDP is flying plenty fast for smooth gameplay on a twitch game then, which is promising.
You may already know: UDP packets can arrive out of order, duplicated, or not at all, but should never be corrupt as a packet with a bad checksum is silently dropped at the network level. Just in case you were chasing a ghost like that at network side. TCP buffers to hide that, but you clearly know that as you chose UDP for a reason, which was not simplicity! Is the game lockstep networking? If so, it should be "easy" to handle dropped or out of order packets.
Posted: Fri Oct 12, 2018 10:32 pm
Another weird caveat is that UDP packets might not be appropriately handled by ESP8266 in all cases. In normal sockets programming on PC, when you send() the entire payload is a single element. If it gets fragmented along the way(internet weird MTU or something) it should still be reassembled as a single unit before software sees it. This is critical since it can be out of order, so you need known starts stops to interpret meaning(when order is otherwise unknown), not some random half a packet here and there. Passthrough does not have a discrete send/recv since it is based on timing alone, so depending where 50hz lines up, it could "chop" in a weird spot. I suspect this is why you need such a large buffer to get reliable results.
Posted: Sat Oct 13, 2018 4:40 am
I actually didn't consider the fact that UDP messages can arrive out of order! I chose UDP because it's faster. Less back and forth handshaking. Apart from that, I purposely went with a naive approach as this is direct peer-to-peer communications between two network interfaces doing nothing else and this is my first real time network gaming code. I'd rather not preempt any possible edge conditions until testing proves it to be necessary. I certainly haven't come across UDP packets arriving out of order. I think that scenario is proberbly more likely over a network with multiple routing points feeding a destination taking content from more than one source. I will look out for it though. Thanks for the heads up.
This is very much a new field for me. The intricacies is fascinating. Right now, I'm keeping it simple
Posted: Tue Oct 16, 2018 3:24 pm
D3thAdd3r wrote: ↑
Fri Oct 12, 2018 10:17 pm
Is the game lockstep networking?
No it's not. I essentially just pass a fixed length UDP packet across to the other peer for each important state change as it happens. Things like tank posture change (change in direction), being hit by a bullet, shooting, picking up an item etc. Along with each of these packets I'll send things like absolute scores, speeds and tank positions so that dropped packets will auto correct itself when the next one arrives.
Having said that, there are scenarios where a dropped UDP packet will break the game. Like transitioning levels, starting the game or even a pause toggle. So I want to implement a 'reliable' UDP messaging scheme just for these specific scenarios. So essentially identify the critical messages and resend them until an acknowledgment is received. I need to give this some thought though, but I'm confident I can come up with a solution.
The next build I share on here will include a system like this along with the fixes I already mentioned I need to make. So far I've replaced floating point types with fixed point arithmetic and that's already sped up my game loop significantly, freed up some RAM and also reduced the size of my net messages. In addition, I want to optimize my message sends so that I combine multiple state changes into one message. For instance at the moment, let's say I shoot, turn, explode and catch an item all at the same time, I'll send a total of 4 messages across in one frame. I could rather combine this into one message. No reason not too. That will also help out on the receiving end as I only read one message per frame from the Rx buffer. If I can guarantee at most one message per frame being sent, then I should be able to reduce my Rx buffer size even more.
Hopefully I'll be able to provide a much improved build in the not too distant future.