Monday, November 28, 2011

Installing Linux Mint 12 on Lenovo x120e

Ubuntu has really been pissing me off lately with the whole GNOME 3 / Unity desktop hokey pokey so I decided to test the waters with some other options. After trying and rejecting some alternate desktop packages within the Ubuntu ecosystem, I decided to try the newly released, Ubuntu-derived Linux Mint 12.

Installation

Since my computer (Lenovo ThinkPad x120e) doesn't have an optical drive, I downloaded the Linux Mint 12 CD (64-bit) release image and used Ubuntu's "Create a USB startup disk" utility to write it to my flash drive. However, when I tried to boot from it, it kept failing at the bootloader with an error that I can't quite remember (I'll try to reproduce the problem, for search indexing's sake).

I installed the unetbootin package, though, and it created a working drive on the first try. Once I booted into the Mint live system, installation proceeded smoothly and identically to a normal Ubuntu install.

First Impressions

Upon rebooting into my shiny new installation, the restricted driver manager popped up and acknowledged my Broadcom wireless card and Radeon graphics. The wireless drivers never kicked in, though, and the graphics displayed text wrong in the panels and menus (some letters and words were a scrambled, garbled mess).

The lack of wireless *and* a proper graphics driver was a definite deal-breaker for me, so that's where my first experience ended. I hope to give it another shot soon, so I'll update this post if I have any better luck.

UPDATE (12/05/11): I switched over to Linux Mint Debian, which is a rolling-release version based on Debian Testing. Again, installation was successful and fast. Debian doesn't have some of Ubuntu's noob-friendly utilities, such as the 'Additional Drivers' (jockey) utility, so you'll have to manually install the fglrx-driver package and then configure your /etc/X11/xorg.conf file to get accelerated graphics. There is an automated tool, aticonfig, that you can use to configure your xorg.conf. The following command will install the fglrx driver and the helper libraries to get accelerated video decoding, then invoke the aticonfig command to automatically configure your xorg to use the new driver (Thanks Erik!):

sudo apt-get install libva1 libva-x11-1 libva-tpi1 libva-glx1 libva-dev xvba-va-driver fglrx-atieventsd fglrx-control fglrx-driver fglrx-glx fglrx-glx-ia32 fglrx-modules-dkms
Thankfully, Mint Debian had none of the aforementioned weird rendering issues with the proprietary driver, and Compiz worked just fine (I installed the fusion-icon package so I could turn it on and off more easily).

UPDATE (12/30/11): Erik notes:
I went back to the open source drivers....
They seem to work much better for watching flash movies. For Youtube I use the FVR Flashvideoreplacer addon. The other websites are better with the open source drivers then with fglrx.
So, if you watch a lot of Flash video (youtube, Hulu, etc.), you might be better off sticking with the default, open source drivers, buy YMMV, so be sure to try both.

I have not yet been able to get my Broadcom wireless working, but I'll try to update this post if/when I get it figured out. If you are fortunate enough to have chosen the other wireless chipset, you should be fine out-of-the-box.

Saturday, November 19, 2011

Advanced RetroArch Configuration Options

Update (4/23/2012): SSNES has changed its name to reflect its versatility beyond SNES emulation. The new name is RetroArch and this article has been updated to reflect the change.

This guide picks up from where the basic guide left off, so if you haven't read it yet, you should.

In the main window, you can choose whether to save a BSV movie, which is basically a small file that logs all of your keypresses when you play. You can later take this file and replay it back like a sort of movie. This can be used to share your gameplay with others without the necessity of passing around gigantic files.

Below that, we have FFmpeg movie output, which allows you to dump actual video files using state-of-the-art, lossless RGB x264 with FLAC audio. The files can be quite large, but are appropriate for high-quality recording for things like speed runs. Currently, only *.mkv files are supported, so if you want to use this feature, make sure your file name ends in mkv. This feature can be used in conjunction with BSV playback to simplify recording speed runs, etc.

General

At the top of the main window, you'll see a menu labeled Settings. From there, click on General, and it should open a window that looks like this:
The first entry, Enable rewind, is what toggles on the ability to use real-time rewind, similar to what you find in the popular indie game Braid.

The next few options are for special use cases and can generally be ignored (the defaults are usually fine).

The next option I want to point out is Records filtered output, which will make the aforementioned mkv video dumps capture the image *after* filters (but not shaders) are applied, so your video will look as fancy as what you see on your screen. Below that, you have fields to load XML cheat databases, such as those used in bsnes, and below that you have some entries to specify paths for various additional files, such as save data and screenshots, that RetroArch creates. If left blank, these will default to the folder the ROM is loaded from.

