YesNoOk
avatar

-- Mugen to OpenBOR migration guide -- (Read 237 times)

Started by O Ilusionista, November 26, 2014, 01:14:09 pm
Share this topic:
-- Mugen to OpenBOR migration guide --
#1  November 26, 2014, 01:14:09 pm
  • *****
  • 11 years of MFG and counting :)
    • Brazil
    • www.brazilmugenteam.com

  • Online
On this topic, I will be explaining (as much as I can) explain the difference between the two engines (which are different animals), 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.

please, do not use this topic for requesting help, use other topics. Let's make this a clean guide.

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

There is no support for "24-bit" PNG (for characters), just indexed color ("8bit" or Color Type 3). 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.
Re: -- Mugen to OpenBOR migration guide --
#2  November 30, 2014, 04:00:55 am
  • *****
  • 11 years of MFG and counting :)
    • Brazil
    • www.brazilmugenteam.com

  • Online
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. Setting multiple offsets will, in the end, to consume more memory.

- 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 consume more memory.

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.

- 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:

Quote
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. 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.