17 September 2016

Performance Tests BGFX vs. GLSL (Update September 2016)

Standardized performance testing from the command line explained (so you keep your MAME configuration fully intact - again many thanks for Headrush69 for this insight):

Open Terminal and change into your MAME directory, then execute (example for BGFX/CRT-GEOM-DELUXE testing):
./mame64 -video bgfx -str 60 -noafs -bgfx_screen_chains crt-geom-deluxe -bgfx_backend opengl -artcrop -noreadconfig -nosleep -nothrottle rtype

What this example does: It launches R-Type for 60 seconds with the BGFX/CRT-GEOM-DELUXE shader and the OpenGL backend on full speed. Other configuration options of mame.ini left out. After exiting MAME, the Terminal window provides you with the performance result:
Average speed: 634.69% (60 seconds)

If you want to test the GLSL shaders that you have installed manually, be sure that you provide the full path. Example with bezels disabled:
./mame64 -video opengl -nofilter -gl_glsl -glsl_shader_mame0 /Users/xxxxxxxxxxxx/Documents/mame/CRT-GEOM-DELUXE/CRT-geom-halation -str 60 -noafs -artcrop -noreadconfig -nosleep -nothrottle -nobezel elevator

Conclusions from my performance tests: 
  • CRT-GEOM rules both in OpenGL/GLSL and BGFX performance-wise - but take the new OpenGL/GLSL-Halation shaders (discussed here), since they perform much better! You can use Glow both in OpenGL and BGFX without risking a performance hit. 
  • If your machine can handle BGFX, the main advantages are that (i) you can fine-tune with sliders in the game and immediately see the result and (ii) you can even switch shaders in the game in real-time, which is extremely cool. Details are here.
  • The BGFX/HLSL shaders crawl on weaker machines, while the BGFX/CRT-GEOM shader performs decently on weaker machines as well (in my case it works very well on a MacBook Pro 13'' Mid 2012, whereas HLSL crawls with 40%)
  • As for BGFX, I would really like to see a slimmed down version of the default MAME HLSL shader that does not take away that much performance.
  • GLSL in MAME 0.163 vs 0.177: Elevator Action: 730% vs 840%, Gyruss 287.15% vs 429.85% -> very nice performance increases also under OpenGL! (However it seems that the 0.178 release predominantly looses these gains again) 
Here are some details

10 September 2016

Getting a Video Retro Effect on LCD - BGFX, GLSL or Artwork Effect (Update September 2016)

Consider tweaking your screen output as soon as possible 

Since MAME focuses on exact emulation, the unmodified output is unsuitable for flatscreens. This means that the tube screen feeling must be emulated on top.

Raw MAME Output without tweaking:
Let's face it: This is ugly.

Understand the meaning of these Buzz Words:
  • Shader: program parts in MAME that can be activated for tweaking the Raw MAME output
  • Backends: sub-sections of a shader that chosen once a shader is activated 
  • OpenGL Shader - GLSL: for a long time the most important shader for Mac systems, still the performance king, but not part of the standard package
  • BGFX Shader: the new kid on the block, designed for cross-platform experience, official part of MAME
  • HLSL Shader: the shader in the Windows environment - don't mix this up with HLSL Backends within GLSL or BGFX - which apparently try to emulate the HLSL Shader in Mac systems
Recommendations summarized:
  • MAME STANDARD: bilinear filtering - just comes out of the box and gets rid of the worst pixel effects
  • ALTERNATIVE 1: If your machine is powerful enough, go for BGFX with the CRT-GEOM Deluxe Backend (new instructions below)
  • ALTERNATIVE 2: If this does not work out, go for GLSL with the CRT-GEOM Deluxe Backend instead (new instructions below)
  • ALTERNATIVE 3: If this does not work out, just add an Artwork Effect or - better - head for a new Mac
Here are the details for all three options - complete re-write in September 2016.

08 September 2016

04 September 2016

MAME 0.177 - First Impressions

This became my first build from source because the official build was done in MacOSX 10.11. As described in today's update to this post, the build compiled smoothly. So here are my first impressions.