Video
From here, you can choose your desired video driver. For most people, OpenGL (the default), will be fine and I will assume that's the one you'll use for the remainder of this tutorial. However, if OpenGL doesn't work for you, you can choose the slow and crappy (but reliable) SDL driver, or the D3D driver (not available in Linux, of course).

Windowed X and Y scale let you set custom sizes for the emulator window, while Fullscreen X and Y resolutions let you set custom resolutions in fullscreen (leaving it at 0 will attempt to scale the window as large as possible).

Checking VSync will cap your framerate to your monitor's refresh rate (a good thing, or else the emulator will run as fast as it can...).

Start in fullscreen is self-explanatory, and you probably want to leave Force 16-bit color turned off.

Disable composition (Win Vista/7) will automatically turn off Aero transparency, which can conflict with VSync in windowed mode (makes video stuttery), but doesn't affect fullscreen.

Bilinear filtering will add a slight blur to the image to take the edge off of the hard pixel edges (also known as smooth video in some emulators). This option has very little impact on performance.

Lock aspect ratio will ensure that the image is always a given aspect ratio (default is 8:7, assuming square pixels). You can also enter a custom aspect ratio (in decimal format, such as 1.333333 for 4:3 assuming non-square pixels) in the window next to the Aspect ratio entry farther down.

Crop overscan cuts off a few pixels around the edges of the image that were customarily left blank by developers and sometimes contain garbage pixels.

Below that, we have Shader/filter settings, which opens the advanced shader and filter settings window, and at the bottom we have Font settings which opens the advanced preferences for the onscreen text display.

Shader and Filter Settings

This is where RetroArch gets its bling:
The first entry, Cg pixel shader, allows you to load pixel shaders in Nvidia's Cg format. Below that, you can load bSNES XML shaders (deprecated in bsnes with v083, but RetroArch still supports them). The Cg shader format works with both OpenGL and D3D drivers, which is nice, but the selection is more limited than with the more common bSNES XML shaders.

The XML shader directory option allows you to select a folder that contains XML shaders that will be loaded in sequence when you press the assigned hotkey.

Checking the box by Render-to-texture (2-pass rendering) allows you to "stack" an additional XML pixel shader for additional effects. If you enable this, the FBO X and Y Scale fields allow you to specify a scale factor for the first-pass pixel shader. This often doesn't make a huge difference, but it can help with certain shaders that are intended to be calculated at a specific scale, such as HQ2x. Bilinear filtering (2. pass) applies the same slight blurring as before, but this setting ensures that you have fine control over how much blurring occurs and when. Finally, the Shader (2. pass) field is where you select the desired shader for the second pass.

The last field, bSNES video filter, allows you to apply CPU-powered filter libraries from bsnes (like XML shaders, they were deprecated in bsnes as of v083, but RetroArch still supports them), such as blargg's kickass NTSC filter.

You can download a number of Cg shaders from my Mediafire Cg repo, while XML shaders can be downloaded from Screwtape's XML shader repo and/or my Mediafire XML repo.

This page has preview pics for most of the XML shaders and a link to Themaister's WebGL shader testing applet.

You can download bsnes video filters for Windows here (32-bit) and here (64-bit) and for Linux here (32-bit) and here(64-bit).

Font Settings

With the On-screen message font entry, you can load a custom Truetype Font for RetroArch to display onscreen, while On-screen font size specifies the font size in points.

Enable on-screen messages is pretty self-explanatory. Uncheck to disable onscreen messages from  RetroArch.

On-screen message pos lets you specify custom X and Y axis positions for onscreen text, and Message color (RGB hex) determines the the color of the text in hex format. You can use an online color picker like this one to get your desired color in the proper format.

Audio


The first option is self-explanatory. Uncheck it to completely disable audio.

Audio driver is also pretty straightforward. DirectSound is usually the most compatible in Windows, but XAudio2 has lower latency and is often less buggy. In Linux, ALSA is what I use, but many speak highly of OSS.

With the External audio driver option, you can choose a custom driver that conforms to the RetroArch plugin API, but the only one available at the time of this writing is Themaister's experimental WASAPI driver. Below that, you can specify an Audio DSP plugin, which can potentially provide reverb and echo effects, etc. Mudlord has written a few of these, which even come with a fancy Qt GUI.

Audio sample rate should be set to match your computer's sound card output rate, which is usually the default 48 kHz.

