Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Darochinati]

Out of interest, does anybody have any idea how difficult it would be to build a 64bit verion of MUGEN 1.0 (for those who would like to experiment with it?)
My understanding is that MUGEN 1.0 was built in C using the SDL library.
I see there are a pile of .dll files in the mugen directory here:

This will either sound very smart or very stupid because I know almost NOTHING about C++ coding and the SDL library,
but I assume that first these need to be modified in some way/replaced with 64bit versions first, e.g replace SDL.dll with SDL64.dll?
secondly the mugen directory needs to know to point to these etc........e.g point to the dll that lets mugen use 8GB of ram instead of only 2GB etc etc...?

I suggest that elecbyte release a 64bit version of mugen 1.0, or point those of us willing to make it ourselves in the right direction as far as modifying the coding/SDL library C++ stuff so that we have an option in the mugen.cfg where you can select the maximum ammount of RAM allocatable to Mugen e.g 6GB, 8GB etc.
IMO, By having access to more than 4GB of RAM there would be a whole new range of possibilities.
Here is my reasoning for this:

some people have said that MUGEN 1.1 will use GPU instead (when it is eventually released).
Someone also stated that unless you had an overload of Hires/hidef content with 100's of oversized sprites and simultaneous animations/particle illusion effects etc, there is no use for a 64bit version.

About a year ago, I figured out how to patch mugen 1.0 so it can use up to 4GB of RAM rather than 2GB
By allowing access to more than 2GB of RAM, you can apply the following settings to mugen and have almost ZERO loading time and still run highly complicated/graphical screenpacks with heavy content:

Code: [Select]

[Config]
;Set the game speed here. The default is 60 frames per second. The
;larger the number, the faster it goes. Don't use a value less than 10.
GameSpeed = 60

;Set to 1 to draw shadows (default). Set to 0 if you have a slow
;machine, and want to improve speed by not drawing shadows.
DrawShadows = 1

;Number of simultaneous afterimage effects allowed.
;Set to a lower number to save memory (minimum 1).
AfterImageMax = 240;60;

;Maximum number of layered sprites that can be drawn.
;Set to a lower number to save memory (minimum 32).
LayeredSpriteMax = 3000;1000;