(A) BGFX Metal backend seems broken. I hope that this is not due to my own compile. When trying to launch a game from the command line, the Terminal application returns the following error:
/Library/Caches/com.apple.xbs/Sources/Metal/Metal-56.6.1/Framework/MTLRenderPipeline.mm:1006: failed assertion `Blending is enabled for render target 0; however, the pixelformat MTLPixelFormatInvalid for this render target is not blendable.'

Abort trap: 6
Doesn't seem to be a problem of my own build. OpenGL backend works without problems.

(B) Performance: Headrush69 (who posts a lot of good comments here) provided me with the perfect performance testing tool from the Terminal (from inside of the MAME directory), because you do not need to change anything in your settings for doing these tests. Many thanks Headrush69 for this! And here are some first performance results:

Compiling QMC2 and MAME under Mac OS El Capitan/Sierra (Update 02/2017)

Compiling an own QMC2 MacOSX build has been a longstanding target of mine: From time to time, official MacOS binaries have been missing or delayed. In particular installing QT in its legacy version 4.8.7 proved difficult. Homebrew changed this and now the QMC2 compiling process works very well.

Since MAME 0.177 I have also been compiling my own builds under El Captain and later on MacOS Sierra, and it just works.

Compiling QMC2 - the details

(A) The starting point is the QMC2 Wiki - which in the meantime is no longer outdated:

(B) For El Capitan and MacOS Sierra, QT 4.8.7 needs to be installed via Homebrew (as now documented under (A):

Step 1 - go to http://brew.sh

Step 2 - open your Terminal and install Homebrew by copy pasting the entire Terminal command from the window:
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
Step 3 - run the following commands from the Terminal:
brew install qt4
brew linkapps qt (links the qt4 commands to the Applications folder -> that has been a recommendation which I am no longer sure about, but it should be no issue to manually remove the symlinks later on)

Voila, I have a running QT 4.8.7 environment under El Capitan/Sierra :-).

(C) As soon as you have the proper QT environment in place, compiling of QMC2 as explained under (A) worked like a breeze - in short:
Switch to the tmp directory of your MacOSX system via Terminal, then download the source code of QT2 (tmp directory assures that these files are deleted):
svn co https://svn.code.sf.net/p/qmc2/code/trunk qmc2
Then switch into the qmc2 directory:
cd qmc2
Then make the executables (in my example with an alternative image set, otherwise just make):
make IMGSET=crazy
Then install, and make sure that an existing qmc2 directory in the Applications folder is renamed before executing this command:
make install
Means: Without 'sudo make' you cannot overwrite an existing qmc2 directory in Applications - rename it  to e.g 'qmc2.old' beforehand just in case.

But why compiling QMC2 in the first place? First of all, sometimes you have to wait for the Mac binaries for quite some time, and for some versions, they just don't appear online. Secondly, I like building QMC2 with customized icons and without the additional plugins. And finally, compiling from the svn repository is fun :-).

The result is a fairly nice black-themed QMC2, which I quite like. 
Screenshot with Black Theme, Click to enlarge
Compiling MAME - the (not so many) details:

Compiling MAME ever since El Captain is just as easy as it can get. Following the official instructions produces me builds that just work. This also means that these rather complicated build instructions are outdated.

It is just as easy as that:
  • Have XCode and SDL2 installed
  • Download and extract the MAME source code
  • Open Terminal and move to the MAME source code folder
  • make -j5 (if you have a quadcore machine) - drink coffee or tea during the build time
Only the cleanup seems a bit messy to me. Due to the lack of a 'make install' procedure, you must get rid of the source code chunks in your build manually.

Since MAME 0.177 until the current version all builds run without problems.

MAME in Homebrew: This is a very nice initiative. Here you also get all the dependencies installed automagically, and the MAME executable is in $PATH. My only major concern here is that these binaries are some four months behind the latest release, currently 0.179. So if you are not doing your own ROM sets, you can easily run into incompatible games. This is why I would not recommend this route right now (it would be interesting to understand why these builds are way behind).