wraggster
November 29th, 2009, 20:05
DCEmu Member Simon Kagstrom (http://simonkagstrom.livejournal.com/47120.html) has posted some WIP News concerning the Commodore64 emulator for the Nintendo Wii:
I've recently been working on some improvements on the Frodo/Wii networking
implementation. The problems I wanted to address were these:
The connection to the Frodo network broker was a confusing process, with the user having to select master or client connection beforehand
Sound was not transferred over the network!
There were too few bells and whistles :-)
The first problem can easily be seen on the network statistics for Frodo/Wii. Most people will connect twice, first trying as a client and then as a master to await some other player. The current subversion trunk has this fixed so that you connect in one way only, and then either select a peer to play with, or wait for someone to connect.
For more bells and whistles, I now transfer a small screenshot of the C64 display when someone connects. This is supposed to be used in two places: In the peer selection menu and on the broker network stats. I don't run the new broker online yet, but the new statistics web page will look like this:
http://i49.tinypic.com/10idz0y.png
I'm also redesigning the menu support to make it look better, but this work is still a long way from finished (i.e., nothing works!)
But the most important part is the sound transfer. After all, International Karate is soo much better with music and sound. The reason I haven't implemented it until now is that sound is a bit more tricky than graphics and joystick data:
Joystick and text message data generate very low traffic, so that's the easiest part
Graphics and sound on the other hand, generate much more data
Graphics is still pretty easy, since you can drop frames and skip updates without affecting gameplay that much
With sound on the other hand, dropping data will be very irritating
My first approach (implemented a long time ago but never enabled), was to simply take the generated audio and transfer that. This, however, is problematic in at least two ways:
16 bits of data at 44KHz is simply a lot of data to transfer, even with the (fairly primitive) compression techniques I employed
The audio format is platform dependent. My linux box has 16-bit at 44KHz, while the Wii uses 16-bit at 48KHz or 32KHz, so the sound will not be cross-plaform
The implementation of the first approach never worked well. So what I've done now is to do this in a different way. The basic idea is to transfer SID register writes instead of audio-data and simply re-emulate them at the other end. I've so far known very little of the actual C64 emulation, but needed to look a bit more into it for this.
I first did a small test to determine how much data this would actually be by simply printing out all SID register writes. Simple eyeball investigation showed that this wouldn't be too much. The implementation is then pretty simple: Just log each register write together with the temporal offset since the last write (given in number of VIC lines because of the way the emulation works), and then send this out to the peer each 100 ms or so.
And this also works pretty well in the real world as well, when tested between my X41 and Lindas X40. The bandwidth used varies a lot depending on the type of sound characteristics the game has. The music and sound effects in Uridium for example doesn't require much, whereas the "kiay" sound effects in International Karate generate a lot of SID traffic. There is probably a lot to be learned there for those that are interested in how the actual SID works.
I've also registered the c64-network.org domain, which I plan to use for the network stuff in the future. Right now, I'm working on the improved menu support though, and this looks like it might become time-consuming. I don't like GUI work in general, but in this type of application it's really a must. Oh well, sooner or later it will hopefully be functional...
I've recently been working on some improvements on the Frodo/Wii networking
implementation. The problems I wanted to address were these:
The connection to the Frodo network broker was a confusing process, with the user having to select master or client connection beforehand
Sound was not transferred over the network!
There were too few bells and whistles :-)
The first problem can easily be seen on the network statistics for Frodo/Wii. Most people will connect twice, first trying as a client and then as a master to await some other player. The current subversion trunk has this fixed so that you connect in one way only, and then either select a peer to play with, or wait for someone to connect.
For more bells and whistles, I now transfer a small screenshot of the C64 display when someone connects. This is supposed to be used in two places: In the peer selection menu and on the broker network stats. I don't run the new broker online yet, but the new statistics web page will look like this:
http://i49.tinypic.com/10idz0y.png
I'm also redesigning the menu support to make it look better, but this work is still a long way from finished (i.e., nothing works!)
But the most important part is the sound transfer. After all, International Karate is soo much better with music and sound. The reason I haven't implemented it until now is that sound is a bit more tricky than graphics and joystick data:
Joystick and text message data generate very low traffic, so that's the easiest part
Graphics and sound on the other hand, generate much more data
Graphics is still pretty easy, since you can drop frames and skip updates without affecting gameplay that much
With sound on the other hand, dropping data will be very irritating
My first approach (implemented a long time ago but never enabled), was to simply take the generated audio and transfer that. This, however, is problematic in at least two ways:
16 bits of data at 44KHz is simply a lot of data to transfer, even with the (fairly primitive) compression techniques I employed
The audio format is platform dependent. My linux box has 16-bit at 44KHz, while the Wii uses 16-bit at 48KHz or 32KHz, so the sound will not be cross-plaform
The implementation of the first approach never worked well. So what I've done now is to do this in a different way. The basic idea is to transfer SID register writes instead of audio-data and simply re-emulate them at the other end. I've so far known very little of the actual C64 emulation, but needed to look a bit more into it for this.
I first did a small test to determine how much data this would actually be by simply printing out all SID register writes. Simple eyeball investigation showed that this wouldn't be too much. The implementation is then pretty simple: Just log each register write together with the temporal offset since the last write (given in number of VIC lines because of the way the emulation works), and then send this out to the peer each 100 ms or so.
And this also works pretty well in the real world as well, when tested between my X41 and Lindas X40. The bandwidth used varies a lot depending on the type of sound characteristics the game has. The music and sound effects in Uridium for example doesn't require much, whereas the "kiay" sound effects in International Karate generate a lot of SID traffic. There is probably a lot to be learned there for those that are interested in how the actual SID works.
I've also registered the c64-network.org domain, which I plan to use for the network stuff in the future. Right now, I'm working on the improved menu support though, and this looks like it might become time-consuming. I don't like GUI work in general, but in this type of application it's really a must. Oh well, sooner or later it will hopefully be functional...