|
Faster MAMEhub released and our new web site
#263826 - 09/03/11 02:01 PM
|
|
|
Hi,
I have just finished working on our new official MAMEhub web site at https://sites.google.com/site/mamehub
This brings everything together nicely now 
Also, DigitalGhost changed compiler, and as a result, speed optimisations have now been made to CS-MAME/CS-MESS.
"I updated my compiler to Visual Studio 2010. The newer compiler should do a better job of optimizing the code and making CSMAME/CSMESS faster.
I turned on MAXOPT, which enables a bunch of compiler optimizations. This should also make the code significantly faster".
Note, we are still testing the new CS-MAME/CS-MESS changes. Looks great so far.
regards
Zambr / Zambr123
MAMEhub Team
Edited by zambr (09/03/11 02:47 PM)
|
|
|
| CTOJAH |
|
MAME Addict
|
|
|
|
|
Reged: 07/13/10
|
|
Posts: 980
|
|
Loc: Macedonia,Veles
|
|
|
|
Send PM
|
|
|
Re: Faster MAMEhub released and our new web site
[Re: zambr]
#263828 - 09/03/11 02:33 PM
|
|
|
|
|
|
Re: Faster MAMEhub released and our new web site
[Re: CTOJAH]
#263830 - 09/03/11 02:39 PM
|
|
|
Strange, was working when i tested it a few minutes ago.
Also if you use the hyperlink button on text edit, when you goto preview, it hides the URL's. Thus, i just typed the URL's as plain text (then it automatically made it linkable).
Ok, having another look.
Update: should be fine now. Thanks.
Edited by zambr (09/03/11 02:50 PM)
|
|
|
|
Re: Faster MAMEhub released and our new web site
[Re: zambr]
#263835 - 09/03/11 03:40 PM
|
|
|
[PythonFanboyism]
Another fine example that Python totally rules and provides all the means to developers who want to elegantly implement their great ideas, even cross-platform!
[/PythonFanboyism]
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: Faster MAMEhub released and our new web site
[Re: zambr]
#263855 - 09/03/11 08:36 PM
|
|
|
Fair warning: on 64-bit, MSVC produces a slower MAME binary than MinGW (32-bit it depends on the specific driver - each compiler's faster on some specific games), and MAME is not QA'ed for non-MinGW compilers so any bugs found in that configuration are invalid for MAMETesters.
In other words, yet again someone assumed MAMEdev are a bunch of stupids who "durr"ed our way to emulating 7000 games. Not so, we do actively work at this stuff ;-)
|
|
|
|
Re: Faster MAMEhub released and our new web site
[Re: R. Belmont]
#264117 - 09/07/11 08:41 AM
|
|
|
> Fair warning: on 64-bit, MSVC produces a slower MAME binary than MinGW (32-bit it
> depends on the specific driver - each compiler's faster on some specific games), and
> MAME is not QA'ed for non-MinGW compilers so any bugs found in that configuration are
> invalid for MAMETesters.
>
> In other words, yet again someone assumed MAMEdev are a bunch of stupids who "durr"ed
> our way to emulating 7000 games. Not so, we do actively work at this stuff ;-)
I don't think that MAMEdev are a bunch of stupids, but I think that MAMEdev are xenophobic and use outdated build tools.
If MAME isn't QA'ed for MSVC, why is the first developer doc on mamedev.org "Building MAME using Microsoft Visual Studio compilers"?
I am almost done with my own version of the MAME build system that links WAY faster (read: static libraries), breaks ridiculous dependency cycles (src/emu depended on drivlist.c which depended on drivers which depended on src/emu), and separates building tools like mk68kmake from building the emulator itself. With these changes and some wrapper code, I can compile and run the latest MAME on Android and Google Native Client.
|
Check out MAMEHub here: http://www.mamehub.info/
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: Faster MAMEhub released and our new web site
[Re: Digitalghost]
#264156 - 09/07/11 07:43 PM
|
|
|
> I don't think that MAMEdev are a bunch of stupids, but I think that MAMEdev are
> xenophobic and use outdated build tools.
We'd love to update the build tools, but there's a blocker bug in MinGW-W64 with C++ try/catch handling that renders MAME unusable. (Yes, we've filed an official bug with them).
I'm fuzzy how a project which regularly includes submissions from 4 continents is "xenophobic".
> If MAME isn't QA'ed for MSVC, why is the first developer doc on mamedev.org "Building
> MAME using Microsoft Visual Studio compilers"?
Because that's a non-obvious process, so it needs documentation.
> I am almost done with my own version of the MAME build system that links WAY faster
> (read: static libraries)
MAME has built static libraries since the beginning of time and it frankly hasn't done much for link times.
>, breaks ridiculous dependency cycles (src/emu depended on
> drivlist.c which depended on drivers which depended on src/emu)
That's not a build system thing, that's a "someone go through and clean up the #include graph" thing
> , and separates
> building tools like mk68kmake from building the emulator itself.
Those *are* separate - we've supported cross-compiles in the build system for 2 or 3 years now.
I do hope your miracle new setup uses Cmake though. I'm a fan, we use it at work.
> With these changes
> and some wrapper code, I can compile and run the latest MAME on Android and Google
> Native Client.
Google, Inc. has done an official port of MAME to NaCl, and those changes have been quietly folded back into mainline over the last several releases so I would certainly hope you can do that.
|
|
|
|
Re: Faster MAMEhub released and our new web site
[Re: R. Belmont]
#264158 - 09/07/11 07:55 PM
|
|
|
> > I don't think that MAMEdev are a bunch of stupids, but I think that MAMEdev are
> > xenophobic and use outdated build tools.
>
> We'd love to update the build tools, but there's a blocker bug in MinGW-W64 with C++
> try/catch handling that renders MAME unusable. (Yes, we've filed an official bug with
> them).
Unless this bug has changed since 0.139, recent versions of MinGW/MSYS do not build MAME at all, because of issues with the Makefiles.
>
> I'm fuzzy how a project which regularly includes submissions from 4 continents is
> "xenophobic".
>
> > If MAME isn't QA'ed for MSVC, why is the first developer doc on mamedev.org
> "Building
> > MAME using Microsoft Visual Studio compilers"?
>
> Because that's a non-obvious process, so it needs documentation.
>
> > I am almost done with my own version of the MAME build system that links WAY faster
> > (read: static libraries)
>
> MAME has built static libraries since the beginning of time and it frankly hasn't
> done much for link times.
>
> >, breaks ridiculous dependency cycles (src/emu depended on
> > drivlist.c which depended on drivers which depended on src/emu)
>
> make depend.
make depend does not address what I'm talking about: What does address what I'm talking about is replacing drivlist.c with a driver interface and binding the drivers at runtime. Then, the code in src/emu/* and mame/drivers/* can be static libraries without creating a circular dependency at link-time. The way the current build system handles this is by linking hundreds of .o's into one monolithic executable, which takes forever and breaks building on android.
>
> > , and separates
> > building tools like mk68kmake from building the emulator itself.
>
> Those *are* separate - we've supported cross-compiles in the build system for 2 or 3
> years now.
>
> I do hope your miracle new setup uses Cmake though. I'm a fan, we use it at work.
>
> > With these changes
> > and some wrapper code, I can compile and run the latest MAME on Android and Google
> > Native Client.
>
> Google, Inc. has done an official port of MAME to NaCl, and those changes have been
> quietly folded back into mainline over the last several releases so I would certainly
> hope you can do that.
|
Check out MAMEHub here: http://www.mamehub.info/
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: Faster MAMEhub released and our new web site
[Re: Digitalghost]
#264160 - 09/07/11 08:05 PM
|
|
|
> Unless this bug has changed since 0.139, recent versions of MinGW/MSYS do not build
> MAME at all, because of issues with the Makefiles.
The bug hasn't changed, but MAME itself has been largely cleared of GCC 4.6 problems in that timeframe. Similarly, Clang 2.9 3.0 should work for MAME when it's released as we've also been testing there (and they've kindly fixed a bug specifically exposed by MAME).
> make depend does not address what I'm talking about: What does address what I'm
> talking about is replacing drivlist.c with a driver interface and binding the drivers
> at runtime. Then, the code in src/emu/* and mame/drivers/* can be static libraries
> without creating a circular dependency at link-time. The way the current build system
> handles this is by linking hundreds of .o's into one monolithic executable, which
> takes forever and breaks building on android.
Now I'm confused, because that's not what the current build system does at all. It distills the .os into a few dozen .a static libraries (libemu.a for src/emu, namco.a for Namco games, and so on) and then links all the libraries together.
Also, there have been significant changes to how drivlist.c is handled since 0.139.
Edited by R. Belmont (09/07/11 08:12 PM)
|
|
|
|
Re: Faster MAMEhub released and our new web site
[Re: R. Belmont]
#264161 - 09/07/11 08:16 PM
|
|
|
> > Unless this bug has changed since 0.139, recent versions of MinGW/MSYS do not build
> > MAME at all, because of issues with the Makefiles.
>
> The bug hasn't changed, but MAME itself has been largely cleared of GCC 4.6 problems
> in that timeframe. Similarly, Clang 2.9 should work for MAME when it's released as
> we've also been testing there (and they've kindly fixed a bug specifically exposed by
> MAME).
>
> > make depend does not address what I'm talking about: What does address what I'm
> > talking about is replacing drivlist.c with a driver interface and binding the
> drivers
> > at runtime. Then, the code in src/emu/* and mame/drivers/* can be static libraries
> > without creating a circular dependency at link-time. The way the current build
> system
> > handles this is by linking hundreds of .o's into one monolithic executable, which
> > takes forever and breaks building on android.
>
> Now I'm confused, because that's not what the current build system does at all. It
> distills the .os into a few dozen .a static libraries (libemu.a for src/emu, namco.a
> for Namco games, and so on) and then links all the libraries together.
>
> Also, there have been significant changes to how drivlist.c is handled since 0.139.
While it's true that archives are generated from the .o's, they are not treated as static libraries. If they were, you could use ld as the linker instead of g++. As it is now, g++ links every .a and .o together in one step. This negates the benefit of using static libraries, and you might as well be linking every .o and not have .a's at all. If you try to use ld to link MAME, you will realize that there are dependency cycles in the .a's and they can't actually be used as static libraries. This means that build systems like NDK (android) which depend on linking code with ld can't handle MAME's current architecture.
|
Check out MAMEHub here: http://www.mamehub.info/
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: Faster MAMEhub released and our new web site
[Re: Digitalghost]
#264164 - 09/07/11 08:22 PM
|
|
|
> While it's true that archives are generated from the .o's, they are not treated as
> static libraries. If they were, you could use ld as the linker instead of g++. As it
> is now, g++ links every .a and .o together in one step. This negates the benefit of
> using static libraries, and you might as well be linking every .o and not have .a's
> at all. If you try to use ld to link MAME, you will realize that there are dependency
> cycles in the .a's and they can't actually be used as static libraries. This means
> that build systems like NDK (android) which depend on linking code with ld can't
> handle MAME's current architecture.
Ok, that's fair, and you'd gain some better parallelism in the build as well. Do send in these changes once you've gotten them to work with latest.
|
|
|
|
Re: Faster MAMEhub released and our new web site
[Re: R. Belmont]
#264193 - 09/08/11 12:30 AM
|
|
|
> > While it's true that archives are generated from the .o's, they are not treated as
> > static libraries. If they were, you could use ld as the linker instead of g++. As
> it
> > is now, g++ links every .a and .o together in one step. This negates the benefit of
> > using static libraries, and you might as well be linking every .o and not have .a's
> > at all. If you try to use ld to link MAME, you will realize that there are
> dependency
> > cycles in the .a's and they can't actually be used as static libraries. This means
> > that build systems like NDK (android) which depend on linking code with ld can't
> > handle MAME's current architecture.
>
> Ok, that's fair, and you'd gain some better parallelism in the build as well. Do send
> in these changes once you've gotten them to work with latest.
That's what I've been saying all along 
/me dots his .o's and crosses his .a's **brain explodes*
|
Cheers,
Terra Cresta
|
|
|
Re: Faster MAMEhub released and our new web site
[Re: Digitalghost]
#264224 - 09/08/11 10:09 AM
|
|
|
> I am almost done with my own version of the MAME build system that links WAY faster
> (read: static libraries), breaks ridiculous dependency cycles (src/emu depended on
> drivlist.c which depended on drivers which depended on src/emu), and separates
> building tools like mk68kmake from building the emulator itself. With these changes
> and some wrapper code, I can compile and run the latest MAME on Android and Google
> Native Client.
>>>>>>>>>>>>>>>>>
Excited to hear this DG! I'm sure it'll make MameHub run even faster and smoother
|
|
|
Previous 
Index 
Next 
Threaded 
Faster MAMEhub released and our new web site
Reply
[Re: 
