الجمعة، 26 فبراير 2010

How to Run New Steam UI Beta in WINE

If you've opted-in for Steam's Beta user interface in Linux via WINE, you've probably noticed some serious issues, such as the main window not drawing properly on your desktop. Luckily, this is actually really easy to fix. All you have to do is go into your WINE configuration and change the Windows version from the default Windows XP to Windows Vista (or Windows 7, either one works):
Restart Steam and it will notify you that it needs to install a Steam component that requires administrator privileges. Click 'ok,' wait a few minutes, then start Steam again. Everything should begin rendering just dandy:
Everything I tried in the Library and Friends sections seems to work, including downloading and installing games, launching games, chatting with friends, etc. Unfortunately, the store, news and community features still don't show up properly :(

Also, in-game chat using the overlay appears broken in that the game hangs when you try to switch and you can't see what you're typing if you try to chat. However, alt+tab still works, so that's something.

As an added bonus, the 'minimize to system tray' feature works swimmingly:


Original post (for posterity):
I just opted-in for Steam's beta version of their fancy new user interface, which includes a number of improvements such as a greater focus on social interaction and switching from the Internet Explorer rendering engine to a WebKit-based renderer. I had assumed that this would grease the gears a bit on using the UI in Linux via WINE, but it has unfortunately done the opposite.

Now, if you try to launch the updated UI, the Desktop Switcher down in the bottom-right corner of the screen shows a big window with a Steam logo on it, but the window isn't drawn on the desktop as far as I can see.

This post is primarily a placeholder for anything I might find/come up with to correct the problem. So far, I haven't tried disabling compositing or anything like that, so that's next on the list. Feel free to leave me a comment if you have any clues to what's going on.

الخميس، 18 فبراير 2010

Quick batch tool for comparing encoding quality

I was pleased to come across a really handy Linux-native tool for analyzing video quality in a number of clips quickly and efficiently. It is known as 'qpsnr' and it was written by a nice fellow named Emanuel Orlani who posted it at the HandBrake forums.

The program is designed to take a reference file (presumably your original video source) and then compare it to any number of derivatives (e.g., a series of reencoded clips that were produced using different settings) to produce objective quality comparisons, outputted in either peak signal-to-noise ratio (PSNR) or structural similarity (SSIM).

This tool is perfect for individuals who like to tinker with encoder settings to find exactly what works for them. Now, instead of hunting through activity logs searching for quality measures, you can batch-encode a series of clips with your settings, then run them all through qpsnr and see what effect each setting had on quality.

It is only available as a source download at the moment, but the author suggested deb binaries will be posted after more testing is done. If not, I'll package some up in my PPA repository.

الثلاثاء، 12 يناير 2010

Beginner's Guide to SF4 Normal Map Editing

Street Fighter 4 uses relatively simple, low-poly models but adds detail using a special kind of image file known as a bump map or normal map. This normal map is rendered as small variations in depth of the model, either raised or recessed into/out of the overall model. Editing the normal map attached to a model will make any mods look much more complete.

To get started, download the normal map filter plugin for GIMP from this link. To install it, place the normalmap.exe file into your Program Files > GIMP-2.0 > lib > gimp > 2.0 > plug-ins directory. You will also need to install GIMP's DDS plugin (available here) if you haven't already done so.

Next, download Piecemontee's Asset Explorer from this link. You may have to install DirectX 9.0c (available from Microsoft) to get it to display properly.

