Dyed my hair again

Network testing

I got my UDP networking code functional on a "brute force and who cares if we clog the intertubes" level. It sends 200 full game state updates per second, and the clients spit out controls packets (containing, of all bandwidth wasting things, ASCII strings) as quickly as they can generate them. So I went to #wiidev and got a helper on board to fire up the Wii client from an external network:


Each of those crates is under the control of one client. One is a Linux client running on the same machine as the game server. One is a Wii client on the same LAN as the game server, and one is a Wii client about 90 ms away over the internet. The screenshot was captured by the Linux client.

Filesystem layer and menus

I implemented most of a filesystem layer. It gives me uniform access to a media tree on Linux/Windows local filesystem, Wii front SD card slot, Wii USB flash drive, Wii/GameCube memory card files, and the media server I'll keep running. To configure this thing I wrote a simple menu module that pops up on startup to let you pick an FS module and, on some modules, browse for a root directory.



I'm thinking a list of default locations (~/.mod2, sd:/apps/mod2, %whatever-is-the-shortcut-for-application-data%\mvanbem\mod2, etc.) combined with a simple .txt config file would make this screen usually skippable.

I'm hard at work getting some netcode and a useful Player object going. At the moment I can connect to the game server and show unpredicted snapshots on the client's screen. No interactivity yet.

YouTube poop: The Birth of Weegee

Yesterday I was inspired with a vision, so I fired up my XP VM and spent all day fighting with Windows Movie Maker. I also used a healthy dose of the GIMP, but that went much more smoothly. This is what happened:



Here's its page on YouTube. Rate me!

More configure tricks

I previously set up all of the libs needed to compile Project Mod on my Windows XP VirtualBox instance, but it takes forever to compile, so I'm trying once again to set up cross compiling from Linux. It turns out that lots of libs will compile just fine if you pass in a few flags when you configure them:

./configure --host=i586-mingw32msvc --prefix=/usr/i586-mingw32msvc

Of course, more will go wrong, so you have to be willing to dive into the configure script and search for override flags. Some are easier, like how SDL_net requires --disable-sdltest. Without that flag the configure script will try to run a test program, which will fail since it's not producing Linux executables. Others are a bit trickier:

ac_cv_lib_png_png_create_read_struct=yes ./configure --host=i586-mingw32msvc --prefix=/usr/i586-mingw32msvc --disable-sdltest

SDL_image needs libpng for PNG image support, but it compiles a test program to check if libpng works. I know that libpng is fine (I just compiled it), so I made it skip the check by defining_that_long_environment_variable. This command makes the configure script spit out:

checking png.h usability... yes
checking png.h presence... yes
checking for png.h... yes
checking for png_create_read_struct in -lpng... (cached) yes

Without the environment variable that last line fails and PNG support is left out.