Mugen to OpenBOR migration guide

On this topic, I will be explaining (as much as I can) explain the difference between the two engines, showing how to get the same results as we have in the Mugen OpenBOR when possible. For this, I need everyone's help.

I think it important to be able to invite more people from the community to the Mugen OpenBOR, since we have a lot of good people there, and OpenBOR is a fantastic engine. Both engines works different, and both have its good and bad points.

This post will be a constant work in progress. Since english is not my native language, please inform any english error.

TABLE OF CONTENTS




OpenBOR manuals:
http://dcemulation.org/index.php5?title=OpenBORManual
http://www.caskeys.com/arc/games/openbor/wiki/index.php?title=Main_Page

1. BASICS


1a - SFF file and Images


Unlike Mugen, The OpenBOR not use all images in a single file (SFF). All images are organized into folders, usually the same folder as the character but can be in any folder inside the root folder DATA.

One advantage of this is the ease of editing of the images and share images among characters, since respecting the same color palette or palette is changed programmatically. And since there is not a single file, there isn't the same problem we have in SFF file, where images with shared palettes must come before images with no shared palette.

1b - Image Formats & Transparency

OpenBoR supports 256-color (or lower) .bmp, .gif, .pcx or .png files. However, .bmp is too big so choose between the latter. .png is recommended. Image's extension can be omitted (e.g idle instead of idle.gif). If they were more than one images with same name but different extension and there's no specified extension, OpenBoR will search in this order: .gif, .bmp, .pcx then .png

24bit .png is also supported, but naturally you lose the ability to use palette swaps on that entity. Mugen suports it on version 1.1, using alpha mask on the palette (RGBA values). OpenBOR can use Alpha masking (see below).

Transparency

For PCX files, the transparent color index is the same for mugen: the last entry on the palette. For all other formats, is the first one.

Alpha Masking is avaliable (since version 3.2852+), which allows complete freedom in determining the transparency for sprites.

With alpha masking, each pixel of each frame of an animation can have its own alpha value from 0 (fully transparent) to 255 (fully opaque).

OpenBor support sprite clipping, I will talk about it later.

 

[O Ilusionista]

Each engine have points that its better and worse than the other, but you will get it quickly.

IMAGES
- in openbor, you don't need to crop the sprites, the engine is very optimized for it and does it on the fly. So, make all images using just one offset, set it one time per animation and its done. Cropping every sprite individually for OpenBOR won't hurt anything, but it's a huge waste of your time.

- use PNG over all other formats (.PCX, .GIF. BMP). The file is smaller. just remember that, in png, the transparent color is the FIRST ONE, not the LAST ONE like in .PCX. To make it easier in Photoshop, choose EXACT (under indexed color) and on FORCED click custom and put the background color in the first position. Do not use interlace on png, because as DC said, it will just make the file bigger for no benefit.

CLSN BOXES
- you just set one clsn box (per type) on each frame. lke Ned said, Bbox (body box) are the blue clsn in mugen, and attackboxes are the red ones. You can't set two bbox per frame, for example. Note that internally, OpenBOR actually does support unlimited boxes per frame. There's just no text command to use them yet. This is coming soon.

- All clsn boxes in OpenBOR have de "default" attribute. So, if you set one bbox or a attackbox it will be active for all the rest of the animationt, contrary to what happens in mugen. However, if you put in a box attack frame and put another box in the following frame, the attack will not hit twice - again, contrary to mugen (in other words, its not "persistent" as we call in mugen). To make a move hit multiple times, you need to put "fastattack 1" on the animation header (where you put bbox, etc) and you need to add a blank attack box. To make it, just add "attack 0" before the frame, like this:

attack 70 47 36 60 3 1 0 0 15 15
frame data/chars/warmachine/fs2.pcx
attack 0
frame data/chars/warmachine/fs2.pcx
attack 70 47 36 60 3 1 0 0 15 15
frame data/chars/warmachine/fs2.pcx

POSITION

Remember we are working in a 3D space, so in OpenBOR we have X, Y (often called A) and Z, like Winmugen had (now its just X and Y). This is one of the points that both engines are very different:

- In Mugen, Y can be negative. In OpenBOR, not. Unless you override with script, once the entity touches the "floor" (its a bit different concept), it won't sunk bellow the ground like in some errors in mugen. Heck, I never undertood why in the blood hell we can go BELLOW the ground in mugen, but anyway...

- Mugen uses reversed Y values, while OpeBOR uses the normal ones. In mugen, to make something go up, you set a negative Y velocty, but in OpenBOR you set a POSITIVE one, while negative velocities will make it go to the ground. And if the entity is on the ground, it won't get nowhere.

- Y position is Altitute (hence the "a"), z is the depth.

There are a lot of other things to explain which are different on both engines (like the friction, which is absent in OpenBOR, for example). But one of the areas were OpenBOR surpass Mugen is that if the engine doesn't have something you can do it manually, via script, in most of times. Sure, there are some limitations, but we have far more control.

 

[O Ilusionista]

ATTACKS IN OPENBOR

This is an example of what would be in MUGEN HitDef, you will see that things have infinitely simpler:

attack  70 47 36 60 3 1 0 0 15 15

attack{#} {x} {y} {right} {down} {damage} {power} {block} {noflash} {pausetime} {z}

- Items in red are the positions of attackbox (which would be our CLSN red). Unlike Mugen, you can only have one attack box active per frame.

- {damage} is how much damage the attack will cause.

- {power} is one of the interesting concepts BOR - any value above 0 will take down the enemy (such as a fall in mugen = 1). However, if the enemy has a resistance to knockouts (another cool thing of the BOR) of 20 for example and you put 1 as power, the attack will not take him down, but it will take 1 of this counter. If you hit it again, it will substract again, etc.. When the enemy has no more strength, then he will be knocked down, and the counter resets

- {block} says if the attack is defensible or not. By default, attacks on the defense does not draw energy., But you can change that and even do the same schema with the POWER: blocked attacks will subtracting from the counter until he can not block it anymore.

- {noflash} says if the attack will emit a flash (hitspark in mugen) or not. Here's another cool thing: The enemy can override this. Imagine what a blow when hit, display a cut with blood. In mugen, you have to do some trick to this don't happens, but the BOR you determines a hitspark that appears when you get hit. Ie: the target can determine way more things in attack, while in Mugen who has the most control that is the attacker. Has its pros and cons.

- {Pausetime} works the same way in mugen, but it is a value for both (attacker and defender), something I do not like. You should be able to change it via script (you can changes A LOT of things via script in C, in OpenBOR)

- {z} is the depth of the blow. As we use three dimensions there, you have to choose the depth of the blow. If I'm not mistaken, a value of 10 on the attack hits 5 pixels to one side and 5 pixels to the other.