Recent work on libxenon has resulted in Paintown successfully working on the Xbox 360. The 360 always supported 6 hardware threads but libxenon recently implemented a threading regime similar to normal pre-emptive multitasking OS’s where a scheduler is woken up by an interrupt and chooses a thread to run. Many other modules in the system had to be updated to support the new threading facility including SDL. Of course new bugs cropped up due to threading. Most of the fixes revolved around adding locks to core parts of the core such as to the memory allocator and usb driver. Almost nothing had to be changed in Paintown to get this to work although a few optimizations were made to avoid some slow paths in libxenon such as using SDL_GetTicks instead of gettimeofday.

The threading work on libxenon was done by sk1080 from #libxenon-dev so a big thanks to him.

We used the free60 tools to port Paintown to the XBox360 and have just got it to load the main menu. It crashes at random times likely due to threading issues but this is a great start. I did very little work to get this going, mostly just recompiled Paintown using the free60 toolchain.

Here is the Gource visualization for 2012

Paintown 3.6.0 is almost ready to be released. I put up builds for windows, linux, and osx in the pre-release folder of the sourceforge downloads section. Once I am satisfied that all the platforms work relatively well I will move them over to the 3.6.0 folder, thus officially performing the release. Builds of the ps3 and wii will take a little more time just because I want to test them at least once before they are released.

I have pretty much blogged about most of the new stuff in this release in previous posts. Most of the work this time went into the mugen engine. It is now quite playable and somewhat enjoyable to watch the AI fight itself. Recently I added 7z support so mugen characters and motifs can be stored in 7z files. This improvement also affects other parts of the system that load compressed files, such as the paintown mod system.

I would have done the release a bit earlier but I had some difficulty getting the OSX build in shape. I spent a few hours this week fixing some problems with the build but once I finally got a working app I discovered that the new gatekeeper in OSX 10.8 threw a wrench into my wonderful plans. Apparently Apple wants all apps to be signed using a certificate issued by Apple themselves and if an app is not signed then the default action of clicking on an app is an error which says ‘this app is damaged’. That error message is reused for a number of other issues such as a malformed Info.plist file inside the app so its not clear to the end user that the issue is related to it not being signed. Anyway there are three workarounds for this issue:

1. The user can allow untrusted apps to be run by changing a global setting
2. The user can cd to paintown-3-6-0.app/Contents/MacOS and run ./paintown-3-6-0 directly
3. I can sign the paintown app with a certificate issued by Apple

I don’t expect a lot of people will go with option 2 so I hope that OSX users can tolerate running untrusted apps. Its not like thats new or anything, gatekeeper didn’t exist versions of OSX earlier than 10.8. Option 3 is possible but to get a certificate I need to enroll in the Mac Developer Program which costs $99 a year. This amount of money isn’t a lot but I feel its quite unnecessary to be subjected to a rather arbitrary fee to work around an artificial problem. If someone wants to donate the money to me I am more than happy to use it to sign up for the program and get a signing certificate.

It may be possible to sign the app with a self-issued certificate but all the advice and googling I have found so far indicate that this will not work.

I asked some other OSX developers if this new gatekeeper thing will effectively destroy free/open source software on OSX. I didn’t get a direct answer but someone did say that apps built on the same machine that will ultimately run the app don’t have to be signed. While probably true that is an onerous task that extremely few users would be willing to put up with. The Paintown OSX build is pretty difficult even for me. I could make it slightly easier but still I doubt many people would bother doing it. I haven’t found out yet what other open source projects are doing / going to do about this signing issue but I would like to find out.

Anyway I am excited for this release because there are new features/bugs I want to fix that would have delayed the release had I done them earlier. I hope everyone enjoys it.

We extended zip file support in Paintown to the MUGEN engine. Now characters can be loaded directly from zip files just as the original MUGEN engine was capable of. Probably the next feature to support zip files will be MUGEN motifs.

Also, Juvinious has implemented an IRC client that we plan on using for multiplayer lobbies. The main motivation for this work came from supporting network mode in MUGEN. Actually playing networked games in MUGEN still has a ways to go but setting up the other parts of the system can be done in parallel. Paintown arcade mode supports network play and uses its own protocol for dealing with chat but it would be simpler and more effective to re-use the IRC protocol instead.

