Mac Version of Spore CC Uses Code From WINE

Instead of making an actual port of the Spore Creature Creator for Mac, it appears EA has simply bundled WINE code (see the 'transgaming' folder inside the app bundle) in with a Windows-compatible .exe file (it's something called Cider that they talked about at some developer conference a while back). This is pretty depressing for the whole "gaming on Macs" crowd, but it brings up some interesting thoughts about getting it to work on Linux.

This may not reflect much on the standard WINE install, since Transgaming has a spotty history of contributing back to the WINE community, but I'm hoping I can use this info to get it going on my Gutsy box. I'll make a new post if I can figure anything new out.

(Edit: I ran into dll hell for a while, but I got that part worked out. Now it starts up mostly error-free except I get an error that says "A required security module cannot be activated. This program cannot be executed (8008)." If anyone has a clue how to get past this, let me know.)

Update: no luck with the 8008 error, but I looked at the MD5 checksums for the windows .exe and the .exe file that's bundled into the Mac install and, although they both are 16.6 MB, their checksums are different:

3bcbb5ce269c4a38e73344fcb4c87949 for the Mac version

and

eb2834d31b2cb572a4f22947e000127e for the Windows version

[Let me know if you guys come up with different checksums]

This suggests that Cider does something (possibly at the compile time) that's making them different. I would assume it's something similar to the Darwine SDK that lets you compile Windows executables from source for use on Macs, but who knows. This in mind, you may have better or worse luck when trying to run the different versions with WINE since they're not exactly the same.)

For anyone interested, here's a list of the the .dll files that Transgaming included in the Mac version, which may give a clue to what is needed to run it in Linux:

cg.dll
cgD3D9.dll
d3d8.dll
d3d9.dll
d3drm.dll
ddraw.dll
dinput.dll
dinput8.dll
dmusic.dll
mfc42.dll
mfc71.dll
msvcirt.dll
msvcp70.dll
msvcp71.dll
msvcp80.dll
msvcr70.dll
msvcr71.dll
msvcr80.dll
msvcrt.dll
opengl32.dll
psapi.dll
squish_nosse.dll
squish.dll
stdole2.tlb
stdole32.tlb

Likewise, here's a list of the dll overrides they're using in their transgaming config file (located at Resources/Preferences/config in the Mac bundle. You can also find the system.reg file, which holds a lot of interesting info, in that folder):

[dlloverrides]
"commdlg" = "builtin, native"
"comdlg32" = "builtin, native"
"oleaut32" = "builtin, native"
"ver" = "builtin, native"
"version" = "builtin, native"
"shell" = "builtin, native"
"shell32" = "builtin, native"
"shfolder" = "builtin, native"
"shlwapi" = "builtin, native"
"lzexpand" = "builtin, native"
"lz32" = "builtin, native"
"comctl32" = "builtin, native"
"commctrl" = "builtin, native"
"advapi32" = "builtin, native"
"crtdll" = "builtin, native"
"mpr" = "builtin, native"
"winspool.drv" = "builtin, native"
"d3d8" = "builtin, native"
"d3d9" = "builtin, native"
"d3drm" = "builtin, native"
"ddraw" = "builtin, native"
"dinput" = "builtin, native"
"dinput8" = "builtin, native"
"dmusic" = "builtin, native"
"dsound" = "builtin, native"
"opengl32" = "builtin, native"
"msvcrt" = "native, builtin"
"rpcrt4" = "native, builtin"
"msvideo" = "builtin, native"
"msvfw32" = "builtin, native"
"quartz" = "builtin, native"
"mcicda.drv" = "builtin, native"
"mciseq.drv" = "builtin, native"
"mciwave.drv" = "builtin, native"
"mciavi.drv" = "native, builtin"
"mcianim.drv" = "native, builtin"
"msacm.drv" = "builtin, native"
"msacm" = "builtin, native"
"msacm32" = "builtin, native"
"midimap.drv" = "builtin, native"
"psapi" = "builtin, native"
"wininet" = "builtin, native"
"dbghelp" = "native, builtin"

Also located in the Mac bundle is a folder called MacOS that includes a pair of Unix executables called 'cider' and one called 'cidernoui.' I tried running these in my Linux terminal and it made my text go wonky in that session. Very strange.

Another file, Resources/transgaming/c_drive/Program Files/EA Games/Spore/Data/Config/ConfigManager.txt may be of interest.

Please comment if you have any info about that, or anything I've mentioned so far. Please correct me if I've gotten anything wrong.

- Hunter K.

Read More

HandBrake Dependencies List

Update (8/24/10): I wrote this post a long time ago and the dependencies have changed quite a bit since then, so here's an updated list. I'll leave the old post untouched for posterity. These are intended for use on a Debian-based system and can be pasted into an 'apt-get install' command:

build-essential autotools-dev libtool libgudev-1.0-dev intltool autoconf yasm libbz2-dev zlib1g-dev libwebkit-dev libnotify-dev libgstreamer0.10-dev libgstreamer-plugins-base0.10-dev wget subversion python python-gtk2-dev

You'll need to add libdvdcss2 to this list to work with copy-protected DVDs.

Original post: Here is a complete list of dependencies required to compile HandBrake from source. This is mostly for my own reference for whenever I reinstall my OS, but hopefully others will be able to benefit from it as well since it's so difficult to find a complete list elsewhere:

autoconf
automake
g++
g++-multilib
gcc
gcc-multilib
jam
libgcc
libtool
make
makedev
yasm (or nasm if you don't care about cpu extensions)
zlib1g-dev
build-essential (if you're on Ubuntu or a derivative)
dpkg-dev
libdvdcss2

Once you have these installed, just navigate to your source directory, type ./configure, then jam. The build process takes a long time and downloads a lot of things for codecs etc. When it's finished, you'll have a binary called HandBrakeCLI in your source folder, which can be run from its current location or moved to wherever is most convenient for you.

Read More

Fix for Netatalk nbp_rgstr: Connection timedout error

So, I had been playing around with VMWare Server in my Gutsy installation and when I restarted, my Netatalk daemon was failing with an error: nbp_rgstr: Connection timedout.

Luckily, I found this old forum post, which had the solution: Just go into your atalkd.conf file and uncomment the line that says eth0.

I'll walk you through it:

Open a terminal, then type:

sudo nano /etc/netatalk/atalkd.conf

Then delete the # sign in front of the word 'eth0'. Pretty simple!

Apparently, netatalk will just bind to whatever network interface is laying around, so it can sometimes get confused and bind to the crippled one used by VMWare Server. This fix just tells it to look for eth0 from now on instead of picking one willy-nilly.

Read More

CPU-optimized Backend for gHandBrake

Edit: The original author of gHandBrake's site appears to be down and I haven't heard from him since I submitted code to add most of the advanced x264 options to the interface, so I decided to offer my updated version right here (64-bit binary plus source code) until further notice. If you need to compile it for a 32-bit system, I have a list of dependencies for HandBrake here, and precompiled binaries of Yasm Debian/Ubuntu systems here. If you have any problems with any of it, just let me know in the comments and I'll try to help.

You can also download the unmodified gHandBrake (fewer features, but more stable) here. This package includes both the source tarball and a precompiled 64-bit deb binary for Ubuntu/Debian users.

Original post: I've been trying out gHandBrake, the excellent new GTK frontend for HandBrake. It's very early in development, so it doesn't have many of the advanced options--such as advanced x264 options--implemented yet but it seems quite solid and will eventually be a great replacement for HandBrakeGTK/RippedWire, which is basically just an incomplete port of the Windows GUI (of note, HandBrakeGTK does not actually pass advanced x264 options to the commandline).

Unfortunately, the precompiled binaries offered by the author do not appear to utilize HandBrake's processor-specific optimizations, so I decided to offer an optimized 64-bit build of the backend that would:
Download link

To use it, just download and extract, then replace the old ghandbrake-backend with the newer version. In a console, you would type (assuming it was extracted to your desktop):

sudo mv -f ~/Desktop/ghandbrake-backend /usr/bin

Since switching to the updated backend, my average encoding speed went from ~40 fps to ~115 fps, but YMMV.

Of course, if you compiled gHandBrake yourself from source, you would already have the optimizations included as long as you had the yasm assembler installed when you compiled. If you want to go this route, I have a precompiled yasm binary that recognizes SSE3 instructions in my previous post.

Please leave me a comment if you have any questions or concerns.

Read More

HandBrake 0.9.2 and yasm 0.7.1 precompiled deb binary for 64-bit linux

Update (5/15/09): The binaries on this page are woefully out of date, but I have working binaries built from the latest code available in my PPA repository. Directions for adding it to your package manager are available here.

Download: HandBrakeCLI-AMD64 0.9.2 (Thanks Alexander!)
Download: yasm-AMD64 0.7.1
yasm-i386_0.7.1 (it's in a tarball, but the deb is inside)

I just got finished doing some building for HandBrakeCLI. They used to provide a precompiled 64-bit binary on the official site, but they've stopped for some unknown reason, so I decided to provide a copy of my own.

This binary doesn't need to be installed. Just navigate to the directory that contains it and type

./HandBrakeCLI

followed by any desired options (for more information on using the command line with HandBrake, visit the HandBrake wiki).

One of the biggest pains in compiling HandBrake (other than the lack of a comprehensive list of dependencies) is the fact that, to get the most out of HandBrake's processor-specific optimizations, you have to have the yasm assembler installed. Unfortunately, the version in Ubuntu's repos only supports instructions up to SSE2.

To correct this, I had to download and compile a newer version of yasm (namely 0.7.0) before I built HandBrake. Once I got that going, HandBrake recognized my cpu's extensions and accelerated the encoding speed to approximately 3.5-4x faster than the stock, non-yasm compile.

This binary should recognize any extensions present on my cpu: an AMD X-2 4000+ cpu, which has all the usual goodies up to SSE3 (so you fancy-pants core2duo users are out of luck on the SSSE3). Edit: A fella named Alexander was kind enough to supply a build with additional support for SSSE3 and Cache_64. Thanks Alexander!

My binaries include the original source code, which I have not modified. If you have any problems with them, please leave a comment or drop me an email and I'll see if I can correct the problem.

Read More

Hardy Never Worked, So I'm Back On Gutsy

As awesome as Hardy is, I could never get those damned random freezes I mentioned in my last post to stop, so I had to default back to Gutsy.

Fortunately, there were a few things I learned about integrating with Mac OS X 10.5 Leopard while fiddling with my Hardy install that are perfectly applicable in Gutsy, including screen sharing and networking with Netatalk.

Screen sharing was surprisingly easy to set up. Simply install xtightvncviewer from the repos:

sudo aptitude install xtightvncviewer

This should get make your Linux box accessible from your Leopard box, and you can also use it to control your Mac from Linux by typing into a linux terminal:

xtightvncviewer your.Mac's.IP.Here

You will likely have to enter some sort of password to gain access. There are also some command line options you can use to optimize your experience, which you can see by typing:

xtightvncviewer -help

If you plan on using screen sharing often from your Mac, you should consider adding a link to the program to your Dock. It's just a regular program located at /System/Library/CoreServices/Screen Sharing.app.

On to networking:

I had previously used Samba to network my Macs with my Gutsy/Hardy box because I had always heard it was the easiest method. This simply isn't true. All it takes to get things going using Mac-native networking is to bring up a terminal and type:

sudo aptitude install netatalk

If you're on Leopard, you will run into the issue of it not liking cleartext passwords, which the Netatalk version from the Ubuntu repos happens to use. To fix this, you can either do it the hard way: by recompiling a new version of Netatalk from source with a special option enabled, or you can do it the easy way: by jumping on your Leopard machine and open up a Terminal and type (all on one line, courtesy of a commenter at macosxhints.com):

defaults write com.apple.AppleShareClient
afp_cleartext_allow -bool true

Now Leopard will happily communicate with the standard Netatalk from the repos. As a word of caution: this method is less secure than the 'hard way,' but I just needed it for my home network, so it's not a big deal to me.

If you want shares to be accessible to your Mac from your Ubuntu box, you'll have to add them to the end of the file /etc/netatalk/AppleVolumes.default (ex. /media/sda1 at the very bottom of the file) and then restart netatalk by typing into a terminal:

sudo /etc/init.d/netatalk restart

Read More

Hardy Heron Headaches

Update:I've installed an alpha build of Intrepid Ibex, the next Ubuntu version after Hardy Heron, on a separate partition and I haven't had any weird freezes. I haven't given it as rigorous a test as I probably should, but it appears to be okay. This leads me to believe the freezes I was experiencing were caused by the kernel version that shipped with Hardy (2.6.24), which is known to be buggy and unstable on many systems. Intrepid, on the other hand, uses 2.6.27, which seems to be rock-solid. I believe you can manually backport the 2.6.27 kernel to Hardy using Prevu, an automated backporting utility, but my system was so buggy I doubt it would have made it through before it crashed... Instead, I intend to just wait another month or so and install Intrepid when it gets an official release.

I upgraded my HTPC from Ubuntu Gutsy Gibbon to the new version, Hardy Heron, a couple of days ago and it's been quite a headache, considering this is an LTS version. As a caveat, I have been using the 64-bit version, which is known to have more issues since it has a smaller user base.

First, I tried upgrading through the update manager, which was a dismal failure. I was sort of expecting that to happen, though, so I wasn't too put off.

Next, I burned an install disk and set to installing. From the start, the install window was grossly oversized for my monitor (an HDTV) so I had to spend a few minutes shrinking it down to a usable size. It wouldn't allow me to make it small enough to fit the screen, though, so I had to do a lot of scrolling during the install. After that admittedly minor hang-up, the install process went fine.

Upon reboot, I ran into my next problem: GRUB tossed up an error 22 when I tried to boot my system. However, I found that I could get it to work by going through a goofy song-and-dance of first selecting my Windows partition (which also failed to boot) then going back and selecting the Hardy partition again after Windows failed. Not the best solution, but whatever.

Once I booted up, I replaced my user folder with my backed-up user folder from Gutsy, which worked swimmingly. However, my storage drives (SATA, formatted to FAT32) were not automounted like they were in Gutsy, which was a bit disappointing. After some mucking around in /etc/fstab, however, I was able to get them going properly.

All was well for a few hours until I started getting random freezes. These weren't regular ol' crashed X-server freezes, either. They were hard freezes that killed the mouse/keyboard and wouldn't resolve without a hard reboot. I tried looking in my kernel log and didn't see any panics or anything like that, and they started getting closer and closer together, so I made the decision to wipe and reinstall.

This time around, I made myself a separate /home partition in case I ran into any more catastrophic issues. Again, the window was sized wrongly, but everything with the install was fine other than that.

This time around, I guess GRUB got its act together because Hardy booted on the first try without needing any coercion. I haven't checked my Windows partition yet, though, so it may still be borked.

The reinstall seems to have fixed my random freeze issue, but I ran into a really bizarre issue about 3 hours after finishing installing: my colors were all wrong (yellows were blue, etc.) during video playback but not on the desktop.

After some searching, it appears this is an old issue that may be related to proprietary binary drivers and may have something to do with gstreamer doing some sort of hue correction that is redundant with what the driver is doing with newer cards (I have a GeForce 8600GT). The solution for me for the most part was to open Totem and go to the preferences and set the Hue slider all the way to the left. However, I actually use VLC for my videos, so I also had to fix that program separately.

For it, I had to go into the Preferences>Video>Output modules and switch the Video output module from 'Default' to 'X11 video output'.

Not to knock the Ubuntu devs, though, because they have done a wonderful job adding new features and making a highly polished OS. In fact, I've had as many or more problems with my recent upgrade to MacOS X 10.5 Leopard. In my next post, I'll go over some of the fun I've had integrating the two systems in my home network.

Update: I believe I've tracked down the source of my random freezes, which have returned since my reinstall. I used my Leopard machine to ssh into my Hardy machine and just left top running as I went about my normal activities so whatever was displayed when the next freeze came along might tip me off to the issue. Apparently, smbd (the Samba file-sharing daemon) was spawning processes left and right, causing the system to become unusable and eventually freeze. I uninstalled Samba and it seemed to fix things up. Unfortunately, my server is pretty useless without being able to share files, so I set about installing Netatalk, the Apple filesharing protocol. Interestingly, *it* (in the form of afpd) began spawning processes like crazy and shortly froze up the system as well. It looks like I'm share-less until I can figure this out. If anyone has any ideas, feel free to leave a suggestion in the comments.

Read More