Audio input rate can be confusing at first but is awesome once you get it set up (like RetroArch itself :P). Basically, as the emulator chugs away, it creates video frames at a rate of 60 per second and audio at an ideal rate of 32,040 samples per second. However, modern LCD monitors rarely have a true 60 Hz refresh rate, so, when displayed with VSync enabled on such a display, the audio and video will get faintly out of sync and cause either a video frame to drop (manifested as a stutter in the video) or a crackle in the audio. The default value of 31,980 is a closer match to modern display refresh rates than the ideal rate, but you can nudge it higher--if your video still drops frames occasionally--or even lower if your audio continues to crackle.

Audio rate step specifies the granularity at which the audio rate increases or decreases when you press the corresponding hotkeys.

Dunno what Audio device does.

Audio sync is similar to VSync in that it keeps the framerate in synchronization with the audio. Keep it checked for best results.

Audio latency (ms) is pretty self-explanatory. The default value is usually fine.

Input Settings

The Input settings window is where you can assign buttons and/or keys.

The slider at the top, labeled Input axis threshold, determines at which point an analog control will register as a digital button-press.

Below that, you can choose whether or not to use Player 1 button/key assignments during netplay regardless of whether you're hosting the game or connecting to someone else.

The pulldown menu below that lists the categories of keys you can assign, including all of the available controller slots from Player 1 to Player 5 and the miscellaneous RetroArch functions, like rewind. You can bind any of these functions by double-clicking on its entry and then pressing the appropriate key when prompted.

Last, the Detect analog checkbox determines whether analog inputs are even polled.

Netplay

Netplay is one of RetroArch's crown jewels and can be enabled via the main RetroArch-Phoenix window. We'll cover its configuration first and then go over some of the quirks you should be aware of.

If you check the box to enable netplay, you must specify whether you will be hosting (server) or joining (client) the game. If joining, you must also enter the host's IP address in the field below. Make sure your firewall is open on port 55435 (default; you can change it if you like) and that the port is forwarded in your router, if applicable. You can also specify 'spectator mode,' which will allow an arbitrary number of spectators to join and watch you play without being able to play themselves.

Delay frames denotes the maximum number of frames RetroArch will need to emulate at once to maintain synchonization due to actual network latency. You can figure out an appropriate ballpark for this number by pinging the other player and dividing the time (in milliseconds) by 16 (roughly the number of milliseconds in a frame from a game running at 60 fps).

Similar to the GGPO platform, RetroArch creates a constant stream of savestates which, along with button presses, are exchanged and compared between the server and client machines. If the savestates start to diverge, the game rolls back in time to a point where they both agree and then emulates the missing frames all at once to get back to the appropriate spot. This gives the illusion of completely lagless inputs, which is invaluable for twitchy, fine controls, such as parrying in Street Fighter III: Third Strike.