Now, open the Asset Explorer and open both the *.cos.emz file you want to edit (notice the black and white lines representing raised/lowered areas; this is the normal map):
and the *.col.emz file for the color/mod you'll be using:
Next, navigate within the cos file until you find one or more DDS files. When you select one, it should look weird and purple. This is your normal map, which will correspond to the DDS files within the col file. Export it and name it something descriptive, such as 'chest normal map.dds' that you can use to identify it later:
Do the same thing with your col file so that you have a pair of DDS files, which will open in GIMP. First off, we should notice that the normal map DDS is higher resolution than the color DDS:
We need to change that, so we'll scale up the color DDS to match the resolution of the normal map DDS:
>
Next, if your color file is a little grainy, that will show up as texture, which we may or may not want (depends on the mod, really). To get rid of this grain, we'll use a Gaussian Blur filter:
>
Now, we're ready to create the normal map, so go into your filters menu and select Map > Normal Map:
At default, the normal map filter's scale is way too low, so we want to crank it up. I usually put it around 15, but this might be too much for some mods:
You'll just have to play around with it, checking your results in the 3D preview window, until you find a setting you like:
Once you're satisfied with the results, click OK to apply the filter:
Now, save your file using the same DDS characteristics as the unmodified normal map:
Go back into the Asset Explorer, navigate to the old normal map DDS file, and replace it with your newly created one:
Now, your model file should refresh and reflect your new normal map (notice the sunburst pattern on her stomach that wasn't there with the standard normal map):
Just follow these steps with each of the DDS files and normal maps and you should be all set.

الثلاثاء، 22 ديسمبر 2009

Testing Ubuntu 10.04 Lucid Lynx Alpha 1

The latest version of the popular Ubuntu Linux distro, known as Lucid Lynx, was just released the other day and, though it is an early alpha release, I wanted to give it a shot in a virtual machine. Installation in VirtualBox was smooth and polished, but I ran into some problems with installing VBox's Guest Additions, which allow for higher resolutions and, more importantly, mouse pointer integration (the magic that lets you move your cursor from host to guest OSs without mucking around with capturing the mouse pointer).

Here is a simple fix for the mouse pointer integration:

Fire up a terminal and type:
sudo gedit /etc/X11/xorg.conf
This file used to be how Ubuntu managed devices attached to your computer, but they're trying to move away from it. Now, the system will accept such a file, but it tries to figure things out on-the-fly as much as it can, hence the currently-empty file.

So, into this empty file, copy/paste:
Section "InputDevice"
Identifier "VBoxMouse"
Driver "vboxmouse"
Option "CorePointer"
EndSection
All this is doing is telling your virtual machine to look for the vboxmouse driver and use it. Now, when you reboot, you should have proper mouse integration.

However, if this somehow causes problems and you want to undo it, just type into a terminal:
sudo rm /etc/X11/xorg.conf
and then reboot your system.

To fix the small resolution, you just need to add another section to your xorg.conf, so type into a terminal:
sudo gedit /etc/X11/xorg.conf
and below the mouse section, paste in:
Section "Screen"
DefaultDepth 24
SubSection "Display"
Depth 15
Modes "1920x1440" "1920x1200" "1900x1200" "1920x1080" "1600x1200" "1680x1050" "1600x1024" "1600x1000" "1400x1050" "1280x1024" "1440x900" "1280x960" "1366x768" "1280x800" "1152x864" "1280x768" "1280x720" "1024x768" "1280x600" "1024x600" "800x600" "768x576" "640x480"
EndSubSection
SubSection "Display"
Depth 16
Modes "1920x1440" "1920x1200" "1900x1200" "1920x1080" "1600x1200" "1680x1050" "1600x1024" "1600x1000" "1400x1050" "1280x1024" "1440x900" "1280x960" "1366x768" "1280x800" "1152x864" "1280x768" "1280x720" "1024x768" "1280x600" "1024x600" "800x600" "768x576" "640x480"
EndSubSection
SubSection "Display"
Depth 24
Modes "1920x1440" "1920x1200" "1900x1200" "1920x1080" "1600x1200" "1680x1050" "1600x1024" "1600x1000" "1400x1050" "1280x1024" "1440x900" "1280x960" "1366x768" "1280x800" "1152x864" "1280x768" "1280x720" "1024x768" "1280x600" "1024x600" "800x600" "768x576" "640x480"
EndSubSection
SubSection "Display"
Depth 8
Modes "1920x1440" "1920x1200" "1900x1200" "1920x1080" "1600x1200" "1680x1050" "1600x1024" "1600x1000" "1400x1050" "1280x1024" "1440x900" "1280x960" "1366x768" "1280x800" "1152x864" "1280x768" "1280x720" "1024x768" "1280x600" "1024x600" "800x600" "768x576" "640x480"
EndSubSection
Device "Device[0]"
Identifier "Screen[0]"
Monitor "Monitor[0]"
EndSection
Important: Each of the lines that start with "Modes" should have all of the resolutions following it on the same line, and they should only include resolutions that your monitor can actually produce, so you might have to delete some of them (e.g., my monitor is a 20" that only goes up to 1680x1050, so I deleted all of the resolutions that were greater than this).

Again, if this causes any problems, you can either delete the section of the xorg.conf file or delete the xorg.conf file entirely and then reboot to get things back to the way they were.

Shared folders between the guest and host also appear to be broken at the moment, but I don't know what to do about it. Other than that, things have gone well for me. Compiz works fine and I have a fancy composite desktop with wobbly windows and true transparency.

الأحد، 29 نوفمبر 2009

Using Gizmo5 with Google Voice to call landline and mobile phones

I, like many others, pay a lot for home phone service, which is becoming increasingly obsolete with the ubiquity of cellular phones. In an effort to cut out this mostly needless expense, I decided to try and combine two free services, Google Voice and Gizmo5, to make and receive free calls with actual landlines and cell phones via my existing internet connection.

The concept works like this: when you sign up for a Gizmo5 account, they assign to you a free SIP number, which you can basically think of as an IP-based phone number. This is already pretty cool, but the catch is that only other IP-based phones can call this number, and that's where Google Voice comes in. Through this free service, Google will connect any number--physical or SIP--with any other number--again, physical or SIP. Once the initial connection is made (the hard part for Gizmo), Google steps out and you're left with a working SIP-to-landline call without a phone line and without paying a dime.

To get this sweet deal going, you have to have an account with both services, which could be the biggest stumbling block: Google Voice is currently in an invite-only, privite beta stage and Gizmo5 has stopped accepting new registrations after it was recently acquired by Google (existing accounts still work, though).

If you've managed to snag some accounts, though, and they are all set up (you've chosen a local phone number for Google Voice, Gizmo has assigned a SIP number, etc.) you're ready to get started.

First, open your Gizmo5 account in your favorite web browser and find your SIP number (it will have an area code of 747):

Next, open your Google Voice account and click on 'Settings.' Under the 'Phones' tab, click 'add another phone' to forward your calls to:

Name it something recognizable (I called it 'Gizmo'), type in your Gizmo SIP number into the second blank, and then select 'Gizmo' from the pull-down menu:

Next, we'll want to install the Gizmo5 client on our computer (you can also use the gizmocall web-based interface, but it is made in flash and feels a little kludgy). Go to Gizmo's download page and download the client program for your operating system. If you're using Linux (like me), you'll notice that this is a bit of a problem, as the links are all missing. Luckily, you can still download the deb installer file for Debian-based distros, such as Ubuntu, from a direct link. UPDATE: the Linux download page is back!

Once the client is installed and running, you can enter your Gizmo account information and login. You can also choose to configure the client to manage your IM accounts, but I chose not to.

From now on, calls made to your Google Voice number--which is accessible to normal phones, either landline or cellular--will cause your Gizmo5 client to 'ring.' That means we can now receive calls from normal phones on our computer! We can also make calls to normal phones, but the trick is to use Google Voice instead of Gizmo's built-in (for-pay) calling feature:

When you click 'connect,' Google will call your Gizmo client (you answer it when it rings) and then call the number you have entered, merge the two calls, and then step out, just like your own personal secretary:


Conclusions

This method is not a perfect replacement for a home telephone. It only works when you have internet access (the silver lining of which is that you can use it at Starbucks, your hotel room, etc.; anywhere with a broadband connection). More importantly, it doesn't provide emergency 911 access, so if your house catches on fire, you'll just have to watch it burn because the fire department won't be able to look up your information via your phone number.

Furthermore, this method may not work forever. Google has just purchased Gizmo, so things are sort of up in the air until they figure out what they want to do about the way the services interact. Hopefully, if anything changes, it will be for our--the users'--benefit.

There has also been speculation that Google is planning to fully integrate these services together and then make them run on a wifi-enabled mobile device (Android-based, of course). This will essentially create a mobile phone that only works within wifi, but that can make and receive calls to/from any other phone without the need for a carrier (no carrier means no contract, no fees, etc.). That is, a fully ad-supported phone powered entirely by Google services and software.

Google, if you're reading this with your all-seeing robot eyes, please make it happen as soon as possible.

الثلاثاء، 6 أكتوبر 2009

HandBrake Nightlies for Windows

Update (4/26/10): I will no longer provide these packages because the HandBrake devs are now providing real-deal official nightlies: http://build.handbrake.fr/

**These are UNSUPPORTED, BLEEDING EDGE builds of HandBrake. DO NOT ask for help in the HandBrake forums if you run into any issues with them. If you have a problem, ask it here and I will try to help. Otherwise, YOU ARE ON YOUR OWN.**

Additionally, these are not true nightlies because I won't be building them quite that often, but I plan to compile a new version each time a substantial update (such as an x264 bump) is checked into the SVN repository.

The CLI binaries are cross-compiled on my Linux box and the GUI is built natively in Windows.

الجمعة، 2 أكتوبر 2009

Cross-compiling HandBrake for Windows on an Ubuntu Linux Host

I wanted to use an up-to-date build of HandBrake on my Windows machines, but I am not comfortable building from source in Windows. Thankfully, the HandBrake devs recently switched over to a cross-compile-compatible build chain using MinGW, so it's possible to build Windows executables from my Ubuntu box.

To start, we'll download the standard HandBrake dependencies, which you would already have installed if you've built it on a Linux system before:
sudo aptitude install subversion build-essential m4 wget autotools-dev yasm autoconf intltool libtool libbz2-dev zlib1g-dev
Next, we'll download the MinGW packages, which will install a Windows-compatible build chain on top of your Linux system:
sudo aptitude install mingw32
Then, we'll pull down the latest code from the SVN repository:
svn co svn://svn.handbrake.fr/HandBrake/trunk HandBrake
Switch to the newly downloaded code:
cd HandBrake
Then get the build started:
./configure --launch-jobs=0 --cross=i586-mingw32msvc --launch
Things will chug along fine until the build script reaches the LAME library, at which point it will fail during the configure script with an error:
"configure: error: CHECK_TYPE_uint32_t - please report to lame-dev @ lists.sourceforge.net"
To correct this, we'll need to open the configure script in a text editor:
gedit build/contrib/lame/lame/configure
and then do a 'find and replace' to change all instances of this:
FILE *f = fopen ("conftest.val", "w")
to this:
FILE *f = fopen ("conftest.val", "wb")
After that, just go into your build directory and restart the build script (it will automatically remember that we're compiling for Windows):
cd build ; make
You'll have to do the same thing for libogg when it fails. Apparently, this problem is somehow related to autoconf... Once the script finishes, you should be left with a shiny new binary named HandBrakeCLI.exe!