Mugen 1.1b
Mckenzie Witting
Speedster made a great MUGEN build with many different resolution and slot number options to choose from, however, it was only for MUGEN 1.0. I ported this to MUGEN 1.1 by copy and pasting fight.def, fight.sff, and all the system.def files into a MUGEN 1.1 build. Now MUGEN plus can be used in MUGEN 1.1
well I never heard of this screen pack till today. we can use the mugen 1.0 and 1.1 so we can use the slots that been made and use for making screen pack with these many slots setting and resolution setting
[color=blue:86df9e3a19]I am writing here today in regards to M.U.G.E.N - the 32bit 2D game engine built for Microsoft Windows using Visual Studio Express and SDL.[/color:86df9e3a19]
I represent 3 sub-communities of the M.U.G.E.N 2D Freeware fighting game engine community (links in signature).
I am foremost a graphic designer/content creator hence have very limited understanding of SDL, C++ and OpenGL, so please pardon my ignorance-I will do my best to explain what we are looking for.
[color=red:86df9e3a19]1) We want to confirm whether or not it is possible to take the 32bit MUGEN 1.1b Game Engine, and convert it to a Windows 64bit version, to allow uncapped access to more than 4GB of system memory and/or GPU resources when running on a 64Bit Windows OS.
[color=blue:86df9e3a19]If what we are requesting here already sounds preposterous, please stop reading and I apologize for wasting your time.
If however you are still interested and this sounds like something that is possible, please continue reading.
Here is a brief background of MUGEN, the status of our community and why we are trying to do what we are doing.[/color:86df9e3a19]
[size=18:86df9e3a19]What is M.U.G.E.N?[/size:86df9e3a19]
For those unfamiliar with M.U.G.E.N, it is is a freeware, 32bit 2D fighting game engine built for Microsoft Windows using Visual Studio Express and SDL. It supports OpenGL 2.0 and higher.
The most recent public release of the engine is M.U.G.E.N 1.1 beta 1, released August 7th 2013.
[size=18:86df9e3a19]The current state of The M.U.G.E.N community[/size:86df9e3a19]
The general consensus throughout the M.U.G.E.N community is that Elecbyte have retired and no further development on the engine is to be expected.
Despite the engine being outdated and the absence of its creators, the community is still very active and new M.U.G.E.N content is constantly in development.
Support for the engine, including troubleshooting, tutorials, and even unofficial download links to the M.U.G.E.N engine are maintained by the MUGEN fanbase and community itself.
Why do you want a 64Bit MUGEN 1.1?
The issue with the current Engine, MUGEN 1.1b is that it is a 32bit application that only supports use of up to 4GB of system Memory.
We require it to have access to more than 4GB of system memory, and understand that the only way to achieve this is for it to be converted to a 64bit application.
Mugen 1.1b1 was the first version to support OpenGL with 32bit png color and HD/UHD resolutions - content creators began attempting to rip and import content from 7th Generation console games which utilize High Definition image files and sprites, which are much larger in both dimension and file size, in comparison to the low resolution file sizes of 1990s- early 2000s arcade games as you can imagine.
MUGEN 1.1 will crash with an out of system memory error if it is forced to try and use more than 4GB of system memory.
This happens particularly when MUGEN is forced to try and load large numbers of large image files simultaneously.
For this reason, there is a huge limitation now on what content creators can create in mugen going forward.
Despite having the ability to import and create quality High Definition content - the engine is largely restricted this this memory usage limit.
We just want to know whether it is possible for a developer with SDL/OpenGL skills to modify and increase the memory usage limit only.
Moreso, we want to confirm if the developer can achieve this on the current MUGEN 1.1 engine without needing sourcecode access.
The other way is by dumping the assembly source and then make changes.
This sounds interesting - so you mean it would be possible for a developer to do this by just having access to the engine, without needing the sourcecode?
More like fan made material. But it would go in the MUGEN category because they are not legit pc games. Fighting game creator is what it is. Just like Rpg maker would go under it's own name because it is an engine that can create a bunch of other games.
Well thanks for the clarity. I figured out how to increase the resolution and add scanlines to MUGEN games like Bastard and AVP. In case anyone reads this in the future, go to your data folder of the game and look for mugen.cfg
This is a playlist of 42 MUGEN video clips that I uploaded to YouTube. The "Bastard!!" game you mentioned is in there too. I've actually created 140 in total so I must upload the rest soon. I've also uploaded about 370 OpenBOR clips if you ever get onto them. They took me weeks to complete. Emumovies is a bit patchy for MUGEN and OpenBOR videos.
Yeah, I created every single video in both of those playlists. I'm quite proud of them. They took me about 3 weeks fitting it in around work. Afterwards, I never wanted to see or play a MUGEN or OpenBOR game again heh.
Description - This tool patches x86 executables in order to let them have 4GB (instead of only 2) of virtual memory on x64 platforms. After using this patch on your Mugen 1.1b executable, the memory limit (RAM) will increase from 2GB to 4GB on x64 platforms, allowing the use of heavier memory content and stoping Mugen from crashing.
Pantherk"UOOOOOOOOGH" PANTHERK shows mercy!Stats16603000100100InfoTypeOriginal, editAuthor NameBrergrsartOriginMortal Kombat ChaoticAI?YesDate of first public releaseSeptember 9th, 2021Mugen Version1.0 and 1.1b
Pantherk is a human-panther hybrid originating from the infamous M.U.G.E.N fan-made game Mortal Kombat Chaotic. He was remade by Brergrsart for the fullgame Vargverse, as Joel played said fangame while the project was still in the works.
Because of its size and sprite limitation, Pantherk is quite easy to punish when hit from below, thus making it its weak point; to circumvent this, Pantherk's crouching attacks are instead summons, allowing him to call a tiny Shao Kahn (weak and medium) or Bear Sub-Zero (strong) to help him.
His Vinetrigger is the best in terms of damage, but the worst in terms of mastering, as each of Pantherk's states is boosted, wich also includes his speed, making him really hard to control during the entire state; the durability of the Vinetrigger is also quite short, making it hard to time correctly.
As Joel haves little to known knowledge on how Fighter Factory works, he decided to make Pantherk an absolute monster with all he could think of by editing all his stats to be cheap-like, by also making Pantherk extremely flat (or as he called it, Fun Sized) and increasing his volume to make him extremely loud.
Command Trigger Overflow, technically known as Command Trigger's Buffer Overflow Attack or CBOF, is an exploit in all the M.U.G.E.N Engine versions that allows for arbitrary code execution at the time of character selection.
As a part of the SuperNull exploit series, it is executed when a character is loaded during the character selection, making it a good alternative to the StateDef Overflow exploit as the latter is usually sealed by other characters.
As implied by the exploit's technical name, it takes advantage of a Buffer Overflow type vulnerability in the Command Trigger's text parser. Text parser's buffer size is assigned to 64 bytes by default, and when a Command Trigger string line exceeds the assigned size, it will cause the parser's return address to be overwritten, resulting in a potential arbitrary code execution.
Although the exploit still functions in these engine builds, shellcodes cannot be directly used but ROP chains, as stated in the exploit series article. It is not one of the best options to use, as it has a lot of data limitations that makes this exploit difficult to handle.
Non functional in 1.1b as the length of Command text strings will be truncated to the parser's buffer size; Use the AssertSpecial exploit instead.