JKKDARK
June 9th, 2008, 18:57
http://blog.dev-scene.com/flatware/
A tetris game based on Tetris Attack.
Changelog:
* Local Wifi
* Host game on DS
* SDL port for PC
* Lots of changes in the code
It's been a long time since there was any news on Tetattds. Two big things has happened. The first is that we ported Tetattds to SDL so that it can run on PC during the last year. The purpose for this was that we wanted to be able test new features with access to a debugger. If we ever would add a big feature like AI players this would be very useful, although we probably never will. Another reason was to see if it was even possible. It was but the code is now in a mess.
You can play the SDL version against other DS players, but as I said it is only meant to be used for development. One problem is that the GUI is exactly the same as the DS version, and not suited for PC. I have provided a compiled version for Windows. If you want to have instructions for compiling on Linux or Mac OS X please post a comment.
The other big thing, local wifi, was added during christmas. It is now possible to play multiplayer player games without an access point. This was made possible using liblobby, which is a work-in-progress library, but development seems to have stopped.
One reason I didn't release Tetattds 3.0 back then was that I meant to refactor the network code in to make efficient use of the bandwidth of local wifi. One problem with liblobby is that it sends packets reliably, and when too many packets is pouring in they start to pile up.
The network code in Tetattds is implemented using UDP, with reliable packets on top of that. That gave us much better response times than TCP since TCP is cached. This also means we don't need liblobby's reliable implementation. If it was possible to send packet directly, and skipping the "lobby" part of liblobby, we could send field updates a lot more often, since these are sent unreliably. There is a function to broadcast packages unreliably which would be perfect for this, but I need to refactor the code to make use of this.
Unfortunately the christmas vacation was over and I lost interest in the project, so I never investigated that further. I'm releasing what I have now so that it will not go to waste. Be warned that it is somewhat unstable.
A tetris game based on Tetris Attack.
Changelog:
* Local Wifi
* Host game on DS
* SDL port for PC
* Lots of changes in the code
It's been a long time since there was any news on Tetattds. Two big things has happened. The first is that we ported Tetattds to SDL so that it can run on PC during the last year. The purpose for this was that we wanted to be able test new features with access to a debugger. If we ever would add a big feature like AI players this would be very useful, although we probably never will. Another reason was to see if it was even possible. It was but the code is now in a mess.
You can play the SDL version against other DS players, but as I said it is only meant to be used for development. One problem is that the GUI is exactly the same as the DS version, and not suited for PC. I have provided a compiled version for Windows. If you want to have instructions for compiling on Linux or Mac OS X please post a comment.
The other big thing, local wifi, was added during christmas. It is now possible to play multiplayer player games without an access point. This was made possible using liblobby, which is a work-in-progress library, but development seems to have stopped.
One reason I didn't release Tetattds 3.0 back then was that I meant to refactor the network code in to make efficient use of the bandwidth of local wifi. One problem with liblobby is that it sends packets reliably, and when too many packets is pouring in they start to pile up.
The network code in Tetattds is implemented using UDP, with reliable packets on top of that. That gave us much better response times than TCP since TCP is cached. This also means we don't need liblobby's reliable implementation. If it was possible to send packet directly, and skipping the "lobby" part of liblobby, we could send field updates a lot more often, since these are sent unreliably. There is a function to broadcast packages unreliably which would be perfect for this, but I need to refactor the code to make use of this.
Unfortunately the christmas vacation was over and I lost interest in the project, so I never investigated that further. I'm releasing what I have now so that it will not go to waste. Be warned that it is somewhat unstable.