Fighter Factory Studio released! 3.7.4.4

[O Ilusionista]

From author's Patreon Post: https://www.patreon.com/posts/version-3-6-3-is-58179294

Version 3.6.3 is out. This build fixes various issues and has many quality of life improvements as listed bellow:

Changes:​

• Fixed search & replace for CMD and AIR text mode;
• Fixed color settings not being properly updated while applying changes;
• Made text editor background/foreground colors customizable;
• Increased maximum zoom level for Image editor to 32.
• Implemented some security measures to avoid data corruption of binary files if something goes wrong during save;
• Implemented a tooltip for tabs to display the full path of the file/project.
• Implemented Edit / Code / 'Auto-indent selection' and 'Auto-format selection' functions for code formatting;
• Implemented Project / 'Welcome screen' to show the first screen with recent projects as a tab;
• Added the complete file path to the history menu;
• Added an option to edit the history (remove items) from the Welcome screen;
• Added support for OGG/FLAC/MP3 (open/import) and OGG/FLAC (save/export);
• Increased maximum pen size from 24 to 128 and remap slots from 12 to 32 in the Image editor;
• Moved tool options in the image editor to a toolbar at the top of the canvas area (will move to the main toolbar later);
• Fixed the bug that makes impossible to manually go to a frame with time = 0 in Animations editor;
• Fixed current line in full text mode changing to the first frame when you go to the [Begin Action] line in Animations editor;
• Fixed "Import from another Project" functions reporting twice the ammount of items imported;
• Fixed "Import animations from another Project" function not properly renaming if you do so;
• Fixed .def not being saved for testing in M.U.G.E.N. if used as cns, st, ...
• Added options to choose the texture upload method (Options / Graphics). This may help avoiding issues with bad OpenGL drivers.

Regarding texture upload method, the options are:

