Julie & Julia

              What name else can I start my blog with? That was the name of the movie that inspired me, yes "Julie & Julia"… the most lovable movie I've ever seen, but we are not here to talk about movies actually, it’s all about food :)

  I Love food... and I LOVE cooking so much “saying that won’t make me fat :-j”. I've never thought that I would write about it. Many people told me to do it before, but I didn't have the courage, also my sisters have blogs, and they kept asking "why don’t you make one?!" I was thinking that it was just silly.

  Julie & Julia, not only a movie but also Julie and Julia are the most inspiring women in my life... cooking.. cooking.. cooking.. this “is” my life :).

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.

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.

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.

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.

HandBrake 0.9.4-3154svn (CLI and GUI)

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!

Beginner's Guide to SF4 Model Editing

Model editing is still being perfected, but it's currently possible with a few caveats.

First, download piecemontee's SF4 Assets Explorer. This is the cornerstone of model editing: http://sf4mods.pbworks.com/Utilities#piecemonteesSF4AssetsExplorer

Next, you'll need a 3D modeling program. I use the open source Misfit Model 3D because it preserves some coordinates and whatnot that seem to get dropped from other, more capable programs, such as 3D Studio Max (from what I hear from other modders; I have no experience with 3DS): http://www.misfitcode.com/misfitmodel3d/download.html

Once you have your tools, open the SF4 Asset Explorer and click 'Load file...'

Now, navigate to the costume file you wish to edit:

Click on the plus signs next to the path and the first entry marked "#EMB ([***]_01.obj.emo):

If you click on a model element, it will isolate it from the overall character model, like so:

Now, right-click on the element's name and select "Extract file...":

Name it something informative and give it the extension ".obj":

Next, open the file using Misfit Model 3D:

From here, you can move around vertices as much as you want, but you CANNOT add new ones or remove any. The number must stay EXACTLY THE SAME or you cannot re-inject it back into the model:

After you're finished editing, save the file and uncheck the option to "Save normals" (actually, I don't think this matters):

Now, back in the SF4 Assets Explorer, select and right click on the element you edited and choose "Inject file...":

Select your edited model and click "Open":

Now, when you refresh the model in the Asset Viewer, you will see your edits have taken effect:

The program will automatically create backups whenever you inject models, which is nice, but you should still be careful about overwriting because there is no "Undo." This edited model should now be ready to drop into your C:\Program Files\CAPCOM\STREETFIGHTERIV\Battle\Chara\*** folder to replace your old costume file.