Bugzilla Bug 96651

Hi. I've attached an proposed revision bump for gxmame-0.35_beta2 which
addresses two issues. The first is to ensure that ./configure is invoked using
the "--with-xmame-dir=/usr/share/games/xmame" argument. If this argument is not
specified then it defaults to "/usr/lib/games/xmame" instead which is incorrect
and results in the user having to configure no less than 14 text input fields
in gxmame's "Default options" dialog in order to fully correct! By making this
simple change, the default paths in gxmame will co-incide with those of xmame
inself (note that the current xmame ebuild does actually create a
/usr/share/games/xmame directory and that its default paths can be observed by
typing: xmame --showconfig).

The second issue concerns a new parameter which was introduced in xmame itself.
The help text for it states:

*** DGA Related ***
-vsync-pagelimit / -vspl <int> Maximum number of pages (frames) to queue in
video memory for display after vsync

Some comments on DGA first: the fact of the matter is that DGA is the only way
to get efficent performance in xmame (which also requires for xmame to be
setuid root, unfortunately). Users of very fast systems may not notice but
those with slower systems most certainly will. Using DGA mode I can get
equivalent performance to mame running on a Windows system (using DirectDraw)
and this has always been so.

Anyway, I can't remember which version this parameter was introduced in but I
noticed at the time that it severely impacts upon DGA performance. xmame
insists upon setting this value to 2 by default but (in my testing) I have
consistently found that disabling the option by setting it to 0 is the only way
to return DGA performance back to normal - just as it used to be. On my system
(PIII 733Mhz, nVidia TNT2 m64) performance is still no better than with xv (or
alternate display methods) unless I set it to 0, even with relatively
undemanding mame drivers. For example, if I run dbreed (Dragon Breed) I get a
100% (55/55fps) framerate without any issue. With -vspl 2 (the default), it
averages about 35fps which is frankly terrible. With -vspl 1 it averages at
39fps. This is reminiscent of my experiences with mame on Windows too ... page
flipping/buffering to avoid tearing sounds like a good idea but it actually
doesn't often seem to pan out in practice. For example, I found that the best
results were achievied by simply setting the vsync option and the option to
match the game's original monitor refresh rate (something we can't do with
xmame).

I am well aware than I ought to request an option to control this parameter
upstream and will probably do so. However, I would strongly request that this
option is disabled in the meantime. My argument is that a fast machine should
have no trouble achieving an adequate fill rate before the next vsync and that
a slow machine has its performance slaughtered by this option. Users of faster
machines will probably run with regular x11 or xv support (or SDL with the x11
backend) anyway and won't even notice/care. But for the sake of those who need
(or care) about performance/efficiency and use DGA please seriously consider
applying the patch as it is likely to help a gxmame achieve the best experience
without hunting around for hard-to-find tidbits of information ...

Created an attachment (id=61603) [edit]
games-emulation/gxmame-0.35_beta2-r1.ebuild

Created an attachment (id=61604) [edit]
gxmame-0.35_beta2-zero-pagelimit.patch

Causes gxmame to invoke mame with -vspl 0 in the case that xmame.x11 is the
executable being used.

(From update of attachment 61603 [edit])
added the xmame configure option

I don't think we should force -vspl 0 on people.  If people need it, they can
add it to Additional options in the configuration themselves.

so... half FIXED, half WONTFIX, marking FIXED.