;Maximum number of explods allowed in total. Note that hitsparks
;also count as explods.
;Set to a lower number to save memory (minimum Cool.
ExplodMax = 3000;1000;

;Maximum number of system explods allowed.
;Set to a lower number to save memory (minimum Cool.
SysExplodMax = 3000;1000;

;Maximum number of helpers allowed in total.
;Set to a lower number to save memory (minimum 4, maximum 56).
HelperMax = 1600;800;

;Maximum number of projectiles allowed per player.
;Set to a lower number to save memory (minimum 5).
PlayerProjectileMax = 500;150;

;-------------------------------------------------------
[Misc]
;Number of extra players to cache in memory.
;Set to a lower number to decrease memory usage, at cost of
;more frequent loading.
PlayerCache = 32

;Set to 1 to allow precaching. Precaching attempts to start loading
;player data as early as possible, to reduce apparent loading times
;between matches. To get the best performance, set PlayerCache to at
;least 1. The optimal number for PlayerCache is 4 when precaching is
;enabled. Precaching is not available in DOS.
Precache = 1

;Set to 1 to enable large-buffer reads of sprite and sound data.
;Set to 0 (off) to decrease memory usage, at cost of slower
;loading.
BufferedRead = 1Here is an example of Mugen1.0 in GL draw mode using up to 3GB:


However, after experimenting with a 400MB+ Hires stage with over 500frames of animation, with most the animation sprites being particle illusion generated sprites at atleast 800x600 in size, I managed to crash mugen via an "out of memory error" in 2vs2 mode where mugen needed more than 4GB to load the stage, the Hires fully animated 300MB+ lifebars and announcer animations etc.
Here is an example of this memory crash:



When Mugen crashes via this out of memory error, it seems that the 4GB patch is disabled and mugen goes back to its default 32bit allocation limit maximum of 2GB(approx).
This proves that a 64bit build, would allow creators to push the graphical content boundaries of mugen.

I donot want to argue with anyone saying it isnt needed, as I agree that there are only a small number of people that want to go that overkill with mugen.
But I would love to show the mugen community what could be done with a 64bit build.

[omega_rugal]

I know almost NOTHING about C++ coding and the SDL library

Then how did you "patch" the exe?

[Code Slasher]

Within that wall of text, Darochinati mentions the massive use of particles and animations.  Couldn't some ranged-based characters (ex.: Touhou characters) benefit from this?

Also, what's with the +respect thing?  Could someone please explain?

[Shadow0X3]

Also, what's with the +respect thing?  Could someone please explain?

It's something Kyo clone 1 started after thinking he could sway people's opinions. Just try your best to ignore it.
After looking at the screenies and visualizing how mugen would look with 64-bit, that makes me really want to +1 this idea, so long as it wouldn't be THAT difficult to do. Just modify the allocated memory based on how much available space there is, simple afaik

[Byakko]

The "patch" explained is not a patch, it's configuring mugen.cfg. This is completely unrelated to... Erhm, to anything. Other than the point at which Mugen crashes if your computer itself is unable to take the load. This is just using more of the raw power of a regular computer until it breaks from overload, rather than optimizing the treatment to make that same work load smaller and thus not break with the same limit. When you say "Mugen now uses 2GB or RAM instead of 4GB", it's actually perfectly normal. This configuration file you modified ("patched") is precisely there to allow you to make changes according to how powerful your computer is.

A more powerful computer can obviously take a bigger load than a weak computer, and can display more explods and helpers at the same time. The reason you can change at will these numbers you changed is that with a weaker computer, you want Mugen to not generate more explods and helpers than that, because otherwise, it crashes. The objective with this config file is to precisely tweak those numbers, so as to allow Mugen to display as many explods and helpers as it can, but not more, and then when it's at its limits, newer explods/helpers replace older ones or just aren't created.
You didn't tell Mugen to use 4GB rather than 2GB, you just told it that the limit of your computer was higher than it really was. What you did is just telling Mugen your computer could handle 3000 explods, and then let it try to do that, and fail, and crash - because your computer actually can't handle that. You're supposed to try lower numbers until it doesn't crash because it won't try to display more explods than it actually can. If you saw any difference, it's only because the initial limits were lower than your comp's actual limits ; when you upped the number, it was allowed to reach your real limits (so it worked better than with limits too low), but then since your new numbers were to high, it went past your real limits, and it crashed.
As for the crash with 400MB stage and 300MB screenpack, this is just unrelated to what you changed. It's just that you don't actually have enough free memory, hence the "out of memory" error.
And all of the above is just completely unrelated to 64bit or anything.

As for Mugen's needs - Elecbyte showed pictures of tests for the new graphic engine of the upcoming 1.1 version, and those tests reached a framerate around 600fps, when previous versions of Mugen could have troubles at 60 with heavy characters and such. If Mugen can now go 10 times as fast, I just don't see why everyone talks about 64bit like it was the invention of hot water all over again, unless everyone starts pumping out characters of 800MB each.

Finally, about your idea of just switching DLLs, well hum, that's just not how it works at all. You're supposed to rebuild it from the ground up.

And this is totally not the first time all of this is explained on this forum. You can try to look around.

[Josue]

Who needs Mugen to be 64-bit if it runs just fine on my 64-bit, CORE i5, 4GB RAM computer?

End of story.

Yeah, [/thread]

32bit software is going to be around for a long time anyways.

The "patch" explained is not a patch, it's configuring mugen.cfg. This is completely unrelated to... Erhm, to anything.

Well, Byakko has already said it all, I just wanted to add:

I know almost NOTHING about C++ coding and the SDL library

Then how did you "patch" the exe?

True, he doesn't know about C++ and I doubt he knows anything about assembler.
Besides, to do anything like that you would need MUGEN's source code to build it with a 64 bit compiler, and probably you would also need to tweak the code for it to compile correctly. or you would need to hack the existing exe (like they did with the WinMugen one, I'm not sure exactly how) hex edit it and that's not practical. Actually I doubt you can convert it into 64 bit by hex editing it.

Whoever said ignorance is a bliss... *sigh* I can say it's actually the source of painful trouble.

I suggest that elecbyte release a 64bit version of mugen 1.0, or point those of us willing to make it ourselves in the right direction as far as modifying the coding/SDL library C++ stuff so that we have an option in the mugen.cfg where you can select the maximum ammount of RAM allocatable to Mugen e.g 6GB, 8GB etc.

Elecbyte hasn't even released the source code for the current 32bit MUGEN!!!

This proves that a 64bit build, would allow creators to push the graphical content boundaries of mugen.

No... if you make something that overstrains most computers (that's what you did, you simply set MUGEN's limits up to values your system could not handle, thus you got the "out of memory" error.)
nobody will be able to use that!
Quality over quantity, dude. Massive effects and such is usually simply something bloated and not practical.

*sigh*...
the amount of misconceptions is preposterous...

[Darochinati]

Thank you for all your feedback.
I am glad to see that there are people discussing the pros/cons of this idea.
I have read all of your comments and I will try my best to answer all of your questions and provide explanations for your areas of doubt.
In my first post I will address your questions and in the second post I will reply to some of your statements regarding the .cfg file and PC specs etc.  

I know almost NOTHING about C++ coding and the SDL library

Then how did you "patch" the exe?

I was waiting for someone to ask!
I was still using Winmugen plus when I started trying to do this. Winmugen plus uses the Allegro Library (mugen1.0 which i didn't use at the time uses SDL).
I asked the IT company I deal with at work about 32bit app RAM usage limits on 64bit OS's and what I was trying to do with MUGEN and they told me that it had nothing to do with Allegro or C/C++, and they told me about a method for increasing the available RAM for 32bit apps when run on a 64bit OS known as 4GT which is explained here more or less in a more detailed manner than how they explained it to me:
http://www.blackid.asia/2010/04/27/x86-or-32bit-os-with-4gb-ram

I sounded difficult so I put in a job request with them and they wrote me a small program in one hour, which was basically a patch run via a command window that patches the "winmugen.exe" file once placed in the same directory, and it would remove the 2GB cap and allow mugen to use up to 4GB RAM (approx 3.5-3.7GB).
In theory, they said that the patch could potentially remove the 2GB limit from any 32bit .exe, but their charge out rate is 120/hr so I got the dirt cheap molebox version that must be placed in the same directory as winmugenplus.exe, and will ONLY patch winmugenplus.exe. If I wanted a GUI built for it and the ability to browse for other applications to patch, it would have been expensive.
My patched version of winmugen plus has been available on the phantomGs forum since around xmas 2009 and had some positive feedback.

I was pissed off for spending $120 when I discovered later on in 2010 that somebody else had already created an almost identical FREE program which includes the GUI for selecting any 32bit application and removing the 2GB ram limit. Here is the link to this program and the creators homepage if anyone wants to try on their own mugen and see for themselves:
http://www.ntcore.com/4gb_patch.php
I have tested this on various programs other than MUGEN on XP, vista, Windows 7, and had no problems.
If anyone is unsure how to work the patch above or would like a direct link to the already patched 4GB winmugenplus/mugen 1.0.exe, please reply in this thread and I will check as soon as I am able to.

Because this program included a GUI and the ability to select any 32bit .exe, I used it on the official Mugen1.0 release and converted my Mugen SP/full game system etc over to Mugen 1.0 earlier this year and deleted the old shitty program that I paid for.

Within that wall of text, Darochinati mentions the massive use of particles and animations.  Couldn't some ranged-based characters (ex.: Touhou characters) benefit from this?

Quality over quantity, dude. Massive effects and such is usually simply something bloated and not practical.

@Codeslasher: My screenshots in my previous post showing mugen using 3GB represent the new limits I was able to reach in terms of multiple over sized simultaneous animations/sprites, cache/explod/projectile/helper settings etc. If it is flashyness, extreme graphical content and multiple stage/character hi res animations you seek, then this will definitely benefit you.
With this patch I can easily have 2vs2 overkill 42MB broken GOD Touhou characters (for test purpose only as i don't really like god characters) battling out at 60fps on a 200+MB stage no problem (not to mention the simultaneous oversized animations running on my 1GB system.sff/fight.sff/fightfx.sff).
I am from a graphic design/art background so that is naturally my preference, however not everyone is interested in the graphical side of mugen as much as the fundamentals/mechanics and we should respect this.
@Byakko: I agree 100% that quantity over quality is a huge mistake in gaming, however I do believe their would be benefits to a 64bit build.

The "patch" explained is not a patch, it's configuring mugen.cfg. This is completely unrelated to... Erhm, to anything.

You didn't tell Mugen to use 4GB rather than 2GB, you just told it that the limit of your computer was higher than it really was.

@Byakko: hopefully the download links and explanation above regarding the 4GB patch provide a detailed explanation now that this is indeed a patch and unrelated to the mugen.cfg.
If you have a PC with atleast 4GB available RAM, welcome you to try the patch for yourself and then experiment with the mugen.cfg settings after adding the patch to your likings. I guarantee you will find a difference in loading time to say the least. Here is a comment from phantomGs forum regarding this:

Well i tried and well i did its job i guess i mean i don't notice anything that changed MASSIVELY, but the loading time did decrease by a lot usually have to wait 5-8 sec pops up just about instantly and also there was no point and creating a backup lol cuz it was just a drag N drop w/o overwriting,but again it did make my mugen load up faster, Good Job and keep it up

Then I told him to try the coding for mugen.cfg i posted in my previous post and he replied:

holy shit,The PreCache fuckin awesome, didn't notice that, and my Moojinz just got better, thanks daruminati, using Vista  >.<

What you did is just telling Mugen your computer could handle 3000 explods, and then let it try to do that, and fail, and crash - because your computer actually can't handle that. You're supposed to try lower numbers until it doesn't crash because it won't try to display more explods than it actually can. If you saw any difference, it's only because the initial limits were lower than your comp's actual limits ; when you upped the number, it was allowed to reach your real limits (so it worked better than with limits too low), but then since your new numbers were to high, it went past your real limits, and it crashed.
As for the crash with 400MB stage and 300MB screenpack, this is just unrelated to what you changed. It's just that you don't actually have enough free memory, hence the "out of memory" error.
And all of the above is just completely unrelated to 64bit or anything.

I apologize for not posting my PC specs earlier. This should hopefully prove my system is capable of handling  the explod settings etc mentioned previously if only Mugen wasn't limited to 4GB virtual memory. Apologies for the oversized screenshots. I can remove them if this is against forum rules please let me know.

PC Specs



SF4 AE on MAX settings



[/spoiler]

Crysis2 with ultra settings, all up to date hi res texture plugins and DX11 Patch



Running TVC via Dolphin on 1080p Full HD max settings at 60fps with additional rendering plugins:



I am fully aware that there is a pending Mugen 1.1 release that uses GPU. I look forward to its release, but because we do not know when that will be released, I would like to pursue a 64bit modification of the existing mugen 1.0 if elecbyte believes it is possible and are willing to offer it to us. I would like to hear from elecbyte regarding this topic and would highly appreciate their opinion on this.

[Frederika Bernkastel~]

first, thanks for not throwing a fit while in the discussion, while i did not particularly expect that from you I have come to expect that from recent posters so it's good to see someone keeping it mature for a change.

second, that patch looks interesting, though I don't have anything worth testing it right now, i will try and set up a mugen that uses much more memory just for it.

[omega_rugal]

I7? i would play something better on that

anyway

Let get something straight

Your hack removes the memory limit imposed by the OS to adress memory, but sorry, you are still running 32-bit code, do some research and find out why the 2GB limit exists

check this

http://en.wikipedia.org/wiki/Physical_Address_Extension
http://en.wikipedia.org/wiki/3_GB_barrier

Nice job AMD/Intel, you succesfully brainwashed people to think that just because "it can adress more memory!" = better

Damn how come i didn´t notice this?

does anybody have any idea how difficult it would be to build a 64bit verion of MUGEN 1.0

[Darochinati]

first, thanks for not throwing a fit while in the discussion, while i did not particularly expect that from you I have come to expect that from recent posters so it's good to see someone keeping it mature for a change.
second, that patch looks interesting, though I don't have anything worth testing it right now, i will try and set up a mugen that uses much more memory just for it.

Thanks Frederika, I am sure you will not be disappointed. remember that you can always patch your mugen as it is now and continue using it as normal, and when your mugen gradually gets filled with more heavy and graphical content and more characters, I guarantee you will see the difference.

Your hack removes the memory limit imposed by the OS to adress memory, but sorry, you are still running 32-bit code, do some research and find out why the 2GB limit exists
check this
http://en.wikipedia.org/wiki/Physical_Address_Extension
http://en.wikipedia.org/wiki/3_GB_barrier
Nice job AMD/Intel, you succesfully brainwashed people to think that just because "it can adress more memory!" = better

@omegarugal: Thank you for the links. I understand that it is a 32bit code, hence my suggestion of a 64bit version. The wiki link regarding the "3GB barrier" I have read before.
As per my link I posted in my previous post, I am aware of PAE and AWE: http://www.blackid.asia/2010/04/27/x86-or-32bit-os-with-4gb-ram

While I admit I am in no way an expert in any of these memory/virtual address space/Address windowing/mapping related matters, I did read up on AWE/PAE before posting here and discovered that a person just like myself named ronag on stackoverflow.comwas trying to allocate more than 4GB RAM to a 32bit application on a 64bit OS did ask experts about the possibilities of this and had the following replies:
http://stackoverflow.com/questions/7282079/address-windowing-extension

RONAG:I have an 32bit application with very large memory requirements. I noticed that there is something called Address Windowing Extension.
However I haven't found much information in regards to how to use it and also what disadvantages and problems one might run into while using this?

xanatos:It shouldn't work on versions of Windows at 64bits (read here http://msdn.microsoft.com/en-us/library/aa366778.aspx Intel and AMD's specification of PAE does support the x86-64 architecture but the software layer of Microsoft's PAE (the API), called AWE, is not supported on 64 bit editions of Windows, so Windows Vista 64 bit cannot attribute more than 4 GiB of RAM for a 32 bit application.). Even on Windows 32 bits there is a "license" limit on the amount of memory usable (same page shows all the limits). And clearly it's complex to program :-) It's like using EMS on the old 8086.
Ah, no 64 bit OS support is a deal-breaker for me. – ronag Sep 2 at 10:27   
If you truly need much memory, you should try to convert the program to 64 bits (but it can be complex, especially if it needs to support "legacy" libraries) – xanatos Sep 2 at 10:30
Unfortunately I'm dependent on third party components that are in 32 bits. – ronag Sep 2 at 10:32   
Time to ditch those dependencies. You need to move to 64 bit. – David Heffernan Sep 2 at 10:35
The "license limits" flat out exclude AWE on Vista and Windows 7. Windows 2008R2 doesn't even have a 32 bits version, so AWE flat out isn't available on the last 3 Windows versions.
@MSalters "license limits" are about memory, and they are 4gb. You can still use 2gb more than without AWE. – xanatos Sep 2 at 15:35   
If you can move your 32 bit dependecies out-of-proc that would allow you to move to 64 bit easily. At least easier that having to deal with AWE. – Seva Titov Sep 2 at 16:16

Excuse me if I have misinterpreted this, but most of these guys are telling him to migrate his app and OS to 64bit rather than apply AWE/PAE to his 32but app in a 32bit environment, if it is more RAM access he requires.
However your posts and opinions have highlighted that I may have been a little naive, and I may be suggesting the wrong things in regards to a 64bit build.
If that is the case does anyone have any other suggestions on this matter and how to achieve access to more RAM?

[zerogunner]

wow, some really interesting comments here....
But it sounds like its too difficult and probably wont happen....

[Code Slasher]

wow, some really interesting comments here....
But it sounds like its too difficult and probably wont happen....

Yay, the original poster returned!  Lol.

By the way, I hope you have learned a few things from the people here.  As you can see, there are many people that adamantly stand by their positions.

[zerogunner]

Yes definitely.
It seems the problem is more to do with the way in which mugen utilizes system resources and the fact that it is still 32bit code.
I guess we have no choice but to wait until Mugen 1.1 is released so we can benefit from using the GPU.

I am running:

windows 7 64bit
8GB RAM
i7 2600 3.4GHZ
Nvidia GTX 440

I have tried the 4GB patch mentioned above by Darochinati and I applied the config settings above and noticed a huge difference in loading time.
My mugen 1.0 uses about 2GB RAM max with all these settings but during pre fight loading it goes up to about 2.3GB, where as before it never used more than 1.9-2.0GB.
A small enhancement, but definately better than nothing at all.
I will see else I can do with this patch. +1 Daruminati!

[omega_rugal]

it is a 32bit code, hence my suggestion of a 64bit version.

With 64-bit mode, you get more memory available, but there´s a penalty in performance inherent with the so called long mode.

Maybe a separate build may please overkillers.

[Code Slasher]

Yes definitely.
It seems the problem is more to do with the way in which mugen utilizes system resources and the fact that it is still 32bit code.
I guess we have no choice but to wait until Mugen 1.1 is released so we can benefit from using the GPU.

I am running:

windows 7 64bit
8GB RAM
i7 2600 3.4GHZ
Nvidia GTX 440

I have tried the 4GB patch mentioned above by Darochinati and I applied the config settings above and noticed a huge difference in loading time.
My mugen 1.0 uses about 2GB RAM max with all these settings but during pre fight loading it goes up to about 2.3GB, where as before it never used more than 1.9-2.0GB.
A small enhancement, but definately better than nothing at all.
I will see else I can do with this patch. +1 Daruminati!

Oh dear, another +respect reference....

Well, I would definitely want to hear Josue's response to this.