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 attachment 61603 [details] games-emulation/gxmame-0.35_beta2-r1.ebuild
Created attachment 61604 [details, diff] 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.
Comment on attachment 61603 [details] games-emulation/gxmame-0.35_beta2-r1.ebuild 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.