The downside to this method is that sound is almost always crackly and it can sometimes create odd time-rollback isues (hard to explain, but you'll know them when you see them ;P). It also produces occasonal spikes in CPU utilization as the emulator needs to emulate a series of frames all at once to catch up after a rollback.

If the gameplay is a bit choppy, try increasing the number of delay frames a bit. If you try to connect to a server and it immediately says client disconnected, open your log and make sure your ROMs match exactly (it will complain about a hash mismatch otherwise). If it gives you a weird time-out error, just close the window and try to connect again and it should work itself out (sometimes excessive spikes in network latency can cause the states to diverge catastrophically, resulting in this error).

It is also important to note that netplay does not work with all libsnes implementations. Known working implementations include snes9x (and the -next variant) and FBA's CPS3 driver (e.g., for SFIII: Third Strike). Other implementations may work, but you'll have to try them yourself (please leave a comment with your experiences if other implementations work/fail). Often, RetroArch won't show a disconnection if things desync during netplay and will instead show either a non-moving second player, or his/her behavior will be weird (like jumping into holes, running into enemies, etc.).

Getting Started with RetroArch

Update (4/23/2012): SSNES has changed its name to reflect its versatility beyond SNES emulation. The new name is RetroArch and this article has been updated to reflect the change.

RetroArch is a multi-platform multi-emulator with support for some really cool, unique features, including extensive shader and filter support, real-time rewind, lossless video dumping, advanced "lagless" netplay, and more. Unlike many other emulators, RetroArch is under rapid and active development and receives new features on a regular basis. However, all of these esoteric options and capabilities can be daunting to new users, so this guide will cover the basics. The instructions are primarily geared toward Windows users, but the configuration information is essentially the same on any platform.

So, first off: RetroArch is all about modularity, so we need to download a couple of initial modules, namely the RetroArch executable and its helper libraries. To get started, go to the RetroArch homepage and download the RetroArch full package that suits your system (the 'x86' build will work on all machines, while the x64 build will only work in 64-bit versions of Windows; get the x86 version if you don't know which is appropriate for you). The slim package contains the absolute minimum required for bare, no-frills emulation, while the full package is prepared to utilize RetroArch's many advanced features.

Once your download finishes, extract the zip file, navigate to the extracted RetroArch folder and look for retroarch-phoenix.exe. This is the graphical user interface (GUI) module that will help us get RetroArch set up and configured. Double-click it and you should see a window that looks like this:
Along the upper edge of the window, open the RetroArch menu and select Update RetroArch:
It should open a window that looks like this:
You can use this tool to automatically download updates for RetroArch, its helper libraries and any/all of the various emulation cores. First off, you'll need to select which flavor of RetroArch you're using--x86 or x64 (aka x86_64)--by clicking on the appropriate bubble next to CPU.
Then, click on the button labeled Check version. This will search for updates to RetroArch and/or its helper libraries and populate the list of available emulation cores:
After that, click on the bubble labeled Redist and then the button that says Download RetroArch. This will fetch any updated RetroArch executables, as well as fresh copies of all of the helper libraries (you can update RetroArch without the helper libraries by using the Full button instead of Redist).

At this point, you can also automatically download any of the cores in the list by double-clicking on its entry. After the download finishes, it will ask if you want to use the core. Whether you do or not is okay, as we'll be specifying our desired core in just a few seconds anyway.

Once you're done downloading cores (you can come back to this menu and download more cores at any time), close the Updater window and return to the main window, where we'll need to configure some options.

Starting from the top, the Normal ROM path is where you select the ROM you want to play. It will not hide inappropriate files, so make sure you pick the right one for the system you wish to emulate ;)

Next, we need to tell RetroArch where to store and load its settings, via the RetroArch config file path. Click Open, and then navigate to your RetroArch folder and choose the file named retroarch.cfg. Likewise, for RetroArch path, click Open, navigate to the same folder and select retroarch.exe.
Finally, the Emulator core path lets us select which emulation core we wish to use. So, click Open, navigate to the RetroArch folder and look for your desired core that you downloaded from the Updater, such as gambatte-0.5wip1-x86_64.dll in my case. RetroArch can be paired with any emulator core that conforms to the libretro API specification, including but not limited to the original libretro (previously known as libsnes) derived from byuu's bsnes.

At this point, simple emulation should be functional, so go ahead and try it by clicking on the big button labeled Start RetroArch. If it works, congratulations! You're ready to play. Check out the advanced configuration options to learn about filters/shaders, netplay, rewind support and more.

If it doesn't work, click on the File menu at the top of the window and select Show log. This will give you some information on why it failed. If you seek help at the RetroArch forums or in the RetroArch IRC channel, be sure to have this information handy, as it will help others solve your problem.


If you would like to explore some of RetroArch's more advanced features, check out this guide.

For Linux Users

If you're using a Debian-based distro, such as Ubuntu or Mint, you can use my PPA repo, where I package a number of emulators, including RetroArch and all flavors of libretro. To install RetroArch, open Synaptic Package Manager and add ppa:hunter-kaller/ppa to your software sources. You can then install any of the packages through your normal installation procedure of choice.

Otherwise, configuration is just like in Windows, except your retroarch.cfg file is initially installed to /etc/retroarch.cfg (but can then be copied to and overridden by any retroarch.cfg file located in ~/.config/retroarch/) and the emulation cores install to /usr/lib/.

Wednesday, October 5, 2011

Using sloth86's Ambient Occlusion Tools in SF4

In the course of making skins for SF4, you might have toggled off an unwanted model, such as Chun Li's spiked bracelets, only to find an unsightly darkening, similar to a shadow, where the object used to be. This darkening is part of what's known as an "ambient occlusion (AO) map," which is used by the game to fake some self-shadowing by the models and thus reduce the amount of shadows your computer needs to draw dynamically to look realistic. However, once the offending model is gone, the AO isn't really appropriate anymore, so we need to do something about it.

For this tutorial, you'll need to download some of sloth86's tools: AOExtractor, AOInject and EMG Swapper, as well as piecemontee's Asset Explorer (aka, SF4Viewer). You'll also need a paint program that can view/edit EPS files, such as Photoshop. UPDATE (6/20/2012): the links for sloth86's tools are dead. You can now get the AO tools here and the EMG Swapper here.

Once you have your tools, open your desired costume file (*.obj.emo) in the Asset Explorer. I'm going to be using Chun Li's default costume (CNL_01.obj.emo):













As you can see in the picture above, I've already toggled off her 'Ring' model, which has left the visible AO darkening on her 'Skin_arm' model, which I intend to fix.

So, next we'll want to select that darkened model, right-click and choose 'raw dump' to get the raw EMG model. Name it something informative with the .emg file extension and click 'save.'

While we're here, take note of which EMG model we're extracting, counting from the top. For me, it's the 10th one. We'll need this information later, so write it down or something.

Next, open the AOExtract tool. You should see a window like this pop up:







In the first field, put in whatever you just saved your dumped model as. In my case, 'skin_arm.emg.' The other options can be left at the default values, unless you just feel like changing them. (Subdividing triangles will make your EPS file look a little nicer, but it takes longer and is unnecessary)

Click 'Extract' and you should end up with a new file, in my case 'new.eps.'

Open your new EPS file in Photoshop and you should see something like this:













Those triangles you see correspond to the triangles used to make the model (just like the UV map, if you're familiar with those). As you can see, some of them are particularly dark, while others are lighter, just like we saw in the Asset Explorer window.

So, using the dropper tool, pick a medium color (we don't want a dark shadow, but we don't want it all bright like a highlight, either). If you're familiar with using hex color values, EFEFEF is a pretty good, generic match.

Once you have your color, you can either use the paint bucket tool to change each triangle by hand, or you can just paint over the whole thing, like I did.

Once you're all finished, we need to 'Save As...' and choose the bitmap (BMP) format, with OS/2 compatibility, 24-bit and no compression.

Next, open the AOInject tool. You should see a window like this:







In the first field, enter the name of your dumped EMG model, in my case, skin_arm.emg. In the second field  enter the name of our modified, blank AO map, in .bmp format. The third field can keep its default value.

Click 'Go' and you should be left with a new EMG model that we can view in the Asset Explorer:











As the pic shows, it's all one uniform gray color, instead of having light and dark areas.

Great!

However, now we need to actually get this unshadowed model back into our character model. For this, we turn to the EMG Swapper tool.


Open it up and you should see a window like this:








In the first field, enter the name of the character model you're working with, in my case, CNL_01.obj.emo. In the second field, enter the number of the model we're replacing (remember the thing we wrote down earlier??), in my case it's number 10. In the third field, enter the name of your modified model (the one we injected the new AO map into), in my case 'blank.emg.' The last field can be left with the default value, unless you want to name it something else.

Click 'Go' and you should be left with a new EMO file, which we can view in the Asset Explorer:













Our model fits right in and doesn't have any messy shadows for nonexistent objects anymore. Mission accomplished!

Unfortunately, you can see that her hands still have darkening, which creates a seam next to our modified object, but using your newly found AO mapping expertise, I'm sure you can fix it on your own. ;-)

That's it. Good luck, share your work and ALWAYS MAKE BACKUPS!

Monday, September 26, 2011

Pixel Shaders in Genesis, GBA, GBC Emulation

If you've looked at any of the amazing pixel shaders available for bsnes, such as the collaborative CRT shader from cgwg and DOLLS or Themaister's dot-n-bloom, you may have wanted to use them with other systems, such as Sega Genesis or Gameboy Advance. Well, now you can! Update (10/03/2011): now it works with Final Burn Alpha, as well. Update (10/5/2011): I'm adding download links for Windows binaries of the various libraries, when possible.

Themaister wrote some "hacky" wrappers around Genesis Plus GX, Visualboy Advance and Gambatte that route their APIs to match up with that of libsnes. That means any frontend for libsnes, such as Themaister's own SSNES, can now serve as a frontend for these excellent emulators. Thus, any features of the frontend, such as SSNES' real-time rewind and FFMPEG-powered video dumping capabilities, get baked in automatically. This also extends SSNES' badass GGPO-style netplay to all of these systems (where applicable, of course).

If you're using Ubuntu or another Debian-based distro, you can get precompiled binaries from my PPA repo. Other *nixes can compile them from source. The only dependencies are git (not even totally necessary if you manually download the source via http), a compiler that supports C++98 or higher (gcc-3.4 and up, IIRC) and zlib (in Debian-based distros, it's the zlib1g-dev package).

So, open a terminal and type:

For Genesis Plus GX:
git clone https://github.com/twinaphex/genesis-next
cd megadrive-next/src/libsnes
make

Download Windows libsnes-genesisplusgx binaries
(you may need to rename zlib.dll to libz-1.dll for it to work)

For Visualboy Advance (vba):
git clone git://github.com/Themaister/gba-next.git
cd trunk/platform/libsnes
make

For Gambatte:
git clone git://github.com/Themaister/gambatte-libsnes.git --branch libsnes
cd gambatte-libsnes/libgambatte/libsnes
make

For Final Burn Alpha (fba):
git clone git://github.com/twinaphex/fba-next-slim.git
cd fba-next-slim/src/burner/libsnes
make

Download Windows libsnes-fba binaries

The resulting libraries will all be called libsnes.so. In my packages, the libraries are named according to the emulator (libsnes-*.so) so you can have them all peacefully coexist.

One thing to be aware of: SSNES-Phoenix's file browser will filter out non-SNES extensions, so you'll have to manually type the filenames unless/until Themaister does anything about it.

Screenshots (dot-n-bloom shader is used for the GBC and GBA screenshots, CRT is used for Genesis and FBA):


Monday, September 19, 2011

SSF4AE - doshu's ULSM Tutorial

Here's a more or less basic tutorial about how I built my Ultra Light Stage mod. The aspects that I won't cover are basic Gimp/Photoshop manipulations, building your own BGM selection and how to convert a TRN stage to any other stage. If need be, those aspects can all be learned quickly either by reading the SSFIV/AE wikis, by searching the net, or simply by thinking on your own and doing try/errors.
Also, the first part of the tutorial is way more detailed (both in text and pictures) than the last ones, since I wrote it a while back to explain how the Training stage edit works on the polycount forums.

Since I build my mod, a lot of progress has been made in the field of custom Training stage's templates, so instead of blindly followind this tutorial entirely, you should probably just take the parts you need and try to build even better stages than I did (not so hard IMO :p).

Finally, I have to insist that I'm (or was) a total n00b in modding, and that this tutorial might include some really weird and/or not efficient methods for expert modders. I'm repeating myself here, but better safe than sorry^^. Anyway, if you have a better way of doing things, share it! This tutorial will then hopefully be updated ;).