• Immediate: texture is uploaded to VRAM after the image has been decoded on loading (increases loading time, unless you're running on SDD). The safest mode, nothing can go wrong;
• Delayed: decoded image is stored in system memory and only upload to VRAM the first time it's requested by the renderer (increases system memory usage but decreases VRAM usage, if you do not scroll over all sprites anyway). Has a good balance between loading time and safety;
• Multi-threaded: the mode used in previous versions and default. Textures are uploaded in many background threads (much faster but may cause trouble, like freeze and messed up textures on some systems). The fastest for modern hardware;

Another interesting info about the ordering which items gets added into the program from open dialogs (a lot of people are talking about this problem).
There's many ways you can control the order of files from an open dialog in Options window:

1. Force the list of files to be sorted alphabetically by checking "Sort file names from the open dialog", or disable it if this behavior is undesired.
2. Choose between Native and portable open dialogs (look for "Use system native open dialog"). The portable one, is the same on all platforms with consistent behavior.

The combination of these two options creates a lot of variety. The most consistent behavior is disabling the two, so the portable dialog will be used without file sorting. The order will be the same as you select the files (as most people seems to want). Sorting creates consistent behavior for native dialogs, as they vary from one platform to another, like the Windows one that always sort the files, no matter the order you selected (just look at the list as you select).
I hope this clarify things a bit more regarding this "issue".
Known issues:

• Advanced search not working;
• Some weird things happen sometimes while editing animations in full text mode.

 

[DCurrent]

Added to resources with links to VirtuallTek Studios Patreon and support page. Associated resource with discussion thread.

DC

 

[DCurrent]

The palette editor alone is amazing, I could never figure out why Photoshop does not have this.

Me: "Why can't I set the color order without having to start over?"
Adobe: "You'll sort by luminosity and you'll LIKE IT."

Fighter Factory is someone finally listening...

 

[O Ilusionista]

The palette editor alone is amazing, I could never figure out why Photoshop does not have this.

Yeah, PS palette editor is kinda too basic.

 

[Bruce]

pretty much everything. You will be able to code characters and stages, visual tool for walls, holes, platforms with drop and drag support - you will be possible to create this things just by drawing them like we do with boxes, and control the points.

I remember, for example, that when you use "seta", the editor shows it visually.

He was thinking to even support the depth (visually) for attack and body boxes.

About the throws in Mugen, yes there is a throw creator

Is there a reason why the sprites in the sprites mode don't look the same as in the mugen game because they all come out much darker? The sprites in the animations mode look exactly as in the Mugen game. However, there is no way I can extract the sprites from animations mode. Please take a look at the attachment for clarification, thank you.

 

[kimono]

Hi Bruce, try an alpha 1 transparency for these Mugen effects.

 

[Bruce]

Hi Bruce, try an alpha 1 transparency for these Mugen effects.

How do I do that? I don't see any option to change it to alpha 1 transparency in Sprites mode. The sprites in animations mode are shown up just like in the Mugen, but when I exported (saved) them, they all looked much darker just like the picture I posted, thank you.

 

[Daniel Tan]

I can't get the program running. It's there but I can't get it to run.

 

[O Ilusionista]

How do I do that? I don't see any option to change it to alpha 1 transparency in Sprites mode. The sprites in animations mode are shown up just like in the Mugen, but when I exported (saved) them, they all looked much darker just like the picture I posted, thank you.

What you see in the sprites tab is different from what you see at the animation tab.

The SFF (sprites) will display the sprites as they are - they have those dark borders, because this will get transparent once you set the alpha.
You can set the alpha at the animation, kinda like you do in OpenBOR - but in Mugen, animation and state are two separated things, not one like they are in OpenBOR.

I dunno if your question is how you display transparency in OpenBOR or in Mugen. So I will try to reply both:

OpenBOR - There are two ways to set the alpha
Alpha at the entity header

alpha {int}

• If set to 1, this entity will be displayed with alpha transparency.
• If set to 2, this entity will use negative alpha transparency (the darker colors are stronger, like shadows).
• If set to 3, this entity will overlay transparency. It's described in the engine as being a combination of alpha and negative alpha, and the formula is "bg<128 ? multiply(bg*2,fg) : screen((bg-128)*2,fg)".
• If set to 4, this entity will use hardlight transparency. Seems to be the opposite of overlay. The formula is "fg<128 ? multiply(fg*2,bg) : screen((fg-128)*2,bg)".
• If set to 5, this entity uses dodge transparency. Described in the code as being "Very nice for a colourful boost of light."
• If set to 6, this entity will use 50% transparency. The entire entity will be 50% transparent: every pixel will be averaged with the pixel right behind it.
• In 8bit colormode, this setting DOES NOT work with remaps. You need 16bit or 32bit color mode to use this together with remaps.

Or using drawmethod

drawmethod alpha 6 drawmethod channel 0.25

See more info at: OpenBORManual - DCEmulation

Mugen
You can either do this by coding

; Fades the character in, over 256 ticks.
type = Trans
trigger1 = time < 256
trans = add
alpha = time, 256-time

See more info State Controller Reference

or right at the animation

15,4, 0,0, 5, ,A1 ;<-- Color addition to 50% darkened dest
15,4, 0,0, 5, ,AS128D128 ;<-- Mix 50% source with 50% dest

See more into at The AIR format and standard

 

[Bruce]

What you see in the sprites tab is different from what you see at the animation tab.

The SFF (sprites) will display the sprites as they are - they have those dark borders, because this will get transparent once you set the alpha.
You can set the alpha at the animation, kinda like you do in OpenBOR - but in Mugen, animation and state are two separated things, not one like they are in OpenBOR.

I dunno if your question is how you display transparency in OpenBOR or in Mugen. So I will try to reply both:

OpenBOR - There are two ways to set the alpha
Alpha at the entity header

Or using drawmethod

See more info at: OpenBORManual - DCEmulation

Mugen
You can either do this by coding

See more info State Controller Reference

or right at the animation


See more into at The AIR format and standard

Wow, that really helped me alot. I finally know how to use alpha transparency in openbor project! Thank you so much for your help!

 

[Uche]

Are the download links only available on the patreon page?

 

[O Ilusionista]

Are the download links only available on the patreon page?

No: Home - VirtuallTek Fighter Factory

 

[Uche]

No: Home - VirtuallTek Fighter Factory

Thank you, sir.

 

[O Ilusionista]

(from VirtuallTek original post https://www.patreon.com/posts/fighter-factory-71436949)

Hello!

Today, version 3.7 is officially released to the public. After a long time of hard work, it's finally done (except some minor issues to be fixed over time).

Changes:​

• Improved PCX and SFF decoding to better handle corrupted files (avoiding crash and freeze on some cases);
• Texture Upload Method will reset to Delayed (some systems are having issues with Multi-threaded mode, the previous default);
• Improved texture uploading (reduced memory usage for delayed mode and fixed some random crashes/freeze that may occur in multi-threaded mode);
• Fixed Tab focus order;
• Fixed window parameter for hires stages;
• Fixed color customization in options going empty after changing something in a fresh install;
• Fixed Offset Viewer and Throw Creator not taking the frame's offset into account;
• Added two options as a workaround to the text tabulation issue on DPI settings not multiple of 100% ("Convert Tab to Spaces while opening" and "Convert Spaces to Tab while saving"), as avoiding Tab and only using Spaces fix the issue;
• Added detection of WinMugen Plus select screen (may not work in all cases because sometimes is impossible to tell);
• Added support for properly drawing parallax on Native painter rendering mode;
• Added debugging support (external debugger grabbing data from M.U.G.E.N's process memory and emulator [MUGENext internal build]);
• Added support for rendering in the Emulator for "Export to HTML" function (supports exporting stages too).

This short changelog may seem a long time for just a bit of improvement, but the brand new feature of this version is massive. The external debugger working on M.U.G.E.N's process is simple indeed, but the Emulator based on MUGENext is a great leap ahead, providing a lot more information and gives you a fast work, test, fix & repeat approach.



Emulator:

It's a new editor, where you can setup a test environment to check issues and see evertything in action inside Fighter Factory. It supports testing Chars, Stages, Storyboard and Screen Packs (system.def).

While working with Chars, more options are available like match mode (Versus and Training), enemy (Self, Random), number of rounds, round time and explod mode. In Training mode, all options M.U.G.E.N has are there.

The engine installation to be used for testing is detected by the Project's directory. If it finds M.U.G.E.N here, like working on a character in the M.U.G.E.N's chars folder, the Project's engine will be used, otherwise, a built-in custom version based on M.U.G.E.N 1.1 will be setup. Random Enemy is selected from this engine installation too.



Debugger:

Both the "regular" Debugger (Debug > Start on Engine) and the Emulator are, in fact, debuggers. So we have two modes, inspect and control execution directly on M.U.G.E.N (the original engine) or using Fighter Factory's built-in build of MUGENext. The Debug panel for both is the same, and it appers in the right side while a debugger is running.

In the Debug panel we have a hierarchical list of variables to inspect. Some of them are modifiable by double-clicking, and most are watchable (can be put in the Watch lists (right-click > Watch variable (1/2) located in the bottom of the interface).

At the top of this panel, we have a row of buttons to control execution:

• Start/resume: starts or resumes execution;
• Interrupt: Pauses execution;
• Stop: Finish the debug session and closes the engine;
• Restart: The same as Stop - Start;
• Step to the next instruction without entering into functions: this steps from one State to another, jumping over triggers;
• Step to the next instruction entering into functions: advance line by line (between State and triggers);
• Step to the next instruction out of current function: jumps out of current scope to the next instruction (from trigger to State, State to StateDef);
• Step to the next frame: self explanatory.

For M.U.G.E.N, instruction here means an entire expression line. Only the Emulator is capable of stepping by line, the regular debugger can only step by frame.


Breakpoints:

These are marks telling the active debugger to interrupt execution before that line gets executed. Breakpoints can be added in many ways:

• Debug > Add breakpoint: manually addds all kinds of breakpoints;
• Left-click in the blank area before line numbers to add one at this line;
• Right-click a variable in the Debug panel, then Add data breakpoint (execution will be interrupted when the value of this var changes).

The regular debugger only supports frame breakpoints, all other are ignored and will not work.

The Emulator supports all except "Function Name". "File Name and Line Number" breakpoints currently only work for State and trigger(all) lines, so all other lines will be ignored.


Download: fighterfactory.virtualltek.com/download

 

[NED]

@O Ilusionista
Looks absolutely impressive! The emulator to test all kind of stuffs in real time is itself a reason to test it!
I'm curious about the texture work. What is the use of it in mugen creations?

When I see how this software progresses with all these years, I feel like it will be the one to "give us" a real stable and complete software to edit Openbor games one day.
When Openbor still have not such a stable thing available (AFAIK)

 

[Die_In_Fire]

How is it for Openbor? Recommended?

 

[O Ilusionista]

Looks absolutely impressive! The emulator to test all kind of stuffs in real time is itself a reason to test it!

The emulator is actually MUGENext running. VT got the idea of making a new engine after he had to build a fully working emulator to debug inside it, so why not make it fully functional?

When I see how this software progresses with all these years, I feel like it will be the one to "give us" a real stable and complete software to edit Openbor games one day.
When Openbor still have not such a stable thing available (AFAIK)

Yeah I wish OpenBOR has it too - and I think its one of the barriers which doesn't make the engine more popular: the lack of a stable all-in-one editor, like FF is for Mugen.
Sadly, all the available OpenBOR editors has some issues. There was a time where the OpenBOR support was a more important priority for FF development (and I have a private version where you could open OpenBOR characters on it), but after some decisions, this priority had changed.

I can't say the OpenBOR support is dead, but its not one of the priorities anymore.

How is it for Openbor? Recommended?

there is no direct support - see my explanation above.
But its very useful to a lot of things, like palette editor (its one of the best tool for that, beats Photoshop quickly), sound editor, work with offsets, images, etc.
I use it a lot for OpenBOR development.

 

[NED]

The emulator is actually MUGENext running. VT got the idea of making a new engine after he had to build a fully working emulator to debug inside it, so why not make it fully functional?


Yeah I wish OpenBOR has it too - and I think its one of the barriers which doesn't make the engine more popular: the lack of a stable all-in-one editor, like FF is for Mugen.
Sadly, all the available OpenBOR editors has some issues. There was a time where the OpenBOR support was a more important priority for FF development (and I have a private version where you could open OpenBOR characters on it), but after some decisions, this priority had changed.

I can't say the OpenBOR support is dead, but its not one of the priorities anymore.


there is no direct support - see my explanation above.
But its very useful to a lot of things, like palette editor (its one of the best tool for that, beats Photoshop quickly), sound editor, work with offsets, images, etc.
I use it a lot for OpenBOR development.

I understand. Too bad. Since Openbor community (I don't say "our" community since you and I are in both of them for a long time now ^^) , so Openbor community is not able, willing, or had no time/ interest to build a stable software to create Openbor contents and bring new creators in the community, motivate the "slow" creators like me to get more regular with the mods creation, It would have been great if this FF project still had Openbor as a part of the regular updates.
Yes, perhaps later in the future.

@O Ilusionista BTW, I'm using more FF AND FFStudio lately...( When I used to be an MCM, MEE, and other outdated softwares user)
And I would like to know if there is a way to edit key shortcuts ?
I'm sometimes editing many sprites of some SFF in FF (not much in FFS) and I would like to change the ctrl+S (save sprite) for something different.

 

[O Ilusionista]

Today, version 3.7.1 is available for download. This version brings some bug fixes and improvements.

Changes:

• Fixed window not clipping correclty on BGs editor;
• Fixed many bugs related to Storyboard and the Emulator;
• Fixed code folding indent for some file types (like Storyboard and Animations);
• Improved the engine directory detection for the Emulator;
• Updated syntax database to better support Storyboard (only Backgrounds starting with "BG" are supported);
• Changed BGDef selection on BGs editor to be items in the Backgrounds menu instead of tabs (virtual files);
• Added support to Storyboard BGs on Backgrounds editor.

Home - VirtuallTek Fighter Factory

VirtuallTek Fighter Factory is the ultimate IDE for the most popular free 2D fighting game engines and related.

fighterfactory.virtualltek.com

 

[O Ilusionista]

From author's post:

I found the cause and fixed the bug that prevents the program from opening on new installations, so the next build should work for everyone.

But, I'm working to change the way the program is distributed.

Changes:

• I'll remove the built-in update functionality. Every new version needs to be manually downloaded and installed (the update function never worked properly in the first place);
• macOS build will be an App Bundle, so you can just copy it to Applications directory or any other place (no installation required);
• Linux build will be an AppImage (no installation required);
• Windows builds (32/64bits) will have two variations. An installer (resolving dependencies) and a Portable build (just a zipped folder with all dependencies in, no installation required).

I'm working on these changes right now to release version 3.7.2 as soon as I get everything done. The new installer for Windows and AppImage on Linux will take some time, but everything else is ready.

I may do some mechanism of checking if a new version is available for download too.