GroovyMame instead of Shmupmame? Noob Questions!

[CDexWard]

I recently read an old post on shmups.com where someone stated that Shmupmame is pretty much obsolete thanks to Groovymame, even for LCD users. I am in no way an expert in arcade hardware and just need a solution to play Ketsui on my PC with as little lag as possible but the game actually looking good would also be nice.

So, this is my MAME setup so far: A Benq 16:10 (1920x1200) LCD display with low input lag in tate running Shmupmame 4.2 on an old PC with a Radeon HD4500 GPU.

I am pretty fed up with the visual problems that Shmupmame introduced by removing the framebuffer emulation and it woul also be very nice to be able to use GLSL shaders. I found a very nice GLSL conversion of the crt-aperture shader by easymode on some MAME forum, which just happens to be my favourite shader in Retroarch on my main gaming PC.

So, my questions about switching to GroovyMame would be these:

1. How does GM with it's "lower input lag" fare in regards to Shmupmame when both have vsync enabled on an lcd?

2. Do I need switchres when using an LCD display and can this or Groovymame somehow damage my display? It is rather precious to me.

3. Does Groovymame support GLSL shaders and do shaders further affect input lag? Is my HD4500 enough to run the crt-aperture shader?

4. Does the 16:10 aspect ratio of my display cause any problems with displaying the game correctly? Right now Shmupmame takes full advantage of the display's width (in tate) with black bars top and bottom. Does GM handle this the same way?

I hope someone can help me with this!

[krick]

I just spent about 15 minutes googling trying to figure out what the hell "tate" means.

For anyone else reading this thread, it's some kind of "scene" slang (possibly bastardized Japanese) for running the monitor in a vertical orientation.

[CDexWard]

Haha, I thought that this was common knowledge in an arcade forum.

[Recapnation]

1. You should try it yourself. GM's "fare" is based around the "frame delay" feature -- use the search button here and you'll find out. The fork you mention is old and doesn't emulate the original hardware behaviour -- are you happy with that?

2. With a proper configuration, there's nothing to be afraid of.

3. Yes and theoretically, yes. No clue.

4. You can use the same display resolution and effects as with mainline MAME.

[buttersoft]

I just spent about 15 minutes googling trying to figure out what the hell "tate" means.

For anyone else reading this thread, it's some kind of "scene" slang (possibly bastardized Japanese) for running the monitor in a vertical orientation.

Yeah, weirdo foreigners. Probably comes from the obscure traditional Japnese word RO-tah-te or some ---steaming pile of meadow muffin---.

[schmerzkaufen]

Just shmups slang, short for 'tatte iru' I guess, which just means 'standing up' screen orientation. We say 'portrait', guess that too sounds weird to the Japanese...

I could be wrong but ShmupsMAME afaik is just a collection of drivers hacks, mainly just removing a sprites layer buffer which is why some sprites appear shaky/not in sync in several games).
While it should indeed reduce the lag ingame by 1 frame, ShmupsMAME still uses regular D3D and lacks frame_delay or the D3D9ex alternative, so it can't bypass the typical D3D frames queue (of 2 or 3 frames?)
GM does, and therefore should allow for even greater lag reduction, by default using D3D9ex, and the furthest/shortest by tweaking each driver using frame_delay + related settings.
GM also has working syncrefresh which grants locked/smooth scrollings if one chooses to use it, at the cost a slightly sped up or reduced game speed, by un unnoticeable % for most games that are close to 60Hz.
Also portaudio audio delay reduction of course since it was added to baseline recently.
Using OGL changes the rules I think, I don't know so I won't comment on that.

As I see it compared to GM, ShmupsMAME uses hacks producing visible artifacts and probably breaks emulation accuracy, it doesn't produce the lowest lag (neither on video nor audio), and is based on outdated MAME builds missing lots of genuine/official improvements, fixes and new games.
Again people, correct me if I'm wrong, but I think ShmupsMAME should just be forgotten, it was cool when it came out, but it now completely obsolete in both build and purpose.

[CDexWard]

Thank you for your replies! I know the frame delay option from Retroarch. I will try out GM tonight but I fear that I can't rely on frame delay too much because I am shmupping on a 10 year old pc and iirc this feature is very cpu heavy.

2. With a proper configuration, there's nothing to be afraid of.

This is not really comforting. When I try GM out of the box, will the configuration be proper? Are display breaking things usually settings that have to be set manually?

[schmerzkaufen]

With GM you should begin by creating a mame.ini file and edit settings in it. This is how you control it.
(to generate the ini you have to use a command line prompt; read here: http://forum.arcadecontrols.com/index.php/topic,151459.0.html)

There's no short 'quick basic settings for LCD users' written but you should edit the following for a bare minimum providing working lower video and audio lag, I guess...

Code: [Select]

#
# CORE SWITCHRES OPTIONS
#
monitor                   lcd^ mandatory or you'll get an error message

Code: [Select]

#
# OSD VIDEO OPTIONS
#
video                     d3d^ this as I understand actually enables D3D9ex if you have picked one of the patched builds a few members compile and share here with every update

Code: [Select]

#
# OSD SOUND OPTIONS
#
sound                     portaudio
audio_latency             1^ this I think is the minimum you can do to reduce audio latency by default, I don't know much more about it, seems to work a bit for me without issues

(also don't forget to edit the folders paths etc if needed, or put everything 'bios' & 'devices' in the roms folder along with the games roms. For everything picture settings, scaling filtering etc see for yourself. There are ways to further control things using extra .ini files to put in the ini folder, but it is preferable to discuss that in a separate thread or dedicated post)

Your only shader option is HLSL since with GM we're using D3D anyway. You can activate it in the mame.ini as well. It's become tricky to use, there's the usual settings but also a 'raster.ini' file somewhere that's in control of several parameters. Really impractical, and coming with awful default values.
RetroArch works differently using OpenGL and claiming lag/sync acrobatics similar to GM, the difference is that it comes with tons of shaders options configurable via the GUI, it's unbeatable in that area, as even MAME whether using its default HLSL, OGL GLSL, or BGFX doesn't come close in terms of possibilities and convenience.
For everything mentioned above I have no idea:
1. if RA is as capable as GM in terms of lag reduction
2. if using any kind of shaders (HLSL, GLSL, BGFX) adds more or less lag on top of everything or not at all

Lastly; SwitchRes is integrated to GM and turned on by default as it should, I don't think there's any possibility that it would damage your monitor.
I would be more worried about the Intel HD chipset's compatibility and performance, personally when using only that I've seen poorer performance and some things not working properly like for instance the .png overlays

[CDexWard]

Thank you very much for this detailed post. GM only supporting HLSL is a bummer, though, since the variant of crt-aperture I found on MAMEWorld is in GLSL format. Is there some kind of HLSL shader database where I can download a preset? I never could find something like this, only discussions of people writing their own shader. Again, Retroarch comes with a huge amound of shader presets and there is a github page with screenshots for all of them.

[schmerzkaufen]

HLSL is HLSL, there are no 'others' to select, afaik it's the only thing available using D3D, and GM needs D3D.
HLSL features a ton of parameters to extensively tweak and modify the picture effects, like other advanced shaders under OpenGL or BGFX systems do. It's just rather heavy/headscratching in comparison.