Mame Compiler 100% Automated

[Rain]

The new version of the program is looking pretty good, now I just have to finish refactoring about 3200 lines of code and orginize my methods and we should have a release in about a week.

[rimbambito]

Please excuse my ignorance as i'm new to all this. Why would anyone need to compile a MAME exe? Can't i just download the latest version.

[djvj]

Because nobody really uses a plain vanilla Mame. If you do then you don't have hi-score support and have a very annoying nag screen to press left-right each time you launch a game. Also vanilla mame won't be optimized for your specific cpu. Many more things too, but those are the main ones.

[Rain]

Please excuse my ignorance as i'm new to all this. Why would anyone need to compile a MAME exe? Can't i just download the latest version.

To people whom it matter to, it pretty much all boils down to updates & machine architecture. If I asked you to show me a version of Mame 0.143u6 for a quad core 64 bit processor with the Hi-score patch, you'd never be able to find it on the Internet. However, you could just build your own version and have it in about an hour.

Building primarily is for those whom want to stay up to date with their Mame build and have those updates as soon as they are released. Myself, I have always compiled my own Mame since 2000 becuase I like the benefits of running an executable custom tailored for my own system, the speed increase and because I like to modify the original source code to inlclude my own enhancements.

Along with that there are other benefits, for instance if you use a 15hz monitor you can build your Mame to output at 15hz, you can add patches to double/triple buffer graphics, you can even add DirectX 11 support as well as sound enhancements. There is a giant laundry list on why one would want to compile their own Mame distribution.

I will be writing an extensive tutorial and releasing it with the next MyMame release which will also touch on how Mame works on the code level. Be sure to check it out! I hope that this has answered your question!

[Rain]

Good news everybody! In the new release I have decided to add compiling process adjustments. You can now compile with these priorities:

• Idle
  
• Normal
  
• High
  
• Real Time
  

Just another small enhancement I am all too happy to bring to you.

UPDATE: Wow! Compiling is really smooth now that I can control at which depth my computer compiles. If I want it to run unoticible in the background, I just pop it on low. If I'm not using the PC set it to realtime and I'm good to go. Thanks for the ideal guys!

[Rain]

Here is a little screenshot of MyMame 1.2 working it's Mojo and showing off the new priority control set that I added in:

Are there any other tools that you would say an AIO Mame compiler should have? I have had a request to make a built in C++ editor but am not sure if that one will come to life as of yet or not. Any suggestions, ideals or concepts would be appreciated. Thanks guys!

[djvj]

Can it make me coffee?

How about choice of where I want settings to save, I prefer portable solutions, not "My Documents" ones. Trying to keep everything off my C drive. I'm still pushing for tooltips on all the options so everyone knows what each option does w/o having to read docs.

[Rain]

Umm, not sure about the coffee - but portable settings can be done (oh, wait in fact here a picture is worth a thousand words.)

Tooltips have already been put into the application as well. There is also an external help file with very good documentation. The save/load options allow users to save an array of different build guidelines and share them with other users, or just archive them for future use.

It would probably be easier if I just added a what's new log to this post so that you will have an ideal of where the program is going:

• Added advanced error trapping.
  

• SHA-1 & CRC checks done on every file in/out.

  
  

• Added tooltips.

  
  

• Added Open/Save menue.

  
  

• Added complete help file.

  
  

• Automated error submission.

  
  

• Mame update notifier (notifies you when your Mame is out of date.)

  
  

• Exporting your recent built Mame game list.

  
  

• Enhanced memory control.

  
  

• Auto adjust processing power (based on CPU temp & RAM usage.)

  
  

• Added audio cues to notify of errors/completed build (optional)

  
  

• Fixed the open in explorer option.

  
  

• Added ZIP/TAR/Bzip compatibility.

  
  

• Added a system tray menu.

  
  

• Added an auto-hide feature (when compiling/optional.)

  
  

• Added a Windows 7 progress bar to taskbar icon (if running Windows 7.)

  
  

• Added the ability to submit error logs automatically.

  
  

• Added automatic loading of "last working" settings.

  
  

• Added slueth mode (which will build Mame only when PC is in an Idle state.)

  
  

• Added to option to pause the current process (in case you need to do something that requires more computing power, can resume as well.)

  
  

Along with these added options I have a few more in mind to give a person total control, and offer a totaly easy to build Mame executable. So, outside of the above changes if there is anything else that you can think of or anybody else, just let me know and I will throw it in.

In reference to your can the program be ran from any location query - the short answer is no. Right now MinGW is limited to a local disk as well as your Mame source code cache. If I attempt to move those then the variables in the program would all need to be rewritten - then there would be a huge chance of undesired errors within the application. The program does offer the option to load and save settings, but beyond that any configuration settings would only be for face value.

