Build Your Own Arcade Controls Forum
Software Support => GroovyMAME => Topic started by: 8BitMonk on July 19, 2015, 06:54:25 pm
-
I'm having trouble setting up Groovymame to work with my LCD. From the instructions I've read it seems like you just need to change the monitor setting in the .ini file to be 'lcd', video to d3d and changing the monitor aspect and resolution to match your LCD. When I launch Groovymame I'm getting an error message that says: Switchres could not find a video mode that meets your specs.
Are there other .ini settings that need to change? Do you still run Is it just a matter of using the Groovymame .exe and changing .ini file or do you still run VMMaker? Should modeline_generation be on or off, I've tried both ways. I feel like it must be something simple I'm missing but haven't found the answer in a forum or web search.
Appreciate any help!
-
Why would you want to use groovymame for an lcd? Is there a feature not relating to crt display that I am missing?
-
I've just test GM 163 64bit with set 005 and no problems here. Hardware: i5-2400, Intel HD 2000, Win 7 x64.
Settings:
monitor lcd
video d3d (auto also worked)
aspect 16:9
The only information was: SwitchRes: [005] (1) vertical (224x256@60.00)->(1440x900@60.00)
-
Probably your desktop resolution is marked as @59, or @120. Adjust the lcd_range option accordingly:
-lcd_range 50-60
(default is 60-60)
-
Why would you want to use groovymame for an lcd? Is there a feature not relating to crt display that I am missing?
I can't speak for 8BitMonk but I started using GroovyMame because it gave smooth scrolling without tearing on my LCD setup.
-
Why would you want to use groovymame for an lcd? Is there a feature not relating to crt display that I am missing?
I can't speak for 8BitMonk but I started using GroovyMame because it gave smooth scrolling without tearing on my LCD setup.
You can do the same with MAMEUIFX too ;)
-
Why would you want to use groovymame for an lcd? Is there a feature not relating to crt display that I am missing?
I can't speak for 8BitMonk but I started using GroovyMame because it gave smooth scrolling without tearing on my LCD setup.
Yep, this. Awhile back I asked Calamity about the benefits to using GM alone (ie. without VMMaker/CRTEmudriver) with an LCD and this is what he cited.
Probably your desktop resolution is marked as @59, or @120. Adjust the lcd_range option accordingly:
-lcd_range 50-60
(default is 60-60)
Thanks for the suggestion. I changed the lcd_range to 50-60 and then I started getting this error: Unable to create the Direct3D device (8876086C).
Here's what I had changed from the fresh GM .ini file:
monitor lcd
lcd_range 50-60
aspect 16:9
resolution 1920x1080@60
video d3d
Since I have two monitors running and mame was launching on the second monitor I decided to switch the primary. I went into my monitor control panel, made my second monitor my main display and now GM launches fine without errors. Any ideas why this is?
My next question is about the best values for the lcd range based on the monitor. When I go in and look at one monitor under advanced settings it shows 59 and 60 hz only but the other monitor shows 25, 29, 30hz interlace along with 50,59 and 60hz. Does this mean I should broaden my lcd range settings to 25-60 to take advantage of the lower refresh rates?
Thanks again for the help!
-
Another thing I just noticed. I'm trying to use the Lottes shader with GM and it doesn't seem to be working. Is this expected, doesn't GM work with video set to opengl? My settings for the Lottes shader work with vanilla 64bit mame.
#
# OpenGL-SPECIFIC OPTIONS
#
gl_forcepow2texture 1
gl_notexturerect 1
gl_vbo 1
gl_pbo 1
gl_glsl 1
gl_glsl_filter 0
glsl_shader_mame0 shader\Lottes_CRT
-
Since I have two monitors running and mame was launching on the second monitor I decided to switch the primary. I went into my monitor control panel, made my second monitor my main display and now GM launches fine without errors. Any ideas why this is?
Before switching monitors, where you pointing to the right display with the -screen option? e.g. -screen \\.\DISPLAY2
the other monitor shows 25, 29, 30hz interlace along with 50,59 and 60hz. Does this mean I should broaden my lcd range settings to 25-60 to take advantage of the lower refresh rates?
I don't think the monitor actually works at those refresh rates, it just supports them as input frequencies. If you're running your desktop at 60 Hz, then just keep lcd_range 60-60. It only makes sense to modify the range when the desktop resolution is not 60, like when sometimes it's reported as 59, or when it's 120.
The original purpose of the lcd_range setting is to be used with Powerstrip and an LCD monitor that really supports variable refresh rates.
-
Another thing I just noticed. I'm trying to use the Lottes shader with GM and it doesn't seem to be working. Is this expected, doesn't GM work with video set to opengl? My settings for the Lottes shader work with vanilla 64bit mame.
It did work last time I checked. Notice OpenGL will crash with -mt.
Bear in mind the -syncrefresh option is not currently possible with OpenGL though, so this API is not usable in practice with GM. Under Linux it's only usable because we're bypassing it through drm in order to get a working v-sync (such bizarre extremes to enable some basic functionality).
-
It did work last time I checked. Notice OpenGL will crash with -mt.
Huh, doesn't seem to work for me, no noticeable affect with opengl and glsl setting activated. Does this work for anyone else? What is the -mt switch?
Bear in mind the -syncrefresh option is not currently possible with OpenGL though, so this API is not usable in practice with GM. Under Linux it's only usable because we're bypassing it through drm in order to get a working v-sync (such bizarre extremes to enable some basic functionality).
Does this mean that it nullifies the effects of Groovymame, ie. reducing screen tearing/sound stuttering etc. and so they can't be used together? That'd be a shame, I really like the Lottes shader. Does this go for HLSL as well? HLSL effects seems to work for me with GM when I have it enabled unlike the Lottes shader and opengl.
-
Before switching monitors, where you pointing to the right display with the -screen option? e.g. -screen \\.\DISPLAY2
I wasn't targeting a monitor specifically, had just left it on the default setting.
I don't think the monitor actually works at those refresh rates, it just supports them as input frequencies. If you're running your desktop at 60 Hz, then just keep lcd_range 60-60. It only makes sense to modify the range when the desktop resolution is not 60, like when sometimes it's reported as 59, or when it's 120.
The original purpose of the lcd_range setting is to be used with Powerstrip and an LCD monitor that really supports variable refresh rates.
Got it, thanks for the info.
-
Why would you want to use groovymame for an lcd? Is there a feature not relating to crt display that I am missing?
I can't speak for 8BitMonk but I started using GroovyMame because it gave smooth scrolling without tearing on my LCD setup.
You can do the same with MAMEUIFX too ;)
Are you talking about using MAMEUIFX to turn on triplebuffering and vsync or is there something else I'm missing? I do like the fact that it has hlsl and glsl settings within the UI and there are good presets, very cool. One thing I've noticed about MAMEUIFX is that after I point it to all of my roms and art it's incredibly slow to browse. I've also never used it with my Hyperspin setup before but I'd imagine it would work ok there.
-
So Calamity or u-man, one more question regarding this. If you're using an LCD/LED where you can't change the refresh rate anyway what is the difference between using GM and just turning on triplebuffering, sync to monitor refresh or wait on vsync?
With these options enabled in UIFX I don't notice any sound stuttering or screen tearing and can use the OpenGL Lottes Shader or HLSL without an issue. I didn't do exhaustive testing, just Pacman and MK as it's easy to notice issues with audio and tearing issues in them and it seems to work fine with either shader enabled and triplebuffering, sync to monitor refresh and wait on vsync enables.
Thanks for clarifying!
-
Why would you want to use groovymame for an lcd? Is there a feature not relating to crt display that I am missing?
I can't speak for 8BitMonk but I started using GroovyMame because it gave smooth scrolling without tearing on my LCD setup.
You can do the same with MAMEUIFX too ;)
Nah ive tried using MAMEUIFX but seems to have tearing issues, GM does not!
-
http://mame32fx.altervista.org/features.htm (http://mame32fx.altervista.org/features.htm)
- Added feature: SYNC TO MONITOR REFRESH (GroovyMAME)
Please... i am sick and tired of this blaming about UIFX is this, UIFX is that.
-
So does this feature in UIFX use Groovymame code since says Groovymame in parenthesis? I thought syncrefresh was a standard mame setting.
UIFX works for me with this setting enabled, ie. I can use the Lottes shader AND don't seem to get any tearing or sound stutter. If the setting is related to Groovymame I'm curious why I can't get it to work directly with the GM executable, only HLSL works with GM.
-
http://mame32fx.altervista.org/features.htm (http://mame32fx.altervista.org/features.htm)
- Added feature: SYNC TO MONITOR REFRESH (GroovyMAME)
Please... i am sick and tired of this blaming about UIFX is this, UIFX is that.
Well they may have implemented that feature but it sure doesn't work (on ver 0.161). Playing vertical games (with my monitor in a vertical orientation) with UIFX there is a constant sync line going across the screen near the top with GM there is no such issues
-
Well they may have implemented that feature but it sure doesn't work (on ver 0.161). Playing vertical games (with my monitor in a vertical orientation) with UIFX there is a constant sync line going across the screen near the top with GM there is no such issues
None for me though I've only tried a handful of vert and horizontal games, 1942, Robotron, Marvel vs. Capcom, Joust, Galaga and I'm running .163.
What game(s) are you noticing it in?
Do you have Triplebuffer, waitvsync or frameskip enabled?
Are you running any HLSL or GSL shaders?
-
Hi 8BitMonk,
So does this feature in UIFX use Groovymame code since says Groovymame in parenthesis? I thought syncrefresh was a standard mame setting.
Check this post, it's explained there,
http://geedorah.com/eiusdemmodi/forum/viewtopic.php?pid=321#p321 (http://geedorah.com/eiusdemmodi/forum/viewtopic.php?pid=321#p321)
UIFX works for me with this setting enabled, ie. I can use the Lottes shader AND don't seem to get any tearing or sound stutter. If the setting is related to Groovymame I'm curious why I can't get it to work directly with the GM executable, only HLSL works with GM.
So what happens exactly? Does it crash? Any error message? What video card are you using?
-
Check this post, it's explained there,
http://geedorah.com/eiusdemmodi/forum/viewtopic.php?pid=321#p321 (http://geedorah.com/eiusdemmodi/forum/viewtopic.php?pid=321#p321)
Thanks, this clarifies it for me. Am I right then in concluding that UIFX would be the optimal setup for an LCD since it has these modifications to the mame source code as an option and will sync sound and video perfectly along with the ability to concurrently use any of the shaders?
So what happens exactly? Does it crash? Any error message? What video card are you using?
Groovymame runs, it just looks unfiltered when I enable the Lottes shader. I know the Lottes shader settings work because I have the regular mame executable in the same folder as GM and it works. I also notice that if I turn on the normal filter option in the .ini file it doesn't look filtered either when running GM. HLSL works.
Video card is a GeForce GTX 760, monitor is a Dell Ultrasharp U2711 running 2560x1440
.ini file is below. I only changed 2 settings from the GM default, monitor lcd and lcd_range 50-60. Previously I had changed the aspect and resolution but they don't seem to have any effect.
#
# CORE CONFIGURATION OPTIONS
#
readconfig 1
writeconfig 0
#
# CORE SEARCH PATH OPTIONS
#
rompath roms
hashpath hash
samplepath samples
artpath artwork
ctrlrpath ctrlr
inipath .;ini
fontpath .
cheatpath cheat
crosshairpath crosshair
#
# CORE OUTPUT DIRECTORY OPTIONS
#
cfg_directory cfg
nvram_directory nvram
input_directory inp
state_directory sta
snapshot_directory snap
diff_directory diff
comment_directory comments
#
# CORE OUTPUT DIRECTORY OPTIONS
#
hiscore_directory hi
#
# CORE STATE/PLAYBACK OPTIONS
#
state
autosave 0
playback
record
mngwrite
aviwrite
wavwrite
snapname %g/%i
snapsize auto
snapview internal
snapbilinear 1
statename %g
burnin 0
#
# CORE PERFORMANCE OPTIONS
#
autoframeskip 0
frameskip 0
seconds_to_run 0
throttle 1
syncrefresh 0
sleep 1
speed 1.0
refreshspeed 0
#
# CORE ROTATION OPTIONS
#
rotate 1
ror 0
rol 0
autoror 0
autorol 0
flipx 0
flipy 0
#
# CORE ARTWORK OPTIONS
#
artwork_crop 1
use_backdrops 0
use_overlays 0
use_bezels 0
use_cpanels 0
use_marquees 0
#
# CORE SCREEN OPTIONS
#
brightness 1.0
contrast 1.0
gamma 1.0
pause_brightness 0.65
effect none
#
# CORE VECTOR OPTIONS
#
antialias 1
beam 1.0
flicker 0
#
# CORE SOUND OPTIONS
#
samplerate 48000
samples 1
volume 0
#
# CORE INPUT OPTIONS
#
coin_lockout 1
ctrlr
mouse 0
joystick 1
lightgun 0
multikeyboard 0
multimouse 0
steadykey 0
ui_active 0
offscreen_reload 0
joystick_map auto
joystick_deadzone 0.3
joystick_saturation 0.85
natural 0
joystick_contradictory 0
coin_impulse 0
#
# CORE INPUT AUTOMATIC ENABLE OPTIONS
#
paddle_device keyboard
adstick_device keyboard
pedal_device keyboard
dial_device keyboard
trackball_device keyboard
lightgun_device keyboard
positional_device keyboard
mouse_device mouse
#
# CORE DEBUGGING OPTIONS
#
verbose 0
log 0
oslog 0
debug 0
update_in_pause 0
debugscript
#
# CORE COMM OPTIONS
#
comm_localhost 0.0.0.0
comm_localport 15112
comm_remotehost 127.0.0.1
comm_remoteport 15112
#
# CORE MISC OPTIONS
#
drc 1
drc_use_c 0
drc_log_uml 0
drc_log_native 0
bios
cheat 0
skip_gameinfo 0
uifont default
ramsize
confirm_quit 0
ui_mouse 0
autoboot_command
autoboot_delay 2
autoboot_script
http 0
http_port 8080
http_path web
console 0
#
# CORE MKChamp OPTIONS
#
disable_hiscore_patch 0
disable_nagscreen_patch 1
disable_loading_patch 1
#
# CORE SWITCHRES OPTIONS
#
modeline_generation 1
monitor lcd
orientation horizontal
connector auto
interlace 1
doublescan 1
cleanstretch 0
changeres 1
powerstrip 0
lock_system_modes 1
lock_unsupported_modes 1
refresh_dont_care 0
dotclock_min 0
sync_refresh_tolerance 2.0
frame_delay 0
black_frame_insertion 0
modeline auto
ps_timing auto
lcd_range 50-60
crt_range0 auto
crt_range1 auto
crt_range2 auto
crt_range3 auto
crt_range4 auto
crt_range5 auto
crt_range6 auto
crt_range7 auto
crt_range8 auto
crt_range9 auto
#
# OSD KEYBOARD MAPPING OPTIONS
#
uimodekey SCRLOCK
#
# OSD FONT OPTIONS
#
uifontprovider auto
#
# OSD DEBUGGING OPTIONS
#
debugger auto
debugger_font auto
debugger_font_size 0
watchdog 0
#
# OSD PERFORMANCE OPTIONS
#
multithreading 0
numprocessors auto
bench 0
#
# OSD VIDEO OPTIONS
#
video auto
numscreens 1
window 0
maximize 1
keepaspect 0
unevenstretch 0
waitvsync 0
#
# OSD PER-WINDOW VIDEO OPTIONS
#
screen auto
aspect auto
resolution auto
view auto
screen0 auto
aspect0 auto
resolution0 auto
view0 auto
screen1 auto
aspect1 auto
resolution1 auto
view1 auto
screen2 auto
aspect2 auto
resolution2 auto
view2 auto
screen3 auto
aspect3 auto
resolution3 auto
view3 auto
#
# OSD FULL SCREEN OPTIONS
#
switchres 1
#
# OSD ACCELERATED VIDEO OPTIONS
#
filter 0
prescale 1
#
# OpenGL-SPECIFIC OPTIONS
#
gl_forcepow2texture 0
gl_notexturerect 0
gl_vbo 1
gl_pbo 1
gl_glsl 0
gl_glsl_filter 1
glsl_shader_mame0 none
glsl_shader_mame1 none
glsl_shader_mame2 none
glsl_shader_mame3 none
glsl_shader_mame4 none
glsl_shader_mame5 none
glsl_shader_mame6 none
glsl_shader_mame7 none
glsl_shader_mame8 none
glsl_shader_mame9 none
glsl_shader_screen0 none
glsl_shader_screen1 none
glsl_shader_screen2 none
glsl_shader_screen3 none
glsl_shader_screen4 none
glsl_shader_screen5 none
glsl_shader_screen6 none
glsl_shader_screen7 none
glsl_shader_screen8 none
glsl_shader_screen9 none
#
# OSD SOUND OPTIONS
#
sound auto
audio_latency 2.0
#
# WINDOWS PERFORMANCE OPTIONS
#
priority 0
profile 0
#
# WINDOWS VIDEO OPTIONS
#
menu 0
#
# DIRECTDRAW-SPECIFIC OPTIONS
#
hwstretch 0
#
# DIRECT3D POST-PROCESSING OPTIONS
#
hlsl_enable 0
hlslpath hlsl
hlsl_prescale_x 0
hlsl_prescale_y 0
hlsl_preset -1
hlsl_write
hlsl_snap_width 2048
hlsl_snap_height 1536
shadow_mask_alpha 0.0
shadow_mask_texture aperture.png
shadow_mask_x_count 6
shadow_mask_y_count 6
shadow_mask_usize 0.1875
shadow_mask_vsize 0.1875
shadow_mask_uoffset 0.0
shadow_mask_voffset 0.0
curvature 0.03
round_corner 0.03
reflection 0.03
vignetting 0.03
scanline_alpha 1.0
scanline_size 1.0
scanline_height 1.0
scanline_bright_scale 1.0
scanline_bright_offset 0.0
scanline_jitter 0.0
defocus 0.0,0.0
converge_x 0.3,0.0,-0.3
converge_y 0.0,0.3,-0.3
radial_converge_x 0.0,0.0,0.0
radial_converge_y 0.0,0.0,0.0
red_ratio 1.0,0.0,0.0
grn_ratio 0.0,1.0,0.0
blu_ratio 0.0,0.0,1.0
saturation 1.4
offset 0.0,0.0,0.0
scale 0.95,0.95,0.95
power 0.8,0.8,0.8
floor 0.05,0.05,0.05
phosphor_life 0.4,0.4,0.4
#
# NTSC POST-PROCESSING OPTIONS
#
yiq_enable 0
yiq_cc 3.59754545
yiq_a 0.5
yiq_b 0.5
yiq_o 1.570796325
yiq_p 1.0
yiq_n 1.0
yiq_y 6.0
yiq_i 1.2
yiq_q 0.6
yiq_scan_time 52.6
yiq_phase_count 2
#
# VECTOR POST-PROCESSING OPTIONS
#
vector_length_scale 0.8
vector_length_ratio 500.0
#
# BLOOM POST-PROCESSING OPTIONS
#
vector_bloom_scale 0.3
raster_bloom_scale 0.225
bloom_lvl0_weight 1.0
bloom_lvl1_weight 0.21
bloom_lvl2_weight 0.19
bloom_lvl3_weight 0.17
bloom_lvl4_weight 0.15
bloom_lvl5_weight 0.14
bloom_lvl6_weight 0.13
bloom_lvl7_weight 0.12
bloom_lvl8_weight 0.11
bloom_lvl9_weight 0.10
bloom_lvl10_weight 0.09
#
# FULL SCREEN OPTIONS
#
triplebuffer 0
full_screen_brightness 1.0
full_screen_contrast 1.0
full_screen_gamma 1.0
#
# INPUT DEVICE OPTIONS
#
dual_lightgun 0
-
I'm afraid this happens because of the automatic -prescale setting applied by GM. I need to add an exception for glsl, as we have for hlsl currently. Simply force -precale 1 from command line and it should work. To make that change permanent, add that option inside horizont.ini and vertical.ini, *only* that option. The prescale setting in mame.ini is overridden by Switchres.
-
I'm afraid this happens because of the automatic -prescale setting applied by GM. I need to add an exception for glsl, as we have for hlsl currently. Simply force -precale 1 from command line and it should work. To make that change permanent, add that option inside horizont.ini and vertical.ini, *only* that option. The prescale setting in mame.ini is overridden by Switchres.
Thanks Calamity, that did the trick.
Does Switchres have an affect on aspect as well because the games I tested look stretched and I've tried changing values such as aspect and keepaspect with no effect. Switchres always reports it's running at my monitors res of 2560x1440 @ 59hz even if I try to change the resolution under video settings as well.
I'm still curious if this is better/worse or the same vs. using UIFX. In answer to one of my previous questions (below) you had mentioned an -mt switch crashing with opengl and that syncrefresh isn't possible with OpenGL so the api isn't usable in GM which I still don't understand. I thought it to mean that OpenGL and the Lottes Shader wouldn't work with GroovyMame or **would work but nullify some it's benefits in regards to syncing/refreshing the image. The UIFX fix seems to address the issue at the core and make the changes to the mame source that you suggest.
It did work last time I checked. Notice OpenGL will crash with -mt.
Bear in mind the -syncrefresh option is not currently possible with OpenGL though, so this API is not usable in practice with GM. Under Linux it's only usable because we're bypassing it through drm in order to get a working v-sync (such bizarre extremes to enable some basic functionality).
-
Does Switchres have an affect on aspect as well because the games I tested look stretched and I've tried changing values such as aspect and keepaspect with no effect. Switchres always reports it's running at my monitors res of 2560x1440 @ 59hz even if I try to change the resolution under video settings as well.
I think I answered my own question on this one. It was only happening in games with reresh rates over 60hz such as Pacman which looked stretched. Adding a set aspect and resolution in the mame .ini seemed to fix it, forgot I had left those out.
aspect 16:9
resolution 2560x1440@60
Oddly though when I look at the Switchres value on the game information screen within games it still always reports 2560x1440@59Hz.
-
http://mame32fx.altervista.org/features.htm (http://mame32fx.altervista.org/features.htm)
- Added feature: SYNC TO MONITOR REFRESH (GroovyMAME)
Please... i am sick and tired of this blaming about UIFX is this, UIFX is that.
Well they may have implemented that feature but it sure doesn't work (on ver 0.161). Playing vertical games (with my monitor in a vertical orientation) with UIFX there is a constant sync line going across the screen near the top with GM there is no such issues
Well, thats sad for you. I dont have that problems, as long as I use HLSL. No matter if my monitor is in vertical orientation or not. No tearing here and i only have that option "sync to monitor refresh" enabled and V-Sync. My V-Sync is hardware enabled, i use the V-Sync from my graphic-cards properties so to say, because of the bad V-Sync implementation on the GLSL side. I also double checked that my monitor refresh is at 60Hz. Sorry to say that, but the tearing-errors you get, must be something different and has nothing to do with UIFX.
GLSL is a different story. Sometimes it works properly, sometimes not... depending on the game. What I mean with this is, there are no tearing problems, but the sound will ugly pitch up and down, so you have to play either without sound or with tearing. Thats at least my experience. Good example for this issue is Street Fighter II Worldwarrior. On the other side, I can play Aero Fighters, that has 61.31Hz and should be much worse because of that refresh, but it plays fine with nice sound. Its really odd and I hope the MAME devs will fix this issue.
-
GLSL is a different story. Sometimes it works properly, sometimes not... depending on the game. What I mean with this is, there are no tearing problems, but the sound will ugly pitch up and down, so you have to play either without sound or with tearing. Thats at least my experience. Good example for this issue is Street Fighter II Worldwarrior. On the other side, I can play Aero Fighters, that has 61.31Hz and should be much worse because of that refresh, but it plays fine with nice sound. Its really odd and I hope the MAME devs will fix this issue.
GLSL seems to be working fine for me, no problems in Street Fighter II at all. Is your graphics card underpowered? I'm running a GeForce GTX 760.
-
GLSL seems to be working fine for me
I'm running a GeForce GTX 760.
Yeah, that's because you're using a Nvidia. OpenGL's V-sync implementation is not consistent across brands. That's terrible (for OpenGL). Besides, OpenGL is highly Nvidia-biased. MAMEdevs often mention about their Nvidia cards so most of them are likely on Nvidia, which contrasts (https://www.youtube.com/watch?v=_36yNWw_07g) with the fact they're on Linux too btw.
EDIT: From an old update:
What's new in SwitchRes v0.015g
- Added support for video mode switching with the OpenGL renderer in Windows (-video opengl). Notice that in order to get any vertical synchronization through the OpenGL renderer, the WGL_EXT_swap_control extension must be present in the system, otherwise the emulation will run unthrottled. This seems to be totally driver dependent. Not a real alternative to Direct3D at the moment.
So if the WGL_EXT_swap_control extension is present in your system, chances are -syncrefresh will work out of the box. Otherwise, it may work by forcing v-sync externally as suggested above.
(This extension was not present in any of my ATI/AMD systems.)
-
GLSL seems to be working fine for me
I'm running a GeForce GTX 760.
Yeah, that's because you're using a Nvidia. OpenGL's V-sync implementation is not consistent across brands. That's terrible (for OpenGL). Besides, OpenGL is highly Nvidia-biased. MAMEdevs often mention about their Nvidia cards so most of them are likely on Nvidia, which contrasts (https://www.youtube.com/watch?v=_36yNWw_07g) with the fact they're on Linux too btw.
Interesting, had no idea there was a brand bias with OpenGL. Good to know, I guess I lucked out with the card I'm using. Funny Linus video :laugh2:
-
Interesting, had no idea there was a brand bias with OpenGL.
Well maybe I should have said that Nvidia is OpenGL-biased, but due to its huge traction the effect is what I said although it's actually the other way round, if this makes any sense.
-
All the info in this thread was very useful. I was able to get the lottes shader working on my Intel integrated graphics by using all the settings here and forcing vsync in the Intel driver. Looks great now and no more sound stuttering.