GroovyArcade GLSL Performance

[robbo43]

Hi All,

I seem to get really poor performance enabling glsl and using the CRT-Geom shader in groovy arcade. Games drop to 1=around 1/3 speed. I'm running the latest beta of GA with GroovyMAME 0.167, graphics card is a GTX460 outputting to a 1600x1200 lcd. Using the same hardware in windows I have no performance issues.

Anything I should be looking at in the mame.ini file to improve performance?

Cheers

Rob

[Calamity]

I've no experience with GLSL, but I'd try the "-video accel" option.

[robbo43]

Thanks for the quick reply! I've tried a couple of things. I changed video in my mame.ini from opengl to accel and it no longer applies the glsl shader. I also tried adding -video accel and -video accel -rd opengl to the emulator "mame" line in advancemenu.rc and again it fails to apply the shader.

Have I done something wrong there?   

Cheers

Rob

[Calamity]

Try -video accel -renderdriver opengl

[robbo43]

Thanks again, but still no joy, the shader fails to be rendered.

Cheers

Rob

[u-man]

with your setup, it should be possible to run the CRT-geom shader twice just saying.... something must be very odd in your setup, if it doesnt work.
pls attach the shader you are using.

[Doozer]

I can confirm that since mame version 0.167 the shader mode is not applied properly (black screen) but the emulation is running well and the game sounds are audible. This has been verified under SDL with openGL.

You can test/use a previous version to have the GLSL working as expected.

[Calamity]

I can confirm that since mame version 0.167 the shader mode is not applied properly (black screen) but the emulation is running well and the game sounds are audible. This has been verified under SDL with openGL.

You can test/use a previous version to have the GLSL working as expected.

Do you mean this is an issue with baseline MAME or just GroovyMAME?

[robbo43]

Thanks Guys,

Just to clarify I'm running GroovyMAME 0.167 with the last GroovyArcade beta. When trying to apply a CRT-geom shader, performance drops to ~30% of full speed. If I try to use the -video accel command (with or without -renderdriver opengl) the emulation runs full speed, just with no evidence of the shader being applied (e.g. no effects).

This happens with every single shader I've tried (included those 'bundled'), but I've attached my favourite CRT Geom Bloom.

Cheers

Rob

[u-man]

All i see is, that your shader is a.) not complete and b.) you are using the multipass shader version of CRT-geom, which means you are missing two blur-shaders that create the bloom, used by the CRT geom bloom shader.

I attached the whole shader package. Put the shaders into your MAME install folder and run this commandline:

Code: [Select]

mame -glsl_shader_mame0 gaussx -glsl_shader_mame1 gaussy -glsl_shader_mame2 CRT-geom-halation
please report back if it works for you.

[robbo43]

u-man,

Thanks, haven't got time tonight, but will try tomorrow and report back.

Cheers

Rob

[Doozer]

Do you mean this is an issue with baseline MAME or just GroovyMAME?

I haven't tested stock mame on that subject. I will setup something to confirm this.

[u-man]

I can confirm that since mame version 0.167 the shader mode is not applied properly (black screen) but the emulation is running well and the game sounds are audible. This has been verified under SDL with openGL.

You can test/use a previous version to have the GLSL working as expected.

If you have that black screen with the CRT-geom shader, than it is because of this line in the "CRT Geom Bloom.vsh" file

Code: [Select]

// tilt angle in radians
  // (behavior might be a bit wrong if both components are nonzero)
  const vec2 angle = vec2(0.0,0.01);
There are some graphic cards that have your described issue with a black screen as a result, if the values are "(0.0,0.0)". We corrected this by using a slightly higher value i.e. "0.01 or 0.001". Just try out my attachment and look if you still have a black screen.

[Doozer]

Hi U-man,

I am using the same GLSL shader files which were working fine with previous version. The CRT shader model is from 'Copyright (C) 2010-2012 cgwg, Themaister and DOLLS'

In this version, the angle is already set to something different from zero.

Code: [Select]

  // tilt angle in radians
  // (behavior might be a bit wrong if both components are nonzero)
  const vec2 angle = vec2(0.0,-0.15);