That is not to say that someday I won't find a way around these limitations. Currently the program is now 20k+ lines of code and growing more everyday. I am about to move a lot of functions to external DLL files to save space within the internal applcation. But hey, I might be able to do what you are suggestion just

because I love a good challenge!

Thanks guys!

[Rain]

MyMame sporting handsome Tool Tips:

[djvj]

[Rain]

Oops, looks like a prerelease build of MyMame was leaked late last night - damned me and my sleep! I have pulled it because it still requires much work. I will try to have everything finished today!

[whiLd]

You're not allowed to sleep!

j/k

Sent from my DROIDX using Tapatalk

[Rain]

I wonder if I should make downloadable modules for certain Mame builds that a user could just download and select, rather than having to hardcode every Mame build out there, therefore requiring an update everytime a module is coded just to run the program? Something for me to think about.

Oh, I found a gremlin in the system - so naturally I bashed it's head in with my mighty keyboard then I stole it's ritches! No, but seriously I did manage to find a broken shelf in the application that could potentially result in some failed builds - it is fixed now.

[nekkard]

I downloaded and tried this out last night. Maybe it was that prerelease you mentioned. I had lots of trouble getting builds to compile. I managed to get a .0143 build to compile a couple of times but the NoNag patch didn't seem to work (yes I clicked the button). I had lots of failed compiles, I couldn't get a .0139 build to successfully compile, and I submitted some of the errors I got. I hope those help you.

Thanks for all your hard work and I look forward to future releases so I can try again. I'm a noob at this and appreciate your efforts to help.

[Rain]

Yeah, I read your error reports. Mame 0.139 uses a modified version of allegro (not the allergy pill) that is not included in the MyMame program at this point. I am still in the process of dumping library indexes into the program. When using the allegro binaries I managed to get 139 to build multiple times.

But 139 will compile in the final build. The 143 patch will not be added unless there is a u build present. For instance if you compile 143u1 the patch will apply, but if you compile 143 the patch will not apply. That issue has been resolved as well.

Other than those issues you mentioned which are already solved I don't see any other problems with the program. But remember if you try to go down to 014 or lower it will not compile as that requires an antique DirectX 7 SDK. So I am removing all support for DirectX versions in the final release. Thanks for your reply!

[djvj]

Please add support for changing input mode to direct input:

In:

src\osd\windows\input.c

This is rawinput mode:

// For testing purposes: force DirectInput

#define FORCE_DIRECTINPUT 0

This is directinput mode:

// For testing purposes: force DirectInput

#define FORCE_DIRECTINPUT 1

You only need rawinput if you use multiple mice (aka lightguns) or keyboards. In Directinput mode, you can use xPadder, ahk hotkeys, shared keyboard/mouse via Input Director or Synergy, etc..

[bLAZER]

To people whom it matter to, it pretty much all boils down to updates & machine architecture. If I asked you to show me a version of Mame 0.143u6 for a quad core 64 bit processor with the Hi-score patch, you'd never be able to find it on the Internet.

Actually, if you look at the right places you can find binaries of all gazillions versions of MAME. And 99% of all people, if they knew where to find them, would chose to download them instead of building their own. For the average user it's pointless to compile their own.

[Rain]

Actually, if you look at the right places you can find binaries of all gazillions versions of MAME. And 99% of all people, if they knew where to find them, would chose to download them instead of building their own. For the average user it's pointless to compile their own.

Don't know about that, but I never trusted downloading a "hacked" version of any program when the source code is readily available for the taking. Seems like too much of a risk to me, but then again for over ten years there is only one site I will even download an emulator from - if it's not from him I won't go near it.

For the "average" user finding those binaries maybe more of a pain then it's worth when you weigh it against compiling. Don't know, this program was mainly made for the dozens and dozens of people I see on here daily requesting instructions on compiling Mame. Will I use this program that I am making? I'm not sure, I like to dive deep down into the rabbit hole and modify my own source code to go with my precise system configuration.

Actually for the average user I would think it is more important that they learn how to compile Mame. It teaches them a little bit about computers and the software that runs their machine. Otherwise if they can just simply slop something together they will, having never learnt a thing. Personally I compile my own Demul, Dolphin, BSNES, and Mednafen builds whenever new source is available. But, I guess I just like to know what it is I'm doing..

In:

src\osd\windows\input.c

This is rawinput mode:

// For testing purposes: force DirectInput

#define FORCE_DIRECTINPUT 0

This is directinput mode:

// For testing purposes: force DirectInput

#define FORCE_DIRECTINPUT 1