Our plan is for chat rooms created within Paintown to be hosted on a standard IRC server, such as freenode.net, so that people outside the game can chat using their own IRC clients and hopefully people can find out about games much easier. Of course users would be able to connect to any IRC server if they wanted to.

Recently a user wanted to compile Paintown for Android but ran into some issues while following the setup instructions. When I looked into what went wrong I found that the version of SDL I was using for Android (from SDL’s mercurial repository) had been updated in such a way that Paintown wouldn’t compile anymore. SDL 1.3 is currently in beta so the SDL developers feel free to change the API at their whim. I had created a patch to change a handful of things in SDL 1.3 that I didn’t like and/or to keep backwards compatibility with SDL 1.2 but so many things have changed in SDL 1.3 that maintaining the patch would have become a huge burden.

Instead I am going to transition Paintown to the Allegro5 backend, similar to how Paintown is implemented on the IPhone/IOS. Allegro5′s API is fairly stable at this point and I know most of the people working on the library itself so I feel more comfortable using it for bleeding edge development. The Android port of Allegro5 was recently started by a motivated member of the Allegro community and has got the essential parts working. There is still much work to do, however. One glaring piece that is still missing is sound. I started to implement a backend for OpenSL, a sound standard made by the same people that develop OpenGL: the Khronos group. I have only just started looking at the specification for OpenSL so it will take me a while to implement something working. I can’t seem to find any OpenSL implementations for Linux on the desktop, apparently the only working implementation exists for Android so I will have to test in the emulator.

Paintown now has the ability to load resources from zip files. So far I have only implemented loading arcade mode players from zip files but in the future more files will be able to be read from zip files. Also I will add support for other container formats such as .tar.gz, .rar, .7z and whatever else.

r7235 is the relevant change to the code

The zip code came from the minizip project and it works fairly well. I had to add an abstraction for files that allowed Paintown to read from arbitrary sources, similar to Java’s Reader interface. So far there are reader implementations for strings, fstream objects, and zip files. New containers can simply implement the reader interface and suddenly those formats will be supported by Paintown. Then I changed all the constructors for objects that read data from files to accept the Reader interface. These classes include Graphics::Bitmap, Sound, and TokenReader.

Since Paintown already uses a virtual filesystem layer it was easy to add support for container objects. Files are looked up using a call to Filesystem::find() which searches various places on the filesystem or in the case of NACL will check if the file is available on the server. I added an extra layer of indirection to find() called an overlay that contains information about pseudo-files, exactly those files in container files. When a zip file is opened by the Filesystem manager all its contained files are added to the overlay so future lookups for those files will resolve properly. Originally the return value of Filesystem::find() was a Filesystem::AbsolutePath class but to support new data sources I changed it to Filesystem::File, which is the name of the reader interface class.

Paintown now supports an option to enable various high quality filters. Right now they only work if the window size is an exact multiple of 320×240 such as the default 640×480.

Right now there are HQX and XBR filters implemented for SDL. These filters are fairly CPU intensive and should only be used if you have at least a 2ghz cpu. At some point I will implement them as opengl shaders as well.

In revision 6727 I completed the implementation of an hq2x filter based on code from byuu (forum link). The original code was set up for RGB 555 but Paintown uses RGB 565 so I had to fiddle with some of the constants.

Here is a screenshot of mugen with and without the hq2x filter. First with the filter:

And without the filter

If you look at the edges of sprites you can see the hq2x version is much smoother.

The hq2x filter is somewhat expensive so its not enabled by default yet. I will have to experiment more with it to see when its best to use it in the game. Also the ’2′ in hq2x means the source image is scaled by 2. There are times when images in Paintown need to be scaled by 4 and for that there is hq4x! But the code for that is not as easily hackable as hq2x so I’m not sure if I’ll implement hq4x.

The current implementation is only for SDL. It can probably be ported to Allegro4, though, without too much effort. This code is a good candidate for a pixel shader which would work well with Allegro5.

I compiled Paintown using the android ndk and have just got it running in the android emulator.

The emulator is pretty slow but most functionality seems to work: input, sound/music, and loading all the data. I was unable to load adventure mode but was able to enter an arcade mode match in mugen.

We tried testing on a real EVO android phone but the game was crashing on startup so more debugging is needed, but this is a good start.

This port is made possible by SDL 1.3 already having an android backend. There are a few bugs in it yet to be solved but that should not take too long I hope.