I will give a try to your provided files.

[robbo43]

u-man,

Have tested the files and here is the outcome (I think there's several things going on here that I don't understand!)

Test 1 - RType 1 (55Hz game)

 If I apply the shader as per instructions, and set lcd_range to 50-75, the shader applies correctly, the screen scrolls smoothly, but runs at 37% speed. If I change lcd_range to auto or 60-60, the shader applies correctly, the game claims to be running @ 100% but the game randomly jumps and skips. I've used this terminology as it is not the same kind of artefacts you get from a 55Hz gaming running on a 60Hz monitor (i.e. regular tearing).

Test 2 - Shinobi (60Hz game)

Applying the shader results in the game running at 37%, but scrolling is smooth. No difference in behaviour if lcd_range is set to 50-75 or auto.

Not sure what to do next.

Cheers

Rob

[Calamity]

the game running at 37%, but scrolling is smooth.

That sounds surreal. But can you confirm whether the game is actually running at the *right* speed, despite the reported speed I mean.

[robbo43]

Calamity,

Sorry, should've been clear, you can tell the game is running at approximately 1/3 speed when 37% is reported. When R-Type is set to run with lcd_range at 60-60 or auto, the game does run at full speed (GM reports 100%), but with lots of random dropped or missing frames. And I thought that the speed should be reported at 110% as I have refreshspeed set to 1 so the game should be throttled to match the 60Hz refresh rate of the screen.

Cheers

Rob

[Calamity]

The option that needs to be enabled is syncrefresh, not refreshspeed.

[robbo43]

Thanks for clarifying that. Just to confirm the R-Type behaviour is exactly the same with syncrefresh set to 1 and GLSL shaders applied.

lcd_range 50-75: game runs at 37%, smooth scrolling observed but game definitely runs at 1/3 speed
lcd_range auto or 60-60: game reports running at 100% (not 110%). Game appears to be running at full speed but with random dropped and missed frames, this does not look like the normal tearing you get when running a 55hz game at 60Hz. Should've said frameskip is set to 0 (not auto).

Cheers

Rob

[u-man]

Well, i sadly cant test the shader on another OS, i am windows only .... but even on windows, SDL/GLSL works. So i can only assume, that either your OS is missing important drivers for your graphics card or GroovyArcade itself is causing the trouble. If GLSL would have problems on Linux/Mac OS X, there would be more reports about it and GLSL is the only option for shaders in Linux/Mac OS X.

Of all shaders i use, the CRT-geom shader is the one with the lowest demand on resources, so 37% with your setup sounds like a big error and i am pretty sure, it doesnt have to do with the shader itself.

[robbo43]

u-man,

I was coming to that conclusion myself, and I'm thinking it may well be an NVidia specific issue. I've been testing a win7 setup with GroovyMAME and have no problems with GLSL, although have decided to go down the d3d9ex and HLSL route as I love the apparent zero input lag using usb joysticks and spinners. I love GroovyArcade because the usb input lag 'feels' a hell of a lot less than xp or 7. However, calamity's latest GM release on win7 eliminates this even though my gfx card isn't quite fast enough to completely remove the static tearing.

My ideal would be to have a GroovyAarcade setup, with GLSL running at 100% and a HP LP2065 LCD so all games ran at the native refresh rates.

One last question - does anybody know if it is possible to update the NVidia drivers in the GroovyArcade distro, and if so, point me towards a tutorial / guide? Would like to see if this fixes it.

Cheers

Rob

[Doozer]

Code: [Select]

// tilt angle in radians
  // (behavior might be a bit wrong if both components are nonzero)
  const vec2 angle = vec2(0.0,0.01);
There are some graphic cards that have your described issue with a black screen as a result, if the values are "(0.0,0.0)". We corrected this by using a slightly higher value i.e. "0.01 or 0.001". Just try out my attachment and look if you still have a black screen.

Hi U-Man,

I confirm that changing the tilt angle cures the black screen effect. By the way, GA stock version is currently affected by this odd behaviour.

Thank you for pointing me into that direction. You saved my time from a long regression tracking from Xorg to SDL ;-)

Cheers