I will look into applying those modifications, but right now we are using pure source code for everything out there on the table. I will see what I might need to add to change code at runtime, but that will take some time.

Today is my day off of work, I have eight PC's compiling Mame all day. I will release the next version of the program once I see that it can compile all Mame versions from 150 to 143u6, then I will be satisfied. There are also a few Mame mods that I have been working on that may make it into the optional downloads of MyMame.

Thanks for the comments and the good ideals guys!

[rimbambito]

To people whom it matter to, it pretty much all boils down to updates & machine architecture. If I asked you to show me a version of Mame 0.143u6 for a quad core 64 bit processor with the Hi-score patch, you'd never be able to find it on the Internet. However, you could just build your own version and have it in about an hour.

Building primarily is for those whom want to stay up to date with their Mame build and have those updates as soon as they are released. Myself, I have always compiled my own Mame since 2000 becuase I like the benefits of running an executable custom tailored for my own system, the speed increase and because I like to modify the original source code to inlclude my own enhancements.

Along with that there are other benefits, for instance if you use a 15hz monitor you can build your Mame to output at 15hz, you can add patches to double/triple buffer graphics, you can even add DirectX 11 support as well as sound enhancements. There is a giant laundry list on why one would want to compile their own Mame distribution.

I will be writing an extensive tutorial and releasing it with the next MyMame release which will also touch on how Mame works on the code level. Be sure to check it out! I hope that this has answered your question!

Thanks for the info. I'll be watching this thread very closely. Good luck

[Rain]

New version released, see first post.

[djvj]

Cool, I'll grab it to play with.

[djvj]

Latest build fails every time (143u6). Telling me to do a clean compile even though I deleted all source files, this shouldn't be needed. Also, the log seems to be starting late, the top line doesn't even show it downloading the src. These are the first few lines:

patching file src/emu/addrmap.c

patching file src/emu/addrmap.h

patching file src/emu/clifront.c

[Rain]

That WA a known bug in the last version. I removed that string error. Should work now. It used to always say it failed but when you looked in your archive folder you'd still see the compiled exe. Ill look at that after work. Thanks for the heads up.

Sent from my MB508 using Tapatalk

[Rain]

The program has been updated and seems to be working pretty good now. I added a debug option as requested that will compile mame using the debug methods such as direct input and a few other options only found in the debug builds of Mame.

Changelog:

1. Fixed the incorrect "compile not a success message."
   
2. Fixed the cache cleaner (improved speed.)
   
3. Added a debug build option to the compile options.
   
4. Added a new support method for dual/quad cores (internal.)
   
5. Added a flow stabalizer (to keep program from crashing when in realtime mode.)
   
6. Finally fixed the damned ZIP method, it is now working.
   
7. Enhanced the support for 64 bit processors.
   

Your application should automatically update the next time you start the program. If it doesn't just fill out the contact form on MyMame and I will look into it as soon as I can.

Well guys, it's been real - but I got to take a break. I know MyMame is still in beta but I've been going at it really hard over the past few weeks. Over 3,000 debug builds compiled, over 16k lines of code sorted, dozens of databases configured; but now I need just a little time to relax.

I am not abandoning this project, but until the new Mame version comes out I will be only doing minor updates and no hard coding. For now I am just going to wait until MyMame starts to build a little bit of a fanbase and get's more users. Once I get more users I will be able to expand on the current platform.

I have been pondering some really neat ideals but in which I will start applying one at a time. I will however be working in the background on a new compiling platform that will replace MinGW - but that is not looking so promising as of yet because instead of a few thousands of lines of code - we are talking a few hundred thousand lines of code.

On a personal not I would like to thank anonymous, whomever you are your $60 donation to the project is truly appreciated. With it I was able to purchase a library from a vendor at a really great deal (that is the main driving force behind MyMame right now.)

I would like to state that I am always taking suggestions on things that I can do to expand the platform of MyMame. I know that some versions of Mame will not compile and rest assured those are being looked into as well, when all is said and done I promise that MyMame will be your new one stop Mame compiling solution.

Thanks for the fun guys,

Ronald -- Out!

Thanks guys!

[akiles500]

Rain is very important that if you can to add a option for that we can compile a version with FORCE_DIRECTINPUT 0 and other with FORCE_DIRECTINPUT 1.

Please add support for changing input mode to direct input:

In:

src\osd\windows\input.c

This is rawinput mode:

// For testing purposes: force DirectInput

#define FORCE_DIRECTINPUT 0

This is directinput mode:

// For testing purposes: force DirectInput

#define FORCE_DIRECTINPUT 1

A good program but it needs that option because I have a version of mameplus for to play with games of lightgun and other version to rest of the games of mame.