Ok, let's start with an overview of the needed tools (find those in the wiki and/or with google) :

  • SF4 Assets Explorer
  • The Gimp + dds mod
  • SFIVAM
  • hexadecimal editor HxD
  • Ryu's Classic Training Stage mod by hunterk
Quick overview of the whole process :
  • extract Ryu's Classic Training Stage's dds and observe how it's made
  • build your own dds from whatever art you find that seems fine (but do not forget to get the author's authorization if you want to share your work!)
  • do the hex magic
  • inject the dds : the stage is done!
  • build the 3 preview pics'dds : big, medium and small size
  • build the 2 kind of presentation text : Stage Select and pre-versus screen
  • inject the whole thing into the appropriate files
  • mute that annoying announcer !
  1. Building your own stage
    1. Basic explanations
      Ok, so here's a bit of explanation on how it works. As you'll see, it really needs only basic picture editing skill, and not anything fancy.

      First, let's look at the "cube" limitations : the edges (this stage was done by hunterk).
      [IMG]

      As you can see, all the vertical sides of the cube are filled with the same part of the texture, making it "loop" when it reaches the end. The same with the floor/ceiling. In practice, it doesn't show that much, except when performing some Ultra's like Ryu's Metsu Shoryuken.
      But what is important here, is that because of that loop, the more the left and right sides of the texture looks alike, the less it will be apparent in the stage. In this case, it's almost "invisible".
      Secondly, here's the kind of file the stage's texture is made of:
      [IMG]

      Basically, the "floor" part is upside, then comes a thin black line, and the the main background. What is important here for "good" results, is that the floor looks as much as possible like one, as it does from all the above examples (and in the WIP preview screenshot). If the original jpg image's "floor" isn't "straight", or is filled with different objects and such, the result might be awkward (or not, it depends).

      For example, let's first show the results from the 2 pictures above:
      [IMG]

      All in all, except the crappy resolution problem, those stages look "good" : the floor is “floory”, and the edges of the texture look alike, so it should be pretty "invisible" while playing.

      Let's finish the basic explanations with a "difficult" file to work from (at least for my skills)
      [IMG]


      That's it for the basic explanations.
    2. Choosing some art and building a dds from it
      Basically, you'll want to work from a picture as high def as possible, even if the dds will only be 1280*800. Also, the scene should ideally be pretty empty in the “front”, thus allowing you to easily build the floor of your stage. It is possible to work from more difficult material, but I'll leave it to you to find how, explaining it here would be long and tedious.

      For my part, I worked mostly on feeling. Just look at the picture, copy whatever part you want to make the floor of without thinking too much about proportions, copy and paste it as a new image, then resize that new image at 1280*237. That's pretty much it for the floor.
      Return to the original picture, select the other part of it (Ctrl-I should do the trick if your previous selection was still active), copy paste as new image, then resize to 1280*553. That's it for the wall.
      Create a new black backgrounded 1280*800 image, copy paste the floor into it, position it up (using the arrows make it a breeze to do, no pixel precision needed). Do the same for the wall, except you position it down. There should be around 10 pixels left black in between.
      Flip the image horizontally (Image → Transform), then save as a .dds (just name the file whatever .dds when saving). Don't bother about the compression, it's not needed.
      Before injecting the newly created dds file, you need to make it the exact same size as the original one. To do that, just open both the original and the new dds file into your hex editor, and do the following :
      - on the original file : Ctrl-A ; End ; Ctrl-E ; choose 2EE080 ; Ctrl-C
      - on the new file : Ctrl-A ; End ; Ctrl-V ; Ctrl-S

      That should do the trick. Basically, you're copying what bytes are missing in the new file from the original one. All the files I created were always 2EE070 sections long, that's how you get the 2EE080 number. Should your file be a different size than that, you will have the adapt this number to that size so that both files are the same size at the end. This method doesn't work with new files bigger than the original though... (see how I'm a n00b in hex editing? Pretty n00bish I must admit, but it works! I have an idea why it does work, but I'll gladly hear some real explanation^^).

      A last word about applying filters on the dds befrore injecting it. The ingame look of the stage you built won't be exactly the same as the dds' look, so you might want to try and apply some filters. Here are the ones I used so far:
      - unsharpen: used mostly for high definition material, like most of the stage of the ULSM. I used it twice on each dds.
      - cartoon: used in combination with "Van Gogh" to make low definition material look ok-ish ingame
      Don't hesitate to try other filters too!

      Ok, you're good to inject to file into the .emz and test out your newly build stage!
  2. Editing the Stage Select screen
    [IMG]
    This part is really easy, but quite time consuming. I'll first specify the particularities of each kind of file needed for the Stage Select screen (dds resolution : actual picture resolution (ratio) / type of compression needed):
    - big preview picture: 1024*512 / 710*377 (1.88) / BC2/DXT3; the BLD stage needs a 1024*1024 resolution file (adapt the actual picture size accordingly)
    small preview picture: 128*128 / 116*89 (1.30) / BC1/DXT1

    Then the pre-versus screen:
    - medium preview picture: 512*256 / 336*214 (1.57) / BC1/DXT1; BLD, KOR, AFX need a 256*256 image, adapt the actual picture size accordingly

    And for the text in both screen (up left for the Stage Select screen, up right for the pre-versus'):
    - 256*128 or 512*128 / Comic Sans MS Bold 34 (Place) and Arial Bold 36 (Stage name) / BC2/DXT3

    To avoid you the pain of figuring out which stage's text needs which resolution, here's the list of the stages needing a 256*128 dds: AFR, RVR, AFX, VIE, JPN, VCN.

    Another time consuming task is figuring which files you need to edit, so here's the list:
  • \ressource\ui\stage_select\stage_select.emz: for every big/small preview picture and Stage Select screen's text. Finding the small ones is easy, since the entry name corresponds to the stage name. The big picture/text is much more difficult to find, so here's a list to help you out (pic/pic/txt/txt; I guess you have to inject the new pic and text twice, in both entries, I haven't tried to do it at only one place...):
        • BLD: I30 / I3E / I8A / I98
        • IND: I33 / I41 / I8D / I9B
        • KOR: I36 / I44 / I90 / I9E
        • AFX: I39 / I47 / I93 / IA1
        • LBX: I3C / I4A / I96 / IA4
        • USA: I3F / I4D / I99 / IA7
        • CHN: I42 / I50 / I9C / IAA
        • RUS: I45 / I53 / I9F / IAD
        • BRA: I48 / I56 / IA2 / IB0
        • AFR: I4B / I59 / IA5 / IB3
        • VIE: I4E / I5C / IA8 / IB6
        • JPN: I51 / I5F / IAB / IB9
        • EUR: I54 / I62 / IAE / IBC
        • SCO: I57 / I65 / IB1 / IBF
        • JPX: I5A / I68 / IB4 / IC2
        • LAB: I5D / I6B / IB7 / IC5
        • RVR: I60 / I6E / IBA / IC8
        • VCN: I63 / I71 / IBD / ICB
        • CNX: I66 / I74 / IC0 / ICE
        • BRX: I69 / I77 / IC3 / ID1
        • VNX: I6C / I7A / IC6 / ID4
        • TRN: I6F / I7D / IC9 / ID7
  • \ressource\ui\versus\versus\img#.emb.emz, where # is between 0 and 3: for everything pre-versus screen related. The entries are self explanatory, with JPN_name for the text part, and stage_JPN for the medium preview picture. Just take a look to find out which stage is where (the text and the picture entries can be in different files). Also, img3.emb.emz contains Boxer's name, so if you're using a JPN character's name mod, be sure to swap the original (Balrog) with is counterpart (M. Bison, to be found in some other file).
And finally, though I won't go through the hassle of explaining Gimp's image editing manipulations (a small hint about it though, be sure to use the game's original files as models for the shapes, especially for the small preview image; that way the result will fit perfectly into the game's screen), I'll throw a word about the halo thing around the text.
At first, I followed this tutorial. The result was good, but I came around a faster and better looking method after a while: follow all the steps until before applying the first Gaussian filter, then do a select all (CTRL-A), and apply directly a 10 point Gaussian filter. That way, you only have to apply one filter with one setting, removing the need to change the settings from 5 to 10 points every time. Finally, just follow the end steps of the linked tutorial.

Ok, now you're set, all that's left is to inject all of your files one by one into the game's files. A long and boring process if you're doing every stage at once, but the result is really worth it!
One last word about this part of the process: don't pay attention if the SF4 assets explorer preview looks messed up, it doesn't affect the in game result.
[IMG]

  1. Mute the announcer
    This is quite easy:
  • open \ressource\ui\sound\se\VERSUS_SE.csb with SSFIVAM
  • extract everything in a temporary folder ("unpack" command)
  • hexedit the files containing the sounds you want to delete by selecting all and replacing the data with zeros (listen to the files in AM beforehand, to found out the name of the sounds you want to delete)
  • then inject all the files inside the original file ("replace content with..." command)

    There may be a better way, but that one worked great for me^^.
And that's it for the ULSM tutorial!

SSF4AE - Swapping Static Objects with sloth86's Tools

Swapping static objects with sloth86's tools.
copyright sensibeat

sloth86's tools: http://aemods.pbworks.com/w/page/42053948/aetools#Sloth86sModelSwapTools

piecemonteeSF4explorerV0.37b.exe: http://sf4viewer.sourceforge.net/

With this method you can only swap static objects assigned to 1 bone.

First chose a .obj you want to swap:


Chose a character and extract the full model as a .obj with sf4explorer:


You'll have to edit the model in your 3D editor to fit the character:


¤ More infos about that part here: http://filthypants.blogspot.com/2009/08/beginners-guide-to-sf4-model-editing.html

¤ To open the .obj in 3ds max you may need to open it and save it in misfit model 3d first.

Now you have your model in place save it and open EMG2SMD.exe:

I want to swap my cap with zangief's hairs (15th #EMG -as viewed in sf4explorer-)

Open the smd in notepad and look for the number of the bone you want to link your object to:

in that case I want to link to the "head bone": #6.

¤ More infos on smd here: http://developer.valvesoftware.com/wiki/Studiomdl_Data

Now you can use OBJ2EMG.exe:

¤ To use a .obj from 3ds max in OBJ2EMG you may need to open it and save it in misfit model 3d first.

Then use EMGSWAP.exe:


We aren't done yet, it needs some textures (diffusion+normal map dds):

¤ See other tutorials to add dds to your col.emb and nml.emb...

Then use DDSREFEDIT32.exe (I renamed former new.emo to ZGF_01.obj.emo before this step):


That looks OK in sf4explorer:


Let's test in game:


edit:
I thought the bone ID# was in hexadecimal in the smb... it's in decimal sorry for the confusion, I erased that part.
You actually need to write it in hexadecimal when you do it manually, we'll see that in another tutorial...

edit 2: I knew I forgot something...

I didn't linked any material features in the .emm to my "mcap"

2 ways to do it:
1) the lazy way: edit the obj.emo in hexadecimal and change "mcap" by a material that could do the trick like "shoes" or "pants"

2) using NanjouJ's matedit tool, replacing an unused material (in that case "hair") by "mcap" and the features you want to use on it.
http://aemods.pbworks.com/w/page/42053948/aetools#NanjouJsMaterialsTool
UPDATE: use sloth86's EMMEdit instead. It's much easier.

Here's the final result with material features added (no more weird reflections):

Analytics Tracking Footer