- The three types of display encoding have now been merged so that the pixels are only looped through once. This improves server performance a bit
- The client now sends joystick updates to the server, so it's now possible to control gameplay.
- I've added adaptive rate limiting through frame dropping. Basically, display updates are sent every frame until the traffic rates reaches a target kbps rate. Then frames are dropped until the rate has slowed down below the target kbps again.
Rudimentary testing of the rate limiting shows that it seems to work just fine, especially in games such as international karate which are pretty static much of the time (and in those cases, it can use full frame rate). I also tried the network code between two computers, as you can see above. There are some graphics glitches in the image caused by the break in communications when the menu is entered, but that should be pretty simple to resolve, and other than that it worked very well. Looking close, you can see the movement on the snapshot :-)
Answering my own question from the last post, the technique to establish direct connections between hosts in NAT'ed environments is called UDP hole punching and is described well in the Peer-to-Peer Communication Across Network Address Translators article by Bryan Ford et al. TCP hole punching also exists, but is in general less compatible than the UDP variant. Unforunately, I'll need to replace the current TCP-based implementation with a UDP ditto instead and also implement a protocol to talk to the third-party server and "punch the hole". It will be an interesting exercise if nothing else!
I've also posted a new version of my graphical frontend to objdump, Dissy, and moved it to googlecode. The new version supports pasting of Linux kernel crashdumps which will give you the callchain in the "